Boxes And Arrows : The Design Behind the Design

Ten Quotable Moments: Challenges and Responses for UI Designers

by Brian R. Krause on 2003/06/23 | [19 Comments]

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?