THE CONFIDENCE GAME

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?

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.

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.