Section 1.1. A MEANS TO AN END


1.1. A MEANS TO AN END

Everyone who uses a tool, software or otherwise, has a reason to use it. For instance:

  • Finding some fact or object

  • Learning something

  • Performing a transaction

  • Controlling or monitoring something

  • Creating something

  • Conversing with other people

  • Being entertained

Well-known idioms, user behaviors, and design patterns can support each of these abstract goals. Interaction designers have learned, for example, how to help people search through vast amounts of online information for specific facts. They've learned how to present tasks so that it's easy to walk through them. They are learning ways to support the building of documents, illustrations, and code.

The first step in designing an interface is figuring out what its users are really trying to accomplish. Filling out a form, for example, almost never is a goal in and of itselfpeople only do it because they're trying to buy something online, get their driver's license renewed, or install a networked printer.[1] They're performing some kind of transaction.

[1] See Eric Raymond's essay, "The Luxury of Ignorance: An Open-Source Horror Story," about his travails with a Linux print utility at http://www.catb.org/~esr/writings/cups-horror.html.

Asking the right questions can help you connect user goals to the design process. Users and clients typically speak to you in terms of desired features and solutions, not of needs and problems. When a user or client tells you he wants a certain feature, ask why he wants itdetermine his immediate goal. Then, to the answer of this question, ask "why" again. And again. Keep asking until you move well beyond the boundaries of the immediate design problem.[2]

[2] This is the same principle that underlies a well-known technique called "root cause analysis." However, root cause analysis is a tool for fixing organizational failures; here, you use its "five whys" (more or less) to understand everyday user behaviors and feature requests.

Why should you ask these questions if you have clear requirements? Because if you love designing things, it's easy to get caught up in an interesting interface-design problem. Maybe you're good at building forms that ask for just the right information, with the right controls, all laid out nicely. But the real art of interface design lies in solving the right problem.

So don't get too fond of designing that form. If there's any way to finish the transaction without making the user go through that form at all, get rid of it altogether. That gets the user closer to his goal, with less time and effort spent on his part. (And maybe yours, too.)

Let's use the "why" approach to dig a little deeper into some typical design scenarios.

  • Why does a mid-level manager use an email client? Yes, of course"to read email." Why does she read and send email in the first place? To converse with other people. Of course, other means might achieve the same ends: the phone, a hallway conversation, a formal document. But apparently email fills some needs that the other methods don't. What are they, and why are they important to her? Privacy? The ability to archive a conversation? Social convention? What else?

  • A father goes to an online travel agent, types in the city where his family will take a summer vacation, and tries to find plane ticket prices on various dates. He's learning from what he finds, but his goal isn't just browsing and exploring different options. Ask why. His goal is actually a transaction: buying plane tickets. Again, he could have done that at many different web sites, or over the phone with a live travel agent. How is this site better than those other options? Is it faster? Friendlier? More likely to find a better deal?

  • A cell phone user wants a way to search through his phone list more quickly. You, as the designer, can come up with some clever ideas to save keystrokes while searching. But why did he want it? It turns out that he makes a lot of calls while driving, and he doesn't want to take his eyes off the road more than he has tohe wants to make calls while staying safe (to the extent that that's possible). The ideal case is that he doesn't have to look at the phone at all! A better solution is voice dialing: all he has to do is speak the name, and the phone makes the call for him.

  • Sometimes goal analysis really isn't straightforward at all. A snowboarding site might provide information (for learning), an online store (transactions), and a set of Flash movies (entertainment). Let's say someone visits the site for a purchase, but she gets sidetracked into the information on snowboarding tricksshe switched goals from accomplishing a transaction to browsing and learning. Maybe she'll go back to purchasing something, maybe not. And does the entertainment part of the site successfully entertain both the twelve-year-old and the thirty-five-year-old? Will the thirty-five-year-old go elsewhere to buy his new board if he doesn't feel at home there, or does he not care?

It's deceptively easy to model users as a single faceless entity"The User"walking through a set of simple use cases, with one task-oriented goal in mind. But that won't necessarily reflect your users' reality.

To do design well, you need to take many "softer" factors into account: gut reactions, preferences, social context, beliefs, and values. All of these factors could affect the design of an application or site. Among these "softer" factors, you may find the critical feature or design factor that makes your application more appealing and successful.

So be curious. Specialize in it. Find out what your users are really like, and what they really think and feel.




Designing Interfaces
Designing Interfaces: Patterns for Effective Interaction Design
ISBN: 0596008031
EAN: 2147483647
Year: 2005
Pages: 75

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net