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.
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.
- Beckwith, Harry. Selling the Invisible: A Field Guide to Modern Marketing. Warner Books, 1997.
- McCarthy, Jim. Dynamics of Software Development. Microsoft Press, 1995.
- Harding, Ford. Rain Making: The Professional’s Guide to Attracting New Clients. Adams Media Corp., 1994.
- Hohmann, Luke. Journey of the Software Professional: The Sociology of Software Development. Prentice Hall, 1996.
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
Hi Brian, Great article! I especially agree with the part about we (the designers) should be always selling and promoting good design process. ( we don’t do this enough – for variety of reasons)
Over the years as both designer and client, I have noticed some of the designers lack ability to communicate effectively to senior management or customers about their design decisions and proposals – I think this is due to not understanding the business and technical side well enough.
Design question related to the article: Why aren’t the links right in the body text? That is, why are the references (and links) at the bottom of the page?
John, many articles at B&A have followed this convention of including references at the end. In this case, it seems especially ok, since it’s just a few links to Amazon.
I like this article, it emphasizes the normally under-emphasized CRM aspect of selling and providing design services. And a good project manager made me realize (if not purposefully) that it was not design he sold, but confidence in a designed solution. This kept us both busy.
Mr. Krause says, accurately; “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.” But, wait… there’s a gap here. That is, a gap between the common client’s ability to recognize well applied design principals and the designers ability to do so. Afterall, designers have spent years learning, practicing and continually evaluating what principals to apply to which effect given each project’s context. Presumably so that clients will have the benefit of all that, without having to learn to do the same. Thus the addage, “Good client’s make good projects.” So while it’s important to please clients, often in their ignorance (if only for survival’s sake), it is equally important to continue to educate them to whatever degree they are receptive to (diplomatically, of course), as part of this sales process. So that their ability to evaluate a design and their appreciation of good design work will grow. As one designer, with a lot more experience and success than I, once put it to me, “Mostly we’re just talking to each other” (designers tend to want to please each other as much as their clients, who often simply miss the point). The bottom line, I would re-title this useful article: “If they don’t like you, make them trust you. If they don’t trust you, make them like you. But best is to do both.” Which is not bad advice either, is it?
I like this article, it emphasizes the normally under-emphasized CRM aspect of selling and providing design services. One good project manager made me realize (if not purposefully) that it was not design he sold, but confidence in the whole design project and its process. This kept us both plenty busy.
But what about the adage “Good client’s make good projects”? That is, while we’re always “selling the design’s particulars and the value of holding to a design and design principles,” this says nothing of a client’s ability to recognize, thus value, design principals or their application. Thus educating some clients, to whatever degree acceptable to them, continues to be an important part of this sales process, too.
PS. twice posted (once edited) article result of 404 error returned by comments.cgi on “Post.”
When does a confidence game become just a con?
Ron asked:
> When does a confidence game become just a con?
It’s a con when there’s no substance behind it. The title of the article is meant to remind us that in the extreme case, confidence can be won independently of whether confidence is deserved.
Certainly, designers have the skills to mislead and deceive. That’s not the only ethical concern we deal with. For instance, at a BayCHI talk, Jef Raskin pointed out that most computer-related repetitive-stress injuries are caused by mouse use and not keyboard use, so designers can even cause physical pain by making incorrect (or I suppose malicious) decisions.
As a profession, we understand what it takes to persuade and inform, but we often stop short of applying that knowledge to the business and practice of design. Possibly we think it’s not ethical. Maybe we think we can be “caught.” We like to think that since we can see through and dissect these techiques, so can everybody else. We are probably giving ourselves (and others) too much creditpeople in the software field are not exempt from basic psychology or immune from proven sales techniques, even when we recognize them.
If you have the skills and knowledge and believe in them, using the means at your disposal to promote design is not just the way of business, but a fact of life.
Thanks for the response, Brian!
“It’s a con when there’s no substance behind it.”, says Brian.
Great! Where’s the substance?
Referring to the first paragraph of the “Conclusion” section of the article:
“Before the project starts, we are selling the value of a competent design.”
What’s “competent design”? I sell the value of what my team has been able to accomplish in the past while suggesting we can do the same for the prospective clients’ specific situation. I don’t find much substance in talking about “competent design” and neither do my prospective clients.
“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.”
Excuse me? Sounds like the so-called designers never gained the confidence of their client. Perhaps they don’t deserve it? Perhaps the client has serious misgivings about them? Where’s the substance?
Ron asked,
> What’s “competent design”? I sell the value of what my team
> has been able to accomplish in the past while suggesting we
> can do the same for the prospective clients’ specific situation.
> I don’t find much substance in talking about
> “competent design” and neither do my prospective clients.
Just like the designers on HGTV don’t say, “Now I am going to pick out paint samples with you so we can develop rapport,” UI designers don’t talk about “competent design,” but rather they, as Ron does, demonstrate that they have listened to a client’s problems and pull examples from their past experience to show that they have solved similar problems in the past. I can’t give generic substance. By “competent design” I meant the same thing I said in the introduction, a design that satisfies the client’s users. It may be obvious to us as designers, but reminding people that they are in business to satisfy their own customers should not be considered too basic to overlook in a sales presentation or proposal. Usually clients will give you good reasons for needing your services, but you’ll get different answers from different members of the team. Until they get into the process of hiring a designer, teams probably don’t have a complete list of problems and goals.
> Excuse me? Sounds like the so-called designers never gained
> the confidence of their client. Perhaps they don’t deserve it?
> Perhaps the client has serious misgivings about them?
> Where’s the substance?
Confidence is not absolute. Team composition changes constantly. I wish it were enough to convince one key person just one time, but in my experience, developers and other team members are enthusiastic about cooperating when they understand the benefit to their users, but it’s easy to lose sight of this in the middle of coding. For the reasons listed in the article (and probably some more), it’s not enough to just stop selling once the design is turned over.
This could apply in some cases, but roles are now changing. The Designer may now have moved onto the other side of the table and hiring firms to do this work. If so, the dialog begins to get far more interesting.