SD杂志设计专栏:Ease-of-Use Equals Use
By Aaron Marcus
Picture this scene: 20 people are gathered around a conference table for a two-day meeting. Three groups, with their respective managers—developers, line-of-business staff and system users—are jockeying for proximity to the power-people, as well as time to speak. The objective? To review a first draft of screens representing use cases and detailed workflows of a new internal Web portal for an enterprise’s complex financial documents. Users will consult and manipulate this data to serve customers effectively. The data and business processes are vast and complex, including obscure, inconsistent, inherited terminology and procedures that are the inevitable accretions of mergers, reorganizations, errors and time. What’s at stake? The end customer’s as well as the system user’s satisfaction with a crucial Web-based application.
What’s right with this picture? The data analysts have done their homework—as they understand it. They’re following the best practices of comprehensive, integrated software development. They’ve identified the users, their data needs, the use cases and the flow of information—as they understand it. They’re developing templates for data display and the users’ interactions with them—as they understand it. Everyone gathered around the conference table agrees—the group seems to be getting a grip on the monster.
What’s wrong with this picture? Unless professional user-interface developers are present, several things will probably go awry, as I’ve witnessed in such pow-wows:
- IT and business personnel are likely to dominate the discussion. One or the other is usually in charge of the process.
- Users may feel intimidated, especially if presented with technical use-case and workflow documents.
- Users may be talked over, talked down to or asked rhetorical questions, but not be allowed to evaluate and express what’s really right for their purposes.
- Users may be assigned the responsibility for providing not what they need, but what the data analysts desire, and the users may not even recognize this inevitable bias toward the “back end,” not the “front end,” of the user interface.
- More fundamentally, users may never have been asked some key questions that lead to a better understanding of their work needs.
Recently, in an informal, 30-minute gathering with users following such a meeting, I learned some key success criteria for their use of the software that had never been mentioned in any of the documents discussed at the meeting. Ferreting out this crucial information took some respectful and gentle prompting. Especially vital were the need for fast performance in working with multiple document sets sequentially and sometimes in parallel, and the need for comprehensive help systems to assist temporary staffers unfamiliar with company procedures. Even though the IT people assumed that good performance and some documentation were appropriate, they neglected to collect information that revealed how critical these user needs were.
Focus on User Experience
The International Standards Organization (ISO) defines usability as “the effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments.” I take that definition one step further to include the enjoyment or pleasure that users derive from useful human-computer communication and interaction. This last aspect, the user experience, involves usability, branding and culture. User-Centered User-Interface Development (UCUID) affects user satisfaction in ways that immediately impact the bottom line: more efficient production, fewer calls to help centers and more devoted customers.
The UCUID process consists of steps similar to those in software development: plan, research, analyze, design, implement, evaluate, document, train and maintain. But while the software development approach tends inevitably toward data-centered methods and solutions, UCUID is user-centered in theory and practice. Each of these progressive steps involves the user interface itself—its components (metaphors, mental models, navigation, interaction and appearance)—not the data or code. Each step produces knowledge that can assist with the next one. Remaining mindful of essential usability principles at each step helps to ensure the creation of usable, useful and appealing products or services. Some of the basics derive from human factors research, such as keeping things simple, clear and consistent; limiting choices appropriately; and revealing complexity at the right time. But how do you know when to show what, and to whom? Ask the user the right questions early on. It goes without saying that you should interview real users—not managers, but those in the trenches making regular, daily use of software. Then construct your user models based on the interviews followed by a detailed task analysis. Here’s how.
Interviewing
I always advise that a small group of UI developers start by interviewing users, recording observations, creating user models and presenting them effectively to the rest of the development team.
To prepare for these interviews, brainstorm a list of five to nine different user types based on known information or any contact with users—without going into detail. Plan what you want to learn from users and design a set of interview questions. Each interview may last only 20 to 60 minutes. Be prepared to take notes or capture the interviews with audio or video. Some typical high-level interview questions are:
- Can you tell a few stories that are typical of your actual use of the system?
- What makes a good or bad experience with such systems?
- What are the critical success factors on which you are evaluated?
- How are these related to your use of the system? Detailed interview questions may include the following:
- Can you describe particular problems you were trying to solve?
- Can you describe the people/roles involved?
- What steps were taken to solve the problem?
- What constraints were there (for example, time, budget and so on)?
- What information do you need to make decisions?
- What was produced?
- Were you satisfied with the outcome?
- What activities or conditions waste your time?
- What are your typical problems, challenges, pain points and pleasure points?
In these interviews, be prepared to summarize key functions and data for the users. These may have been prepared by marketing, business or engineering staff. Be on the lookout for new, hidden and potentially valuable additional tasks and content. Typical functions might include the following:
- Searching and browsing for desired items by content (type, brand, date/time, price or other criteria).
- Saving named sets of items for later reuse.
- Viewing items to be processed in some way; for example, items to be delivered.
- Scheduling items using different delivery options (weekdays only, express and so on).
- Viewing news and documents by subject matter of interest to the user.
- Creating a profile of preferences that makes the software application easier and faster to use.
- Viewing recommended and related items.
- Viewing content details such as prices, history, special conditions, parts or special items.
- Viewing comparisons of selected items, attribute by attribute.
- Allowing easier methods for the user to navigate very large sets of items.
User Modeling: Creating a Profile or a Persona
User models, also called personas or profiles, enable you to do task/need analysis and quickly present your core understanding to all stakeholders. Knowing essential types of users well helps the UCUID team stay focused on the most important key stakeholders: the users.
Based on your interviews, model at least three user types—they won’t necessarily correspond directly to your interviewees, but select one primary user type as the focus of your UI development. The persona itself should resemble the following:
| Title: Customer Support Representative (CSR) Photo: (Use a stock photo to illustrate) Slogan, name and age: “I like to talk, but I hate to write.” Susan, Age 27 My Goals (needs, desires or job responsibilities):
My Environment (working circumstances, organization’s culture or customs):
My Behaviors (characteristics, psychographics, expectations or usage patterns):
|
Personas help prevent the development team from drifting as marketing, business and engineering all voice their requirements, suggestions and complaints.
Use Scenarios and Task Analysis Based on your personas, you can write two or three realistic use scenarios to be evaluated by users and other stakeholders. Include all the tasks you can think of; consider new tasks as well as those suggested by any documents from marketing, business or engineering. Here are some suggestions:
- What are the task dynamics (for example, the experience of the task over time)?
- What triggers a task?
- How interruptible is the task?
- What tasks are performed together as an activity?
- How often does a task occur?
- What is the duration of the task? Are there time constraints?
- What is the intensity or volume of work?
- Does a task need to be completed immediately, or at will?
- Are task reminders necessary? Which kind?
- Is a task predictable or unpredictable?
- Is a task continuous or disjointed?
- Is the user multitasking? What else is going on?
- Is a task process-driven or user-driven?
After you define the use scenario, conduct task/need analysis with your users and create worksheets that organize the tasks into groups; prioritize them as easy, moderate or difficult based on importance and frequency of use; and consider what metaphors may have emerged from your interview notes to help describe and explain them. These documents can assist you as you develop conceptual diagrams and screens that meet the challenges of the tasks for each persona.
Conceptual Design, Prototyping and Story-Telling
Based on the information in your persona, use scenario and task analysis, the UI can then be developed as a set of layouts with specific labels and data fields that account for tasks, workflow and user concerns. Although computer-based tools for high-level modeling can be used, your team and users can also employ tools as simple as sheets of paper on a wall with grouped sticky notes.
A series of one to three organizational sessions can usually develop high-level screens that accurately and meaningfully represent the user’s world. The ensuing prototype or demo can then be joined to or checked with whatever data-gathering and use-case information has been collected by traditional software development processes. In this way, top-down and bottom-up approaches meet in the middle to achieve superior usability, usefulness and pleasure for the user.
In today’s economy, even a business-critical project must be “sold” to the key stakeholders. It’s essential that UCUID teams develop engaging and compelling story-telling skills with the help of demos and prototypes that make a product vision visible, comprehensible, credible and desirable to key audiences. Your user models and scenarios will assist you again in communicating the benefits of the user interface.
These best practices of user-centered user-interface development will help you to develop easy-to-use software that’s also responsive to your user’s needs. Especially important are interviews, user profiles, use scenarios, prototypes and evaluation techniques that emphasize iterative design and studying actual users. Now you can put these practices to work. Go team!
Aaron Marcus is president of an eponymous user-interface and information-visualization design consultancy in Berkeley, California. A prolific author and lecturer, Marcus has designed and analyzed more than 400 UIs, and worked on the initial versions of AOL and Travelocity.com.