The Deal


Management must make a commitment to bringing design in before programming begins. Analogously speaking, interaction design is architecture, not interior design. Interaction design determines where the concrete for the foundation will be poured as much as it determines which fabric will be most appropriate for the window treatments. This commitment must extend to giving the interaction designers the moral authority to dictate the shape and constitution of the product to the programmers. This will involve significant cultural upheaval, but the programmers will be happier after the change, and you will benefit from shortened programming time and an immensely superior product.

In exchange for this power, the interaction-design community must make two commitments of its own. First, interaction designers need to get some skin in the game. They need to stop standing on the sidelines giving advice to the programmers, while passively letting them take full responsibility for the success of the products. It is not good enough merely to have the right ideas. You have got to get those right ideas applied to practice, and the only time that is going to happen is when the interaction designers put themselves in harm's way. The programmers do it every time they write a line of code.

The second commitment that interaction designers must make is to put their design in writing.

Document Design to Get It Built

One of the really tough lessons that I have learned over the years is that good, even great, design is meaningless unless it gets built. And it will never get built unless it is described at length, with precision and detail, in terms that make sense to the programmers who must build it. It has to be in writing, in exhaustive detail, with supporting evidence and examples. It has to be printed and bound in multiple copies. It must be presented personally to the development team, with the VP of development standing there nodding his head and smiling. Better if it's the CEO.

The designers need to write, storyboard, animate, and sketch their solutions with sufficient completeness and detail that programmers can treat the solutions like blueprints and actually write code from them. Enough situations must be described in detail to give the developers confidence that the solution is robust enough to survive implementation.

The written design is like a written battle plan. Everyone knows his part and what the critical and timely issues are. Everyone can move in synchrony and harmony to create a product that is targeted at a specific user.

Programmers rely on a persuasive technique called "passive-aggressive." Instead of forcing a confrontation that must decide an issue, they avoid attention and quietly take or don't take action. It's like a passenger steering a canoe by surreptitiously leaning to one side or another. One of my favorite business axioms, "If it isn't on paper it doesn't exist," is truer than ever in the world of software design. Anything left unwritten is more than likely to be misconstrued or ignored because the motivations of the programmers are so divergent from the motivations of the users. It's not enough not to specify a dialog box, but the designer must explicitly state where the programmer is not to voluntarily insert an extra dialog box. To a programmer, dialog boxes are good things, and he feels like he is doing the user a favor to toss in a couple of extra ones in his spare time. To users, dialog boxes are hateful things that sap their energy and derail productivity.

Interaction designers, like architects, deliver a set of blueprints that describe the product to be built. But although the similarity between blueprints and software design documents is very close, they have great differences, too. Blueprints have a lot of leverage. A single line on paper can indicate a wall of 100,000 bricks. When interaction is involved, most of the leverage shrinks away. It might take a 100-page document to describe the behavior of 100 pages of code. With only a small dose of facetiousness, I say that a sufficiently detailed specification is indistinguishable from the code that implements it. In a perfect world, developers will grant designers a year to design and then give the programmers three months to code. In this world, the numbers are reversed.

What this means is that the design document must, of necessity, omit some things. As well as knowing what is good design, the designer must know what is important. The interaction designer must decide which parts of the program must be designed, and which parts can be left to the indigenous solutions of the programmers.

All of my design documents are organized in the "spiral" method of a newspaper. The headline of a news story tells the entire tale. Then the first paragraph tells the story again with a bit more detail. Then the next three paragraphs tell the story once again, this time with more information. Then the remainder of the article, which might take several columns, tells the entire story in complete detail. This allows the reader to take what she wants without drowning in unnecessary detail.

Design Affects the Code

Many people have the mistaken assumption that what interaction designers do, and that what needs to be done, is user-interface design. Interface design is certainly part of what needs to be done, but it holds only a secondary role in the process of design, much like packaging does in retail sales. Interface design is what is done after both the purpose and behavior of the interactive product are already established. But a bad product in beautiful and imaginative wrappings is still a bad product.

When experts are called in to do interface design, they are often summoned only after the product is already substantially built. The opportunity for significant design has passed, and the designer's efforts no matter how heroic have relatively limited impact.

Interaction design can have a dramatic effect on the actual implementation process, although this does not mean that the design is explicit about implementation issues. For example, the programmers might be expecting the designers to specify how an important dialog box should look to the user. However, interaction designers might wish to replace that dialog box with another idiom, such as a toolbar. But the designers are not concerned with how either dialogs or toolbars are actually coded.

Because the interaction designer might have a large effect on what does and does not get built, while studiously avoiding details of how things get built, we think of design as a product-definition process. Essentially, interaction designers determine the inside of the product by describing the outside of it. The interaction with the user is specified with great detail and precision, and the implementation issues are left to the programmer.

Design Documents Benefit Programmers

In Chapter 3, "Wasting Money," I asked the question, "What does 'done' look like?" The central purpose of the documents produced by the interaction designer is to answer that question. In general terms, a written design document is a robust mechanism for controlling the actual coding. It acts like the script and storyboard of a movie, making it clear to everyone how it will work, what is involved to build it and to use it, and when construction on it is done. The coding portion of development is typically the most uncontrollable and most fraught with risk, so not knowing when it is done is quite costly.

A clear, written design helps upper management understand precisely what it is building so it can create a more tightly focused business. Management will have a stronger message to deliver to investors, partners, employees, and colleagues. This ensures that all of the company's efforts work toward the same objective.

Programmers want strong and intelligent leadership. After all, they are strong and intelligent, and would obviously wish to be led by their equals, not their inferiors. Jerry Weinberg claims that everyone knows that "bad managers are easier to find than good programmers." This gives the good programmer more leverage over the manager than the manager has over the programmer, despite his nominal authority in the corporate hierarchy.

Product managers are weak if they cannot articulate with precision and conviction exactly what it is they are building. Typically, management expresses what it wants only in the vague terms of deadline management and too-specific feature-list negotiation. Only the programmers know with any precision what the actual product will look like, so they have more control over the project than the manager has.

I've worked with programmers who loathed the presence of an outside design firm. They know that my job is to "design," and they know that design is the creative, fun part of their job. After they have the opportunity to work with us, however, they realize that not only do we not detract from their job, but we also enhance it.

Recently, I attended an acrimonious meeting where some client programmers were invited without being briefed on our role. One gray-bearded programmer, named Fred, was particularly conspicuous. Throughout the meeting, whenever we presented some new idea or different way of offering up information to the user, he would attack us. He was highly intelligent and articulate, and he had a particularly stentorian voice. Every time we revealed another slide showing how the interaction would change, he would roll his eyes, smile condescendingly, and then make some remark about how we "didn't realize what large feats of magic" we were demanding from him and his team. At each step, he indicated that our design decisions made his job harder rather than easier.

Finally, at the conclusion of the meeting, as everyone streamed out of the room, our team was able to speak with Fred privately. We explained to him that our charter was to make the program easier and more powerful for end users, and that we were fully aware that our design decisions would entail significant additional thinking at the program level. We insisted that our concerns were only for the end user. All of a sudden a look of astonishment burst onto Fred's face. He exclaimed, "You are providing me with a significant technical challenge!" His entire attitude changed as he realized that we brought to him the grail of all programmers: a difficult problem worth solving.

Far from threatening him, we were bringing to him that which he most coveted: a chance to prove himself yet again as the cleverest, smartest, most skilled programmer around. His attitude changed when he realized that we took away only the messy human side of the program that he disliked, leaving him master of the clean, algorithmic internal part of the software. We became his benefactors instead of his nemeses.

Design Documents Benefit Marketing

In most noncomputerized businesses, marketing professionals own the product-definition step. In the software business, the marketers have been shunted out of the process. All they have to work with are requests for features. If they demand fixes, the programmers will merely fling the restrictive schedule back in their faces, asking, "How can I fix it if you won't give me time?" The marketing manager dares not give up precious time because not only will the schedule slip, but then everyone will see that the schedule is really just a sham, and the programmers will then proceed to abuse it with impunity in the future. Marketers know that a feature list is a very weak mechanism, and they often agitate for more involvement in the definition process. Unfortunately, marketers seem unable to provide direction that the developers find meaningful or useful.

One of the most important benefits of a strong design process and the rigorous documentation that is part of it is the power it makes available to marketers. The marketers describe to the designers the unfilled need or desire they hope to satisfy. The interaction designers then study potential users to determine their goals and to create a cast of characters. The crisply defined user personas are an important part of the written design documentation, and they become a focal point for marketing efforts. Even though the programmer works only with code, the design personas inform that code. Even though the marketer works with channels, target markets, media, and resellers, the design personas inform them. At last, the programmer and the marketer have a common ground.

In effect, interaction designers act as a go-between for marketing professionals. A designer is a person who can translate from marketese to programese. When marketers have a vague concern, they can describe it to the designers, who will work with them to develop the thought in terms of a persona. From there, the designer can translate it into a specification for interaction. What's more, the marketer can now see his input is being addressed and can be confident that he won't be handed raw technology and instructed to find a buyer for it.

The development of user personas is typically very familiar to marketing professionals. They often do a similar exercise, determining the product's buyer personas. These personas are determined by examining distribution channels and demographics rather than user goals and scenarios, so they are usually different from the designers' personas, but the user personas are always very helpful to the marketing experts in developing their own plans. Marketers can clearly express to the buyer how the product will help her users.

Design Documents Help Documenters and Tech Support

Any technical writer will tell you that good design eliminates the need for prodigious quantities of documentation. Fewer complex interactions mean fewer long explanations. The documentation writers can invest more time in writing at a higher level. Instead of devoting their efforts to leading users by the hand through the swamps of confusing interface, they can elevate their aspirations and put their efforts into taking users into more-beneficial areas of solving the problems of the application domain. Instead of discussing where files are stored in an inventory system, for example, the documentation can more profitably discuss inventory-leveling processes.

The same applies to technical support. The better the design is, the fewer calls come from the field. As the Peacock design described in the last chapter showed, a written design will cause a dramatic reduction in the need for technical support.

Design Documents Help Managers

Of all the constituencies, development management is the one interaction design helps the most. By describing what will be created well in advance of any programming, the entire process of development becomes faster, better informed, less risky, and less expensive. The entire process of development becomes more effective and is cut loose from being customer-driven.

Above all, design means more predictability. A designed product means that the programming phase will be more predictable. It also means that the success of the product can be more easily predicted and measured. These are the two most risky and expensive aspects of software-based product development. They reduce the cost of production, and they vanquish the myth of the unpredictable market. Ed Forman, the development VP of Elemental's Drumbeat product says, "I measure the value of design services in months of burn rate saved."

Design Documents Benefit the Whole Company

The essence of creating a successful business is to ensure that everyone involved is working to achieve the same goals. Any confusion or discord in objectives dissipates energy twofold. First, you lose the effort of those who are not going in the right direction, and second, their effort is applied against those who are striving in the correct direction. Like one person in a boat rowing in a direction opposite to everyone else, the boat is simply not competitive. In order to succeed, everyone must be rowing in the same direction, and any force that diverts the attention of one incurs a cost by all.

What's more, knowing with precision what you are doing helps you avoid wasting effort on things that you are not doing. No company has cycles to waste on efforts that are not right on point.

By vanquishing deadline management and feature-list negotiation, a written product description turns the company's attention to product quality, which has the inevitable result of its dramatic improvement. This in turn generates more of that priceless commodity: customer loyalty.



Inmates Are Running the Asylum, The. Why High-Tech Products Drive Us Crazy and How to Restore the Sanity
The Inmates Are Running the Asylum Why High Tech Products Drive Us Crazy &How to Restore the Sanity - 2004 publication
ISBN: B0036HJY9M
EAN: N/A
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net