Читать книгу Mental Models - Indi Young - Страница 14

If you are who I think you are, you’re familiar with standard user-centered design techniques, such as writing scenarios based on specifically designated personas. You’ve probably seen or used affinity diagrams that show group relationships among things. You may have commissioned or participated in a field study of your users. You possibly have directed “Voice of the Customer” surveys as a part of a Six Sigma[4] program at your company. But you’re looking for something to pull these techniques together, to make them reach further.

Mental model research occupies a place in the constellation of techniques after user data collection and before product and interaction design concepts (see Figure 2.2). Its use as a planning roadmap is long-lived. You can refer to the same mental model for several projects over time.

Figure 2.2. http://flickr.com/photos/rosenfeldmedia/2125040155

Constellation of some user-centered design steps. (No wonder it seems so hard to figure out where to start!)

Mental models are also useful for things other than design. Sales and customer service can use the data to understand clientele better. MBAs and information designers can re-format the data into workflow and process diagrams. Project managers can use it to prioritize among a set of development options. I encourage you to reach out to these people and introduce them to any mental models that you create.

Within the realm of designing solutions, mental models provide a nexus for all the other tools in your toolbox. You can draw benefits from using mental models to support your personas and scenarios. Mental models along with web analytics and use cases influence your interaction design concepts. Prototypes coming out of these concepts undergo usability testing to touch base with the user.

There are a few additional techniques that could flow directly into or out of a mental model. I’ll sketch these additional techniques here, and then dive into the main techniques later.

Input: Diaries

Diaries are a popular way to gather data in the user’s voice. You could ask participants who are, for example, members of Weight Watchers to write down their daily successes and frustrations with the diet and exercise program they are trying to follow. You can comb through this data for behaviors and create a mental model from this analysis. Diaries do have a tendency to flit from subject to subject, however, without deep examination of a topic. This tendency can leave you with a spotty mental model. But if you have this data, go ahead and mine it for your mental model.

Input: Field Visits

Field visits conducted by a professional researcher produce a much deeper understanding, and all topics within a scope are likely to be covered. In this respect, field visit data is better for task analysis than diary content. To create a mental model of the participant’s perspective, however, you will need to convert third-person notes into first-person behaviors. This translation is not insurmountable, and you will have a solid mental model as a result.

Output: Personas

According to Alan Cooper and Robert Reimann in About Face 2.0: The Essentials of Interaction Design, personas are user profiles that help the design team and other teams such as sales and marketing get more useful products into the hands of customers. If you review how they instruct you to write a persona, you will know to list experience goals, end goals, and life goals. The mental model focuses on the end goals (the things a person wishes to accomplish) and the life goals (the reasons why a person wishes to ccomplish something—the larger picture). You can use this data to adjust your original task-based audience segments[5] and go on to build personas out of each segment with photos, names, and experience goals.

Output: Scenarios

A time-honored practice is writing scenarios that describe how a persona accomplishes a goal using a set of tools. Once you have a mental model, you can certainly write scenarios based on the meaningful tasks for your business.

I don’t usually write scenarios, but it doesn’t harm the design process if it is done correctly. Let me explain two things: Why I don’t write them and what is incorrect execution. I don’t write scenarios because I ordinarily work in quick-paced environments. I explore scenarios verbally with my team. To communicate these scenarios to other team members, we could use comics, storyboards, or videos,[6] but typically we don’t have time. We go straight to prototypes, working directly and verbally with engineers.

What is an incorrect scenario? They are long, written descriptions that contain a lot of unnecessary detail, such as the specific buttons the user hits, every edge case,[7] or every error condition. Don’t make it read too much like code, yet. Don’t dwell on the facilities being used. Incorrect scenarios might also include non-relevant conditions that do not affect what the person is trying to accomplish, and might be better off as part of a persona description, such as gender or fashion preferences. In a situation where you’re designing a clothing store, of course fashion preferences would affect how a customer behaves. But it’s unlikely to affect how someone decides on a retirement plan.