User Experience Modeling
Mental Model Diagram
Mental model diagrams depict the steps involved in a task procedure and indicate how users are supported by the website or application at every step. The diagram may be divided into two halves; the top half represents the user’s mental model, and the bottom half represents how each task is supported by the system. Mental model diagrams are useful for developing the task flow of a system and for identifying gaps where a system design does not fully support its users.
The User’s Mental Model
The top half, or the user’s mental model, describes the task procedure in terms of mental spaces, conceptual groups, and atomic tasks.
Mental spaces are high-level goals, such as, “Get Ready for Work.” Within a mental space, there may be several conceptual groups, which are groups of tasks that need to be done in order to accomplish the goal. Conceptual groups for the mental space, “Get Ready for Work,” may include: “Get Dressed,” “Eat Breakfast,” and “Watch the Morning News.” Each conceptual group contains more specific, atomic tasks. For example, in order to “Get Dressed,” you may need to get out of bed, shower, brush your teeth, style your hair, and choose clothes to wear.
The diagram shows atomic tasks stacked into a tower shape, which becomes a conceptual group. Multiple towers of conceptual groups become a mental space. Mental spaces are divided by vertical lines and are depicted in the order in which they are chronologically carried out. The mental space “Get Ready for Work” may be followed by the mental space, “Work,” which may be followed by “Return Home,” and finally, “Spend Time with Family.”
Supporting System Features
Below each tower, or conceptual group, is another stack of boxes that indicate the various features or system tools that support the tasks in the conceptual group. For example, for the conceptual group, “Get Dressed,” people may use the following tools to get dressed: a toothbrush, soap, shampoo, a hairdryer, a brush, hair styling products, a closet, and clothing.
If there is an atomic task that the system does not currently support (in other words, no feature has been created to help users accomplish the task), you can indicate this in the bottom half of the diagram by creating a different-colored box and listing a new feature concept that could support that task. When creating new feature ideas, it is best to base them on user needs and preferences. In fact, it’s likely that users will tell user researchers about these “gaps” in surveys, interviews, and focus groups, and during user observations in the form of user-created workarounds.
Swimlanes Diagram
A swimlanes diagram illustrates how various resources, i.e., job roles, teams, networks, equipment, etc., support each step in a process workflow for a use case. The name “swimlanes” refers to the appearance of the diagram, as each role, team, and resource gets its own row/column or parallel “lane” in the diagram. Swimlanes provide an overview of all of the resources that support a particular procedural step; viewing resources in parallel reveals the interactions and potential conflicts between them. For example, in an online store’s purchase process, a web form supports specific business requirements, a user experience engineer designs the form’s user experience to be easy to use, and a computer programmer creates a database to store and process the data. All of these resources work together simultaneously to support the procedural step.
Sometimes a storyboard is used to depict each step of a process, which puts the swimlanes in context. Additionally, project requirements may be associated with each step by using footnotes. In the example above, business requirements, user experience requirements, and data/functionality requirements are associated with the step of completing a web form.
Use Case Scenarios
Use cases describe “who” (intended users/personas) can accomplish “what” while using a system. Use cases may be developed based on business requirements and participant feedback during user research. An example of a use case for an ecommerce website may be, “Find the shipping status for a recent product purchase.” Another example of a use case could be, “Contact technical support.” Use cases help project developers understand how to best support users’ goals as they develop an interface. Use cases are often referenced in Personas and Swimlanes to add more contextual information. They are also useful to keep in mind while performing a heuristic evaluation and when creating a set of user tasks for a usability test.
Personas
Personas represent the various user types that are expected as the intended users of a system. They are useful for keeping stakeholders and project developers focused on the intended user as they make design decisions.
Personas consist of at least three primary elements:
- Name: This is usually a real name, like “Bob” or “Lisa,” and may include the role of the individual as well. Roles should communicate something about the user’s perspective or motives. Examples of roles are, “Early Adopter,” “Conservative Shopper,” “Worrier,” “Care-giver,” “Parent,” and so on. Include a photograph that represents the individual’s general character to create a more vivid and realistic example for project stakeholders.
- Motivations, Needs, and Preferences: Based on user research, each persona’s motivations, needs, and preferences should be expressed in a concise statement, such as, “John wants to compare mobile phones and calling plans to sign up for new cellular service. He is particularly interested in finding a phone that will support worldwide travel, without expensive roaming fees.”
- Scenarios: Personas help project members better understand the personalities of a system’s intended users by describing a potential task or goal that the system will support in terms of how a person will react to it. For instance, a “Worrier” may be hesitant to complete a shopping purchase, fearing that his credit card information will not be secure. A parent may wish to control the experience of her young child while he explores a video gaming website that advertises violent games.
Although personas are abstractions of actual users, they should be developed based on actual data found in user research. To introduce personas to a project team, print them out and post them around the office. Bring personas to meetings to make more informed development decisions that will affect the user experience. For example, you may want to know, “Which area of the website would Chris, an Early Adopter, explore first before deciding to make a purchase?” During a meeting, attendees may role-play the various personas to ensure that the website will be designed to meet their needs and preferences according to their persona descriptions. Furthermore, to encourage project team members to maintain their focus on the intended audience of personas outside of meetings, create email addresses for each persona and assign team members to assume the role of each persona. When a stakeholder or project member has a design decision to make, he can send an email to the personas, who will respond to their question from the perspective of their needs and preferences.