|
|
 |
|
This article first appeared in the June 23, 2003 edition of Boxes and Arrows. |
|
TEN QUOTABLE MOMENTS: CHALLENGES AND RESPONSES FOR UI DESIGNERSI 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. "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. "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. "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. "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."
|
|
NEW STUFF
ABOUT ADDUCIVE
CONSULTING SERVICES
|
Page 2