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.”
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?
Alogn these lines, I highly recommend Paula Scher’s Make It Bigger http://www.amazon.com/exec/obidos/ASIN/1568983328/eleganthack
Lots of insight into helping nondesigners understand design and the design process.
Excellent list that I now have to share with all people involved on my project.
I’m also a big fan of “Don’t Make Me Think” by Steve Krug that gives a no nonsense approach to what usuability is.
Wonderful article. I can’t count how many times I’ve heard all this. Glad to know I’m not crazy.
The “We have to force them to, in as friendly a way as possible” is by far the most common one I get. It is apparently impossible to make some folks see that they are not the users and the users will not have read the site’s plan and documentation. Great list!
Thank you! Great fun to read an article about my everyday work life! Will read the article every time some of the programmers start this kind of conversation with me. Give humour a chance!
excellent post… buttresses the need for problem statements being as abstract as possible coupled extensive–even complete–requirements engineering
This doesn’t offer as much constructive solution, but I get a big kick out of browsing this every day:
http://www.derailer.org/clientquotes.php
Nice. This list along with Coopers “Inmates are running…” will be a good combination…
Within an hour after this article went live, I got the following e-mail from a client. (I asked for permission to post it, and the reply granting permission got snagged by a spam filter!)
Anyway, I am not making this up!
> 2. After seeing our online … demo, … and … both
> suggested that the … UI should have the active tab in
> a different color. Right now it is not clear which tab you are on.
This has been brought up before. Our UI expert (Brian) replied that it
was intentional that the difference is subtle. I don’t remember the
exact argument, but the gist was that the focus should be on the main
form where the user will input his values, and not on which active tab
he’s on.
Why should the user always be reminded of what tab he is on? He should
select the tab he wants, then go to work on the page, and not be
distracted by what active tab he’s on. In addition, sometimes the page
doesn’t belong to any tab (e.g. query results) and it might confuse a
user who is used to seeing a highlighted active tab.
I think sometimes good UI principles conflict with what people are used
to and therefore expect. What do we go with in such a case?
Brian, would you like to chime in? I hope I did your reasoning justice
🙂
My response:
You got it right. Especially the part about some pages having an
obviously highlighted tab and some not.
You also got it right that good UI principles should result in
software that does what people expect and are used to, except I was
trying to do that here!
I believe that what people are used to is the 3D shading on a tab
changing when the tab is at the front, which is exactly what happens
in Windows. The Mac makes a more dramatic color change. Websites
vary in what they do.
I will add two minor points to what you said. First, people will be
looking at the … UI for long periods of time, and a tab that calls
attention to itself will be somewhat tiresome. Most users will be
regular users. So, I would tend to discount … and …’s reaction if
it is a first impression, which I gather it is, from the demo comment.
In the context of using the system, and using it regularly, I don’t
think it’s an issue.
Second, the tab being active means “You’re already on this page; don’t
click this tab.” Calling attention to the active tab, the one you
can’t click on, would invite people to click it anyway. The current
shading shows what you can’t click on without making a big deal about
how you can’t click on it.
My favorite bad UI moment came several projects ago, when the team leader enthusiastically presented to us his proposed UI solution for rendering complex task information “intuitively understandable by any normal end-user.” Ignoring our growing incomprehension, he continued his tortuous explanation until one brave soul suggested that his solution was not intuitive at all. At that point, he turned to momentarily consider the convoluted mess he had made on the whiteboard. Then aiming his angry glare back at us he shouted “Well, look at it until it becomes intuitive.”
Truly not just any old inmate was in charge of this asylum. This inmate was criminally insane.
Thanks for this excellent list!
It’s amazing how people think they can design interaction even if they have NO training, tools, experience, responsibility, interest or aptitude.
My favorite comment is, of course: “Somebody might want…”
thanx,
Alan
Great article, I got several wonderful laughs from the Uncharitable interpretations.
With respect to number 3, I’ve started to think about dialog boxes in the same way as I think about goto statements in code. That is they are disruptive and often hard to recover from (as a user).
My thinking follows directly from comments that Alan Cooper made in the Dialog Boxes chapters of both versions of About Face.
I look forward to more comic relief in the future.
Read this just after our President said, “Let’s make all the links bright red!”
I sent him that piece of the article, now he’s actually stopping himself before insisting on bigger icons or flashing buttons.
Loved the list. Especially the “let’s make it an option…” I often find that a little “mother-in-law” research, polling 4 or 5 people who generally fit the user profile, and doing a quick usability test based on some simple paper prototypes can usually be very effective in arguing your case. I can usually resolve the issue within a day. Often, when faced with the prospect of such testing, many of the “I don’t want to control everything, just this little bit,” type will back down.
I have to confess that I have very little respect for those who base their assertions on the “trust me, I’m an expert,” method of persuasion. (So when the tables are turned, I cannot blame them) If I cannot convince the powers that be on a particular interface design issue based on merits, a bit of quick research is often better than a flurry of emails to get an issue resolved.
Eric
I was nodding my head the whole time I read this article. I’m not sure about other designers that work in-house, but recently things have started to change. With a lot of projects, the UI buck stops with the designer. So although you get the comment “Hey, can you add a big button up top for this so that the feature stands out more?” it doesn’t really matter because in the end I get to make the final call. My typical response these days is “I’ll do my best within such and such constraints.” Even if it’s a dumb idea, I don’t argue; I just say I’ll do my best.
I admit the “trust me, I’m an expert” method is not very persuasive, so I tried to suggest other means of persuasion.
However, my hope is that these suggestions move the relationship along so that clients and employers come to trust UI designers to handle small and large decisions.
Testing is useful when the designer doesn’t know the answer, and of course for complete designs to find those problems where the designer didn’t know that the designer didn’t know the answer.
I hope that sharing these quotes and pointing out that they are common cuts down on the lengthy meetings or days spent testing just for the sake of persuading the rest of the team, though I realize they can’t be eliminated completely, and other members of the team are just as entitled to their skepticism as I am to mine.
a very good read. as a UI Designer, two favorite scenarios of mine are: 1. when users, BSAs and managers spend hours in meetings trying to decide what button, menu, control or widget to “design” while trying to determine EARLY business requirements; and 2. when clients and decision-makers intentionally hold back on giving me requirements because they don’t want to “thwart my creativity”.
in case #1, before I lose my mind, I take a deep breath and say, “why don’t we concentrate on WHAT it is right now, rather than trying to design how it LOOKS? we don’t have all the facts yet concerning what else will be on this screen…”
in case #2, I smile graciously and say, “why thank you, that’s very thoughtful. but I really need to know WHAT it is I will be designing, before I can get creative with it…”
both of these tacks usually do the trick. 🙂
— mercury shell, Mercury9.com
a very good read. as a UI Designer, two favorite scenarios of mine are: 1. when users, BSAs and managers spend hours in meetings trying to decide what button, menu, control or widget to “design” while trying to determine EARLY business requirements; and 2. when clients and decision-makers intentionally hold back on giving me requirements because they don’t want to “thwart my creativity”.
in case #1, before I lose my mind, I take a deep breath and say, “why don’t we concentrate on WHAT it is right now, rather than trying to design how it LOOKS? we don’t have all the facts yet concerning what else will be on this screen…”
in case #2, I smile graciously and say, “why thank you, that’s very thoughtful. but I really need to know WHAT it is I will be designing, before I can get creative with it…”
both of these tacks usually do the trick. 🙂
— mercury shell, Mercury9.com
A reassuring read. Our head of engineering used to say to my colleagues that my job, as a UI developer, was to “make it pretty”. I left soon thereafter.
When faced with the more maddening aspects of UI development, my stance is always to remind co-workers that it’s not their opinion (or mine) that carries the greatest weight, but the customer’s…after all, they’re paying for everything.