Informing Design with Context Scenarios

The planning phase of any project is crucial, and there are many deliverables that can help document it, including a project roadmap, a product backbone, and user research insights. The challenge comes when trying to turn these deliverables into a wireframe or design. For a recent project, I took to writing context scenarios to bridge this gap.

Context scenarios are user-focused scenarios meant to bridge the functionality described in the project roadmap with the design and technical needs to move it through implementation.

When done well, context scenarios:

• Define the core problem and user need
• Identify the value that something brings to users, the project, and the business
• Describe who will benefit from the solution
• Provide a design hypothesis for the user interface and experience

Each context scenario includes:

• The relevant project roadmap phase
• A priority level and description
• The end goal for the user
• A step-by-step scenario
• The applicable personas
• A design hypothesis for how the team envisions the user experience or user interface and what they expect to see

Example Context Scenario

Phase: Account Management

Priority: Core – Building trust and integrity are essential to user retention.

User Goal: Manage profile settings and notifications for my preferences.

Scenario:

1. A Profile Manager is reviewing their Profile page in order to adjust the number the notifications they receive.
2. They need a way to adjust the frequency of notifications within their preferred range so that they can opt to receive fewer notifications without unsubscribing and deactivating the account.

Personas:

• Project Manager
• Experience Designer
• Developer Lead

Design Hypothesis:

• Options: immediate, hourly, daily, weekly
• Choose the time of day to receive updates (for daily or weekly)
• Show email that is saved to receive updates
• Checkbox: mentions, messages, posts, invitations
• One page to manage all settings (no tabs)
• Changes to settings take effect immediately (no save or apply button)

The framework can be adapted to meet the needs of your project, but I’ve found that the recommendations below help improve consistency and keep me focused on the most important requirements when writing context scenarios.

Phase

Defines traceability from the roadmap phase to the context scenario.

Priority

• Core – Foundational capabilities that make the application functional for the target audience.
• Supporting – Helpful but not foundational features. Supporting priority may be due to an existing workaround that is already built into the experience of the application or the user’s workflow.
• Deferred – Features that are identified but not necessary to build yet. These may be deferred because the effort or complexity of planning will take more time than is feasible during this phase.

Goal

Defines what the user is trying to accomplish. Goals should be action-oriented (ie. save, compare, understand, complete).

• Keep it focused on one outcome. Using the word “and” in your goal may indicate that a new context scenario is needed.
• Write the goal from the user’s perspective.

Scenario

Outlines the step-by-step process the user will walk through in order to accomplish the goal.

1. Situational Context – What is the trigger that starts the scenario? Why is this scenario needed?
2. Starting Point – Describe the place or area where the user begins. What information do they have or need?
3. Actions – What does the user need to do with the information they’re given? Keep it action-oriented (ie. download, save, share, etc.).

• Abstract any names, roles, or personas (ie. Profile Manager, Playlist Curator). This makes it specific to the scenario and flexible enough to apply to multiple personas.
• Remove any mention of a solution at this point. Any hypothesis (ie. “It’s a page, a dropdown, a toggle”) should go to the design hypothesis section.
• Use language that is natural to the user. This will help inform your domain model so that design and development build an intuitive user experience.

Design hypothesis

An initial list of expected pages, views, fields, or patterns that should be considered during the design.

• Provide context or definition of new business model concepts that are new to the team.
• Describe how users might expect it to work.
• Note requirements, conventions, and assumptions.
• Include notes on how this feature might evolve in later phases.

Sharing out

Perhaps the most critical part of developing context scenarios is sharing them with the team. When the team is aligned on the context scenarios, they know what is expected and what the end goal is. This enables all team members to be creative and collaborate on alternative solutions at any point in the process, from design through development.

Once the team is in alignment, design can get underway with further research or wireframes to plan and visualize the user experience.