4 UI/UX Training Activities for Design Thinking

Scenarios: Finding Patterns

As explained above, clear, clean scenarios can emerge during persona development. Yet, this is not always the case. Often, identifying and fleshing our clear scenarios requires additional analysis of research findings in order to identify patterns showing what users can or are likely to do.

Before starting this in-depth analysis, it’s wise to have a clear sense of what scenarios entail and how they differ from journey maps. While journey maps (described below) are important artifacts in the UI/UX design process, an effective journey map requires solid scenarios. It’s difficult to map out the user’s journey without context.

Scenarios provide this context by describing how the target group will use your product, service, or software to accomplish a specific task. For example,

Carmen restores cars in her spare time and needs four parts to complete the restoration of her 1940 Cadillac V-16. She has scoured online and brick and mortar stores without success. Recently, she heard about carsqy.net and plans to use this site to find out if the parts she needs are available.

Notice that this scenario is concrete rather than vague and high level; it explains what Carmen will do. Yet, the scenario does not include a series of detailed steps. In other words, scenarios occupy a middle ground between high-level statements such as “Carmen likes to shop online” and a step-by-step description such as: “Carmen opens a browser, logs onto the auto parts online store, looks for an air intake s for her 1940 Cadillac V-16, compare prices, selects and places an item in her cart.”

Despite their brevity, well-crafted scenarios are powerful because knowing what the user needs to accomplish makes it easier to decide what to include and omit from the design.

Watch for the following traps when developing scenarios:

  • Vague statements such as “Carmen likes cars,” because such high-level statements don’t describe what she will do when she visits your site or encounters your product.
  • Delving into too much detail, i.e. a step-by-step description, which is actually a task analysis. Task analysis is important and useful but not at this stage.
  • Describing what the system will do instead of what the human will do. For example, “Carmen navigates to carqy.net at which point the system prompts her to create a login. She enters a username and password; the system checks to ensure that the username is available returns a message saying that Carmen must choose a different username.” System functions are important but they should not be included in a user-based scenario.

A well-written scenario avoids any mention of system functions and occupies the middle ground between a detailed step-by-step task analysis and vague statements that do not contribute to a design tailored to Carmen’s needs.

Prev3 of 6Next