Envisioning the Chrysler Building
Look at any skyline, and you will see buildings that once existed only in the minds of the architects who imagined them.
In 1928, how did architect William Van Alen persuade automobile manufacturer Walter P. Chrysler to build a gleaming tower of steel, bricks, and glass that would project to the world the success, power, and ingenuity of a company and its people? First, never underestimate the power of appealing to the ego in the executive suite. Having an architect who’s game to build the world’s tallest structure doesn’t hurt, either. But to transform such a grand ambition into reality, it was necessary for the founder’s business goals and the designer’s ideas to come together to form a common vision, and for this vision to be further refined by engineers who understood every aspect of the building’s structure and systems. A business titan, a visionary architect, and engineers asked to construct a structure like no other before it –this could be a recipe for disaster. Skylines prove it can be done.
Our aspirations for the software that runs our business operations should be no less lofty than those of the tycoons whose buildings define our city skylines: a high standard of solidly constructed, reliably efficient, and technically innovative structures that are visually appealing and as imaginative as they are practical. To achieve this result, architects make sketches and build models of the possibilities for review by their clients, engineers, and zoning officials. In contrast, the software development process focuses on the written word – lengthy descriptions of what is wanted from a system, descriptions that become a set of requirements explaining what the technology must do. This process keeps the focus of these objects on engineering, their essence defined by their computing power and technical sophistication rather than their relationship to human users and their ability to project to this audience a sense of empowerment, trust, and even delight. How people will see and touch the features of a new software product is typically a question left to be addressed only after the developers solve the engineering challenge.
What does a software application look like? How is it structured? If you ask technologists these questions, they will describe data structures, layers, and interfaces between the layers and their components. But from the user’s perspective, what does the software look like?
Unfortunately, what the users see on the screen is very often a result of careful consideration given to every aspect of the system except for them. What users are faced with is a product whose form has been dictated by engineering strategy and specifications for inventories of data and features. This lack of consideration for the human factor manifests itself in user interfaces that are little more than an afterthought to the challenges of coding.
From my earliest experiences with software development I’ve been amazed to see software teams move through a development cycle without creating a shared vision of what the end product will look like on the screen. Perhaps what is even more amazing is that budgets are drawn up and checks are approved by business executives who are agreeing to commit precious funds to something they haven’t seen and don’t completely understand.
If we can see a prototype of a product before it’s built, we can see how it will work. Making prototypes is the technique that designers use to spark love affairs between consumers and their favorite products. But before anyone can feel the love, everyone involved in a product’s creation needs to be able to explore the possibilities—without blowing the budget
A prototype can take many forms. Sometimes even a sketch on a napkin is enough to suggest the form of an idea or a concept and elicit reactions from an audience – reactions that drive further refinement of the idea or confirm the appropriateness of the form. A prototype may be a detailed drawing, a full-scale model, or a set of blueprints.
Blueprints are pictures that allow us to visualize the future; in “plan,” an aerial view of a floor, they allow us to imagine walking from room to room and to predict the experience we will have living and working in a space. In “section,” diagrams that allow us to understand vertical elements in the design within a space, we can see staircases, doorways and windows, baseboards and crown moldings. If we choose, we can page through a set of blueprints to see how the plumbing will carry water and waste to and from the kitchen and bathrooms and how the electrical system will be arranged.
What all true prototypes have in common is their fleeting nature: Their sole purpose is to facilitate communication among diverse audiences, elicit their reactions, and drive further design enhancement. A prototype is meant to be thrown away: No one will ever live in it, drive it, or use it for any other purpose. However inexpensive and ephemeral it may be, a prototype allows us to imagine the possibilities, explore options, and examine wild notions without the limitations of cost, time, or physics. Most importantly, a prototype allows individuals to understand a proposed design and for groups to share this understanding.
When we see a prototype, we can imagine what might be – bringing a creative, idealistic vision incrementally back to earth as we evaluate it against the realities of its construction requirements and seek fabrication techniques that rise to the challenge.
—Excerpted from Wrench in the System: What’s sabotaging your business software and how you can release the power to innovate by Harold Hambrose (John Wiley & Sons, Inc., New York). Order your copy of this book.
