The Confidence Game

Written by: Brian R. Krause

How does a user interface designer know that a given design will work? How does anybody develop enough confidence in a design to move it toward the real world? The methods designers use to evaluate user interfaces require training and experience. But the people who need to hire designers are unlikely to have those skills. How do the people who are paying the bills know they are getting good answers?

“We should not be surprised that design decisions have to be sold, even the ones that designers would not find controversial.”

These questions matter because a client’s confidence comes into play when selecting a vendor, deciding whether or not to adopt a consultant’s recommendations, and even in deciding whether to hire a designer at all. We should not be surprised that design decisions have to be sold, even the ones that designers would not find controversial.

The result a client wants — satisfied users — is not something the client can know has been achieved until well after the product is finished. Yet designers are selected with their designs unseen, and approval to begin building according to a design is usually given by someone who does not have the time or inclination to account for all its details.

Learning from television

Last summer I watched a fair amount of HGTV (Home & Garden Television), the cable network devoted to makeovers of homes and gardens (just to see how professional designers in other fields work of course). I especially enjoyed “Designers’ Challenge,” in which three interior designers compete for a client’s remodeling project. The producers of the program condense the information gathering, vendor selection, construction, and presentation phases of the project into half an hour.

In the first segment, the clients explain their problem and say how much they are looking forward to professional help, professing ignorance and incompetence in interior design. They receive presentations from designers in the second segment. Part of the fun after the commercial break is to see if the clients will select the “right” designer, and how it all turns out.

Clients do not make the major decisions about their own home remodeling projects. It is the designers who decide which walls will be moved, where windows go, and where to put plumbing and electrical fixtures. Designers bring along tile, paint, and fabric samples for the clients to review. In Selling the Invisible, Harry Beckwith advises service providers to “accentuate the trivial” as a means to help people justify their decision. Though I’m sure the program is heavily edited, this give-and-take over trivia seems to be where clients develop rapport with the designer, and accounts for a big part of their decision to choose one designer over another.

The limited roles of designer and client apply to every episode, and for good reason. A designer who chose the colors and textures without consultation would stand out as arrogant and tyrannical; a designer who badgered the clients about where they think the sink should go would seem insecure, incompetent, and sycophantic.

Invariably, these stories have a happy ending, with clients effusive about their new rooms. Though the shows are produced to have a certain timelessness, making it unclear when they were taped or how long each project actually took, it is difficult to imagine that after a remodeling project involving a camera crew and television producers, a client is going to say that the ordeal was not worthwhile and had been a big mistake. It doesn’t matter who the clients are or who the designers are. The show has a format that leaves everybody feeling confident in the project’s success from beginning to end, as we should expect from a cable channel that sells design.

The Magic Fax Machine Test

The “Magic Fax Machine Test” is a thought experiment you might consider to determine the importance of the source of a design as a means clients use to evaluate it.

Imagine that a wonderful design solution appears by magic on your client’s fax machine one morning. It solves all the problems you’ve been working on for months. It’s better than anything else you’ve tried. The originating fax number and other evidence of the author’s identity is missing. The quality of the paper and reproduction is so good, it might not be a fax at all.

Reasonable people would have different reactions to using the design, but most would be negative:

  • Curiosity. “I wonder if this will work.”
  • Paranoia. “How did they get our fax number and know what we’re up to?”
  • Provincialism. “We have the brightest minds in the field.” Classic not-invented-here syndrome.
  • Skepticism. “It can’t be right if somebody is sending it for free and came up with it so quickly.”

Clearly, clients consider the source. Without a likeable, trustworthy designer, it is almost impossible to be comfortable with a design.

Cost comes into play, too. An intern’s good ideas might be unfairly dismissed as insubstantial; a high-priced consultant’s ideas as too ambitious or impractical.

Even packaging counts. Once, thanks to a case of mistaken identity, a manager at a company with a typical Silicon Valley dress code told me that the company-logo polo shirt I wore to a meeting was “unprofessional” enough to harm my chances. I thought my khakis, belt, and shoes were a notch dressier than the other men in the room — engineers who were wearing jeans — but I was apparently not consistent with other designers or her perception of how a designer should look. This was enough to keep her from remembering most of what I said and, unfortunately, my name and how my voice sounds.

A design does not sell itself, and the sales process is not entirely rational.

It surprises me that the design profession — while full of people who are knowledgeable about technology, technology cultures, and human motivation — complains so often (usually legitimately) about the lack of respect for our work. Turning to ROI and other seemingly logical or quantitative arguments to convince others of the importance of software design seems misdirected since we ought to have the skills and knowledge to make compelling arguments based on understanding what clients really want. Sales is about listening and solving a customer’s problems with available products and services. The same is true for design. As good listeners with a deep understanding of our audience and a range of skills to choose from, we designers should be good at selling our ideas, and unafraid to think of it that way.

The perfect and the good

We designers want to feel that our solution is the best one, and so we tend to evaluate client feedback in those terms, explaining why we feel a particular decision is better than the carefully considered alternatives. Is this what clients really want?

In many business situations, a client is not as interested in a solution that is the best, but instead in one that avoids risk, or the appearance of risk. Risks include:

  • Difficulty of construction
  • Difficulty adapting to conditions that might arise during construction
  • Possibility of making whoever approves the design look bad if the design is unconventional or hard to explain
  • Costs already paid for a design or for a legacy system can make it difficult to throw it out or criticize it

Planning to test a design’s usability addresses the fears of the unknown. It can show early in the process that a design is very likely to work. Of all the pieces of the puzzle, the user interface design is not the one that clients will need to worry about after a certain point. As designers, we may want to know all the ways a design can be perfected, but clients may be satisfied to know that it is good enough, convinced it is less risky than the project’s other challenges. Since managing risk is the essence of engineering practice, this approach appeals to engineers.

Pitfalls of experience

By definition, nobody on the product team is a typical user. Yet everybody tries to imagine the experience a real user might face with the product as designed. As a product develops, this tendency can lead to erosion in the team’s confidence in a design that has little to do with the design itself. Designers and clients are both susceptible.

“It is difficult to separate polite excuses from legitimate shortcomings.”

One particularly common, if dangerous, idea was popularized by Jim McCarthy’s book Dynamics of Software Development. He argues for requiring the development team to eat its own dog food, that is, to regularly use the product under development. I have been a part of teams made to follow this advice. Those who follow it seem to have forgotten that McCarthy was leading the Visual C++ team when he gave his advice. Hardly any other projects outside of programmers’ tools provide such a close match between developers and their audience.

In enterprise software projects I have worked on, sales or partnering prospects are the first outsiders to see a design in detail. Any sales process involves overcoming a customer’s objections; politeness makes it difficult for a prospective customer to refuse the product outright or to criticize the sales staff. HGTV shows only the good things clients say about designers, even the rejected ones. I would not repeat some of the things I say to the TV set if the designers were present. User interface details are a convenient target for prospects asked to explain their reluctance to buy. A salesman who declares, “customers don’t like the green buttons,” has to be taken seriously. When asked about features the designer deliberately omitted, good salesmen explain why, but also report to the development team how often the question comes up. It is difficult to separate polite excuses from legitimate shortcomings.

Designers also have to be on guard for substituting their own experience for that of real people. Again, a valuable result of usability testing is to counter the likely doubt that sets in as a design meets the real world.

Conclusion

To build the confidence of our clients, user interface designers are always selling. Before the project starts, we are selling the value of a competent design. In its earliest stages, we are selling a particular design, which often means selling ourselves as its source. As the project moves through construction, we are still selling the design’s particulars and the value of holding to a design and design principles.

Getting a client to articulate the need for a good design and good designer is just as important for software as it is for the plot of a home improvement TV show. The small details found early are an opportunity for designers to demonstrate listening and responsiveness and to build trust. A design from a likeable, trustworthy source is better than one from a Magic Fax Machine. Prior to construction, it’s more important to convince a client that a design is safe than that it is optimal. Designers evaluate designs differently than other people, but designers are skilled at understanding goals, so our clients’ goals should be easy for us to identify.

While the project is being built, engineers, salespeople, and designers have a lot of time to second-guess designs. By introducing our tools and techniques at an appropriate level and demonstrating how they are used, we build a track record and a framework for resolving questions that can arise during construction.

Sales skills are rarely identified when clients look for designers, and academic programs ignore sales skills, too. These skills are important, and designers have the basics already. What we need is the confidence to apply them.

For More Information:

Brian R. Krause started consulting on software design shortly after graduating from the Massachusetts Institute of Technology in 1990, and returned to consulting under the Adducive name in 1998. He has worked for SAP, GE Medical Systems, Nuance, Televoke, and other Silicon Valley start-ups. Though based in Silicon Valley, his work has taken him as far as England, Japan, and Singapore. His experience covers desktop and web applications, speech recognition, and touchscreen-driven handheld and custom devices.

For the last three years, Brian has spent most Saturdays honing his sales skills as a part-time salesman at Chain Reaction Bicycles in Redwood City. As a bike geek who enjoys simplicity in all its forms, he can be found racing a bike without brakes most Wednesday nights at San Jose’s Hellyer Park velodrome.

Sites: Adducive, Chain Reaction Bicycles, Hellyer Park Velodrome

Ten Quotable Moments: Challenges and Responses for UI Designers

Written by: Brian R. Krause
“Interfaces don’t become simpler by hiding information and requiring more clicks; they become simpler when they provide the right information at the right time.”I like watching how people react to software. I also like watching how people react to me: I am often the first UI designer my clients have worked with. They say the most interesting things. I’m sure you’ve heard some, too.

What are developers supposed to think about a guy who argues about color choice or which of two synonyms is the best? It’s not like choosing a sorting algorithm, is it? To many software team members who haven’t worked with UI designers before, it seems unlikely that there could be demonstrable differences in usability based on small details like those. I understand this skepticism, and my background as an engineer has helped me to figure out how to overcome it.

Whenever you come into an already established team, you will find preconceptions to confront. Even though there may be no interface yet, people have already imagined what it might be like, by analogy with other products if nothing else. To some people, there is only one way to build the interface, and anything else won’t be obvious to users since it wasn’t obvious to the developers. That’s one source of resistance to a designer’s ideas.

Another is the difficulty of talking about software interfaces without referring to something concrete. Discussion of how users will interact with software often turns to buttons, workflows, and controls, even when it’s still too early to commit to those things. So you get requirements documents that say, “There must be an Add User button,” even though adding users manually may not be required at all. To some, pointing this out and making substitutions makes it seem like we as designers are overstepping our bounds.

Effectively responding to this resistance requires understanding the real issue, and responding with tact and fact. Even though the objection or suggestion may concern a specific user interface element, the problem may be more general, like a lack of experience with software designers or discomfort with roles and responsibilities in the team. Fortunately, an explanation of the basics that we as designers take for granted is sometimes all that’s needed to clear things up.

The following ten things have been said to me by actual clients and represent common and very human reactions to a new wrinkle in the process of building software: design. I hope by gathering these comments in one place and sharing them widely, it becomes easier to recognize them, so we can keep our calm and contribute to effective software teams.

1. What they say: “Instead of arguing about it, let’s just make it an option.”

The situation: After debating two ways of displaying some data, someone suggests letting the users decide, since there are good arguments on both sides.

Uncharitable interpretation: “I want to go eat lunch now, and we really don’t have any information to guide us on this one. How can we figure out what users want until we give them a product?”

The real issue: “There doesn’t seem to be enough information for us to decide.”

The response: “Design is about making decisions, and our team is supposed to be the experts—better able to make these decisions about how the product is supposed to work than the customers themselves. Options that seem critical to developers who enjoy controlling every detail of their computers wouldn’t be missed by most users. Options should have to earn their way into a product by someone demonstrating a real need for them. As Alan Cooper would say, ‘Design is not guesswork.’”

If you find yourself in this situation, it may be useful to respond by stepping through the different kinds of users and situations to see how the proposed option would come in handy. What’s the common case? Is it overwhelmingly common, or 50/50? Are the uncommon situations essential for some reason? Explain how it would be possible to get answers given enough time, but that your hunches, if that’s all there is to go on, are generally pretty good. Customers never ask to have features removed; what’s the worst that would happen if you left the option out and somebody had to ask for it later? When in doubt, leave it out.

2. What they say: “Look, I don’t want to control every last detail, just this one. You can put the buttons wherever you want.”

The situation: A suggestion has been made to make a seemingly minor change that may ripple throughout the product, such as a change in layout standards or the name of a feature.

Uncharitable interpretation: “The last user interface designer I worked with seemed to spend a lot of time moving buttons around. In business school, they taught me to begin discussions like this by conceding a point and recognizing your competence.”

The real issue: “Our understanding of our roles and responsibilities is different.”

The response: “Where the buttons go is usually decided by standards, and is not the most valuable service designers provide. It’s one detail among many that go into the design. User interface design is about details—very specific decisions that need to be internally consistent, and it is much better for those details to come from one source. Take wording as an example: It can come from design, or from marketing, or from the technical writing department. It will be slightly different depending on who does it, but it will be internally consistent if it’s handled by just one person. If it’s the responsibility of several people, then several people have to meet for several hours to consider the ramifications of a single wording change. If several people are qualified, let’s choose one to make the final call, and trust that we’ll all coordinate.”

3. What they say: “All we have to do is pop up a dialog box and ask the user.”

The situation: A function call deep in the code requires a parameter whose value is not available when needed.

Uncharitable interpretation: “I’ve found a way to get what I need in one line of code! My computer pops up hundreds of dialog boxes a day and I don’t even notice. All external information must come from the user anyway; it doesn’t matter when we ask.”

The real issue: When it’s so easy just to ask, it’s hard to consider inspecting the state of the computer or asking the user at a more appropriate time and remembering the answer.

The response: “The solution may not be a dialog box. It may not pop up. We may already know the answer. We may not need to ask. The user may not care, and may give the wrong answer. Lots of people take dialog boxes seriously—they interrupt and make users feel they’ve done something wrong.”

Still, the burden is on you, as the designer, to show that anything more complicated than the one-line solution can really improve the user’s experience enough to be worth the effort. This is especially a problem with installers, for example. Installer requirements are often not known until the last minute, installers don’t get much time on the schedule, and they are by definition not frequently used. For installers, you can always emphasize the importance of first impressions—the out-of-the-box experience. With other tasks, explain how much of an interruption a dialog box can be.

4. What they say: “Don’t you want a list of all the error cases?”

The situation: You are starting a project, and the rest of the team is trying to bring you up to speed by supplying all the information they have.

Uncharitable interpretation: “I don’t see how anyone can understand the project without understanding the edge cases and problems as well as I do. Plus, the error list is one part of the design documentation that’s actually finished!”

The real issue: “A design that doesn’t address every possible situation is incomplete.”

The response: “Let’s focus on the ways the program will work and what it will do for as long as we can get away with it. There is not usually a shortage of people to point out edge cases when the time comes, so let’s pay attention to the user’s experience when things go well. Someday the product will be debugged, and, for the user, things will go well most of the time. By all means, let’s look carefully at the errors that we know will be common, but work to make success the most common experience for the user. The alternative is to build an application that is always complaining about invalid input and less than ideal operating conditions.”

5. What they say: “That’s not how eBay does it!”

The situation: A proposed design catches another team member by surprise, most likely because it is out of line with preconceptions.

Uncharitable interpretation: “You’re not the only one who can cite third parties.”“Asking someone to register for a product they don’t know they like yet is a good way to get them to lie.”

The real issue: “I don’t see why what you’re proposing has to be so different from what I’ve been thinking of all along.”

The response: “There is no halfway reasonable solution to a user interface problem that can’t be found somewhere. Yes, following the lead of successful and appropriate interfaces, especially if they are popular like eBay or Microsoft products, is a good idea.”

Explain why eBay isn’t doing exactly the same thing, or why their approach isn’t the best. Sometimes it’s possible to do better than Microsoft.

6. What they say: “I don’t think it’s confusing.”

The situation: Version 1 of a product was successful and has customers and customer support staff who know how to use it. People in the company like it. However, your first impression as a designer, often the most valuable impression, leads to some suggestions for improvement.

Uncharitable interpretation: “We’ve had people using it this way for years! As the industry leader, our quirks are now the industry standard.”

The real issue: “You’re pointing out a problem we didn’t even think was a problem.”

The response: “As someone who has just worked with the product for the first time, I noticed some room for improvement. We could do usability testing to find the same things, but that takes time and money that is better used on more subtle problems. Hardly any interface is unlearnable, after all, and you can’t rely on staff or existing customers to learn where new customers will be confused. Even considering their short-term pain, I think change is warranted.”

Remind the team why you’ve been brought in for this next version. Even if usability isn’t the main problem with previous versions, adding new features will affect current habits.

Unfortunately, first impressions come fairly early in the relationship with a software team. There isn’t always a basis for trust at first, and a comprehensive criticism of what is probably a successful product—good enough to deserve being upgraded—is not a way to become popular. Take notes so you remember those first impressions, and prioritize the suggestions. Start with problems you can find other evidence for; those are likely to be the big UI problems anyway. Do this before you recommend killing off the quirky details that everybody else has grown to love.

7. What they say: “Dumb it down—these aren’t very sophisticated people we’re dealing with.”

The situation: The actual users are separate from the people who decide to buy or develop the software. They may be in different worlds according to their work location, educational background, computer experience, or clout in the organization.

Uncharitable interpretation: “How can users understand something that’s taken you so long to explain? Simple means very sparse screens, colorful icons, and big fonts, like children’s software. Guide them through one step at a time.”

The real issue: “I’m suspicious that these users will ever be able to figure out something that isn’t instantly clear to me, especially something with a complex implementation.”

The response: “No matter how little education or computer background customers have, they know their jobs. A particular multivariate schedule that makes little sense to us makes a lot of sense to our users, because they know what to look for and what they’re trying to achieve. Very few step-by-step procedures turn out that way in the real world. Interfaces don’t become simpler by hiding information and requiring more clicks; they become simpler when they provide the right information at the right time. Sometimes the logic to do this is complex.”

Of course, when you’re learning about the actual users, you want to make sure that you have visited the actual users in as realistic a setting as possible. It may not occur to others why a lofty software designer would want to hang out in a filthy warehouse for a day, but I’ve always found support for this kind of visit once I ask to do it.

8. What they say: “We have to force them to, in as friendly a way as possible.”

The situation: Registration or security requires the user to answer questions or make up a user name or password.

Uncharitable interpretation: “If pesky people just behaved like machines and followed orders, it would be a lot easier to write software.”

The real issue: Allowing things to happen in any order complicates the internal state of the system. This has to be justified.

The response: “Computers can’t really force a person to do anything. When they try, they are annoying. If they get too annoying, people will find ways around them, which probably defeats your purpose. For example, forcing a person to change a password when the computer chooses, as opposed to when it makes sense for the user, is a good way to increase the chances it will be forgotten. Asking someone to register for a product they don’t know they like yet is a good way to get them to lie.”

The best solution is to make the step optional and the software able to continue with incomplete information. If the step is really easy and short, most people will do it. The trick is figuring out exactly what the step is required for and how to make it as painless as possible to complete. Is it really necessary for all users to go through it? Is there a more natural time to ask, when the user is more motivated to answer?

9. What they say: “You and that Nielsen guy don’t think websites should be any fun!”

The situation: A proposed color scheme, interface widget, or BiCapitalized marketing term has an adverse influence on usability.

Uncharitable interpretation: “We’re just trying to have a little fun and enhance our brand, and you’re being arbitrary. I really don’t want to go to my manager about this detail. Just say it’s OK, please?”

The real issue: “I find it hard to believe you can quantify a usability effect without even trying our suggestion.”

The response: “If the question is the usability of this design, I feel obliged to tell you that there is a tradeoff. A certain number of people will have a harder time because of this decision. Will more people be helped by it?”

Objective measures might help. For instance, it’s easy to find numbers about percentages of colorblind users or minimum font size requirements for people over age 45. It’s even possible to say how many users will ignore hyperlinks that don’t include underlines. The forces of cool find this threatening. Sometimes all you can do is inform them, and wait for the fad to pass.

10. What they say: “Can’t we make it red so it stands out more?”

The situation: A member of the team has just complained that some part of the interface is missing, when in fact it still exists but has been relocated in the interface.

Uncharitable interpretation: “Every time I get confused, that’s a reason to change the design. I’m the CEO, after all. The basics are probably fine, so here’s an easy superficial change.”

The real issue: “This is an important part of the interface and I’m afraid people might miss it.”

The response: “What you missed isn’t supposed to stand out in normal use. Not everything in an interface is supposed to be obvious upon first impression, and the context of using a product for real is quite different than the context of reviewing a UI mockup. Some things are more important than others. If we gave everything equal visual importance, nothing would make sense. We can’t change the design every time a member of the team gets confused.

“That said, sometimes things in the first draft of an interface don’t stand out enough. In that case, the field of visual design offers many solutions that keep an entire interface from becoming one red, boldface mess, and there may even be ways of putting things in context better. The right solution may not be to make everything red; we may not even need to make a change at all.”

Just the Top Ten
This list is by no means complete. Every project has its quotable moments, and I have not handled all of these in the past exactly as I now recommend. In fact, thinking about these moments again will help me next time they come up.

What are some of your quotable moments, and how would you handle them if you had another chance?

Brian R. Krause started consulting on software design shortly after graduating from the Massachusetts Institute of Technology in 1990, and returned to consulting under the Adducive name in 1998. He has worked for SAP, GE Medical Systems, Nuance, Televoke, and other Silicon Valley start-ups. Though based in Silicon Valley, his work has taken him as far as England, Japan, and Singapore.

Getting Creative With Specs: Usable Software Specifications

Written by: Brian R. Krause
“By abandoning the traditional idea of a spec in favor of a usable spec, you can deliver something that’s fun to show off, easy to understand, and confidence-inspiring.”Building architects don’t have to think much about what the actual deliverables are to contractors and their clients, because their industry has traditions and standards for blueprints, balsa wood models, and computer-generated renderings. As user interface consultants, we have to think about this anew for every project. Each project is a little different and each client has different needs and preferences. Over time, this has given me the chance to evaluate the effectiveness of the different kinds of user interface specifications I have produced and used.

First, let me define what I mean by “effective.” An effective spec must be inviting and easy to understand so the whole development team can participate in the design. This way they can catch any problems, and their support can be won early. If a spec is so technical that only engineers can understand it, the marketing department will not feel part of the audience and will not look at it carefully. If a spec is not detailed enough or if the details shown are irrelevant—like unrealistic placeholder data—the spec will be taken as a suggestion and not the blueprint for the user interface. A spec must be detailed, but not too detailed.

An effective, usable spec therefore serves two main purposes: First, it elicits feedback early, which helps to avoid problems and misunderstandings later on. It’s especially important that clients are able to identify any missing functionality in the design, for example. Second, an effective spec ensures the software stays in line with the designer’s intentions as it?s built—in other words, the spec is precise enough that a competent engineer will build the interface as it was designed.

What’s wrong with the traditional spec
For many people in the industry, a large paper document with lots of tables and cross-references is what immediately comes to mind based on the success criteria I just identified. For some managers, it is hard to imagine anything else, so you may encounter resistance toward new approaches. But there are some problems with traditional specs:

First of all, maintaining such a spec can be nearly as complex as maintaining the software it’s supposed to specify. The traditional spec is often too technical and the level of detail too great to keep it in sync with changes. Because of this, in my experience, complicated traditional specs are abandoned quickly. When that happens, the spec is no longer authoritative, but a collection of out-of-date suggestions that are easy to ignore.

The level of detail in a spec should be significantly less than the level of detail in the implementation. A common reason to insist on a detailed document is to make sure that every error condition is covered. I submit that the user interface designer’s job is to cover the common cases well. This includes common errors, but not all possible errors. Obscure error cases should be handled without involving the user, anyway. A spec built around error cases makes it hard to see the forest for the trees. Programming languages are much better suited to this level of detail than English.

If you need to seek approval for the design, a long, highly technical document can scare busy executives and marketing people into procrastination. They have difficulty finding large blocks of uninterrupted time to review it, and it’s usually a chore you have to nag them into performing.

By abandoning the traditional idea of a spec in favor of a usable spec, you can deliver something that’s fun to show off, easy to understand, and confidence-inspiring.

Getting creative
To create a usable spec, ask yourself the same questions you do when creating usable software: Who is the audience? What are they capable of understanding? What will get them involved? Once you know the answers to these questions, you can create a spec that truly meets everyone’s needs. Don’t be afraid to think outside the box. Here are a few examples of nontraditional specs:

Demonstrate real interactions
Why can’t a spec include an audio recording? When putting together specs for telephone-based speech recognition systems, for instance, I have found this to be one of the best ways to get feedback. An audio recording can realistically portray a typical interaction with such a system. Ideally it uses professional voice talent and the same production standards as the final product. But as long as the caller and the voice of the system can be distinguished, this is not strictly necessary. A written script—like the script for a play, not the type in programming languages—also works well. Be careful though: most voice application designs are reviewed on paper, where the tone is more formal, which leads to telephone systems that sound stilted instead of conversational. But either way can be much easier to understand than a complex technical document.

Make every detail count
For a graphical interface, prototypes are useful, but not often considered a specification. In order to function well as a spec, a prototype must be detailed and use example data that has been carefully chosen to reveal key details about how the system works. You will have to explain that the prototype is meant to specify the system’s behavior and appearance exactly, to the pixel, and spell out the few cases where the prototype does not cover things completely. But much of what would be verbiage in a traditional spec is implicit in a prototype. In a sense, a prototype can help you achieve selective disclosure: people who want a high-level overview can glance at it, and those who need to understand the details can ponder the ones you’ve provided.

Speak the developer’s language
To get your design built the way you intended, the closer the prototype matches the developer’s construction tools, the better. HTML leads to code much more readily than Photoshop, for example. In any case, the level of detail captured in a prototype or pixel-accurate screenshot is much easier to understand than if you wrote the 1,000 words every one of your pictures is worth.

Make the invisible visible
Sometimes, when the behind-the-scenes behaviors of a system are especially complicated or especially interesting to the audience for the spec, it’s useful to make them visible. Draw the database table in a debug window and show the information being inserted. Good developers tend to do this, though often by just spewing text messages to a window somewhere. It usually takes only a little extra effort to make the normally invisible modules visible, and if it takes a lot of effort, you are probably discovering bugs in the process!

Mapping it out
In addition to providing the most accurate screenshots, recordings, and other artifacts you can produce, it’s also important to provide a map of the system. I have noticed that the best developers do this, too. What is a map? A map shows the interrelationships of the important screens, states, or programs, and also serves as a to-do list for the user interface programmer. It is usually one or two pages—small enough that it can be viewed in its entirety in the free space next to your keyboard. It is a printed document, needing the full resolution and permanence of paper.

The map can be screenshots with arrows linking them, a quick reference guide listing commands, or a state transition table. It can be primarily visual, or mainly text, depending on the project and the developers. Again, a single artifact can provide an overview or important details, depending on what the developer needs at the time.

Other benefits of usable specs
Usable specs can also be helpful in usability testing, marketing, and to crystallize leadership. You can even get the manual finished at the same time as the product.

A well-crafted usable spec can be easy enough even for potential users to understand, so they can be valuable tools in usability testing. For example, full-blown prototypes can be put to use almost immediately to get feedback on the most common tasks. An audio recording can be broken apart and played to potential users to get reactions. Showing screenshots in sequence can be a good way to get users to talk through problems.

Marketing and sales always want the product before it is ready. Since a usable spec is meant to match the system’s outward appearance and behavior exactly, it can be used in presentations and collateral. This has the added benefit of locking in the design, by reigning in the tendency to request changes while it?s being implemented.

Software projects often lack a tangible way of gauging progress. The user interface is the most tangible part of a software project and the most closely tied to the customer. Members of the development team can use the spec to understand how what they are building will serve the needs of real people, as well as how close they are to being finished.

Once a usable spec is complete, user documentation can be written. The technical writer is the first non-engineer who has to understand the complete system in all its detail. He or she can use the spec to find conceptual problems early—something that’s hard to explain is probably not easy to use or build.

Cost and effort
The cost of producing a usable spec depends a lot on how comfortable you are with the tools developers use. A pixel-accurate Photoshop document will serve a web developer well, but HTML can serve as scaffolding to get them up to speed even faster. An audio file representing a phone call is useful, but you can clarify many of the system’s operations implicitly using a sequence of files whose names have been carefully chosen to coordinate with the sections of the map you provided.

My own background is in programming, but I don’t provide production-quality code as a design artifact. I’ve provided audio files, HTML, Visual Basic prototypes, and even plain old graphics with some written notes. I have found that the more technically capable my client is, the less technical my deliverables need to be.

You might be wondering if you can combine a usable spec with a traditional one. I don?t recommend it. Maintenance is one issue. Authority is the other. It is difficult to manage updating multiple artifacts during the iterative part of the design phase. And you want just one artifact to serve as the source for settling questions about how things are supposed to work.

Finally, as clear as your deliverables may be, you will still need to explain precisely how you mean for them to be received. Recognize that a nontraditional spec will be new for everybody involved, and that you will have to answer questions about the process and explain some things a few different ways—everybody absorbs information differently. This takes diplomacy, and I find it easier to be diplomatic while showing someone a picture than citing chapter 3, section 2, subsection 4, paragraph 5, the second table.

Usability applies to our deliverables as much as to our designs. Creating a usable spec is an excellent way for us as designers to make things easier for the rest of the team. In my experience, this effort is appreciated and rewarded with cooperation and greater appreciation for the importance of our work.

Brian R. Krause started consulting on software design shortly after graduating from the Massachusetts Institute of Technology in 1990, and returned to consulting under the Adducive name in 1998. He has worked for SAP, GE Medical Systems, Nuance, Televoke, and other Silicon Valley start-ups. Though based in Silicon Valley, his work has taken him as far as England, Japan, and Singapore.