Interpretation

When you have answers to your questions, make sense of what you've learned.

Affinity diagramming

What

A way of finding themes in collections of ideas, quotes, or observations.

Why

To draw out insights from qualitative data quickly and collaboratively.

Templates

Phase

Interpretation

Time required

1 hour

How to do it

  1. Record ideas, quotes, or observations from interviews, contextual inquiry, or other sources of research on sticky notes.
  2. Place the sticky notes on a white board (in no particular arrangement). Move the sticky notes into related groups.
  3. Use larger notes (or white board markers, if you’re using a white board), to write titles or catch phrases for each group.

Additional resources

Considerations for use in government

No PRA implications. This method may use data gathered from members of the public, but does not require their involvement.

Journey mapping

What

A visualization of the major interactions shaping a user’s experience of a product or service.

Why

To provide design teams with a bird’s-eye view of a service that helps them see the sequence of interactions that make up a user’s experience including the complexity, successes, pain points, and emotions users experience along the way.

Templates

Phase

Interpretation

Time required

4–12 hours

How to do it

  1. Document the elements of the project’s design context. This includes:
    • People involved and their related goals
    • Their behaviors in pursuit of their goals
    • Information, devices, and services that support their behaviors
    • Important moments in how they experience a service or major decisions they make
    • The emotions associated with these moments or decisions
  2. Visualize the order in which people exhibit behaviors, use information, make decisions, and feel emotions. Group elements into a table of “phases” related to the personal narrative of each persona. Identify where personas share contextual components.
  3. Discuss the map with stakeholders. Point out insights it offers. Use these insights to establish design principles. Think about how to collapse or accelerate a customer’s journey through the various phases. Incorporate this information into the project’s scope.

Additional resources

Considerations for use in government

No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for Recruiting and Privacy for more tips on taking input from the public.

Personas

What

User archetypes based on conversations with real people.

Why

To ground design in reality by forcing us to consider the goals, behaviors, and pain points of the people affected by our design decisions. Unlike marketing personas based on demographics or marketability, design personas describe how someone accomplishes goals.

Templates

Phase

Interpretation

Time required

2–3 hours

How to do it

  1. Gather research from earlier activities like contextual inquiry or stakeholder interviews in a way that’s easy to review. You can create placeholder personas without research to teach user-centered thinking, but because they’re effectively stereotypes, avoid using them for implementable design decisions.
  2. Create a set of user archetypes based on how you believe people will use your solution. These typically get titles (for example, “data administrators” rather than “those who submit data”).
  3. Analyze your records for patterns as they relate to user archetypes. Specifically note frequently observed goals, motivations, behaviors, and pain points.
  4. Pair recurring goals, behaviors, and pain points with archetypes. Give each archetype a name and a fictional account of their day. Add a photo of someone who fits the description, but ideally not an image of someone you’ve actually interviewed and who may be recognized.
  5. Link your personas to the research that inspired them. This is useful when researchers are interested in challenging the way a persona stereotypes a user.

Example from 18F

Additional resources

Considerations for use in government

No PRA implications. No information is collected from members of the public.

Site mapping

What

A comprehensive rendering of how a website’s pages relate to one another.

Why

To audit an existing website by assessing its structure and content. Site maps also help you plan and organize the contents of a new website prior to wireframing and building it.

Templates

Phase

Interpretation

Time required

2–3 hours

How to do it

  1. List each page of a website or section.
  2. Take a screenshot of each page. Create a thumbnail for each screenshot.
  3. Print the thumbnails on individual pages if completing this exercise in person. Remote teams can use a shared whiteboard tool. Arrange the page thumbnails into a hierarchical diagram. Focus on the logical relationships between pages. If you’re evaluating an existing website, focus more on these relationships than on the URL structure. If some pages function as sub-pages to another, the site map should reflect that.
  4. Use the diagram to guide choices about things like information architecture and URL structures.

Considerations for use in government

No PRA implications. No information is collected from members of the public.

Story mapping

What

A visualization of the work needed to build or improve a product, organized from the perspective of a person using the product — essentially a two-dimensional view of the product backlog.

Why

To provide stakeholders with an overview of the proposed product functionality in a way that more clearly illustrates the value provided by the product and the way a person experiences it than is possible with the typical, flat backlog.

Templates

Phase

Interpretation

Time required

2–4 hours (per session)

How to do it

  1. Gather the team.
    • Because this is a work planning activity, it should involve the whole product team, including the product owner and any available SMEs or representative users as well.
  2. Review the brief.
    • Start by setting context for the team by reviewing the product brief, including the vision, scope, and context for the product and current initiative.
    • If available, review any research findings that may have been gathered, including who the team is designing for and what we know about their goals and pain points.
    • If user research is not available, capture initial assumptions, but identify them as such and include discovery work in the story map.
  3. Build the backbone.
    • The backbone outlines the high-level functionality of the product, in the language of the value it provides for the user and roughly in the order the user might experience it in. It should look similiar to the stages of a journey map. (See the resources below for some examples of how this looks.)
  4. Capture work.
    • Set a time box for participants to individually capture work they think needs to be done to support the backbone.
    • This can be done in the form of user stories, and they can be grouped into epics as needed.
    • Participants should focus on the areas of work they are most familiar with, so developers are adding items for development work and designers are adding items for design work, for example.
  5. Share and refine.
    • After participants have had a chance to enter items, talk through each segment of the backbone until the team feels they have captured everything needed based on what they know at the time.
  6. Define release points.
    • Once the story map is filled out to the team’s satisfaction, define breakpoints that represent releases.
    • The story map format ensures each release enables some version of the full experience intended for the product.
  7. Run additional sessions as needed.
    • The entire story map doesn’t need to be completed in one session. It may make sense to break up the context setting and work capturing.
    • If using Miro and Jira, it’s possible to connect them to maintain a view of the backlog in both locations.

Additional resources

Considerations for use in government

No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for Recruiting and Privacy for more tips on taking input from the public.

User flow diagramming

What

A step-by-step diagram of how a user will interact with a system in order to reach a goal. The diagram traces a user’s possible paths through sequences of tasks and decision points in pursuit of their goal. The tasks and decision points should represent steps taken by the user, as well as steps taken by the system.

Why

To validate a team’s understanding of users’ goals, common scenarios, and tasks, and to illustrate in a solution-agnostic way the overall flow of tasks through which a user progresses to accomplish a goal. User flow diagrams also help surface obstacles in the way of users achieving their goal.

Templates

Phase

Interpretation

Time required

2-3 hours per user goal

How to do it

  1. Based on user research, identify target users’ goals that need to be analyzed.
  2. For each goal, identify common scenarios and the tasks and decisions that the user or system will perform in each scenario. Don’t assume you and your stakeholders share the same understanding of the tasks. The idea is to make the flow of tasks explicit in the diagram, so that you can check your understanding by walking through the diagram with users (steps 4 & 5).
  3. Produce a diagram that includes each task and decision point that a user might encounter on their way toward their goal. While there are several diagrammatic languages that can be used to produce user flow diagrams, the basic look is a flow chart of boxes for tasks and decision points and arrows showing directionality and dependencies among tasks. The diagram should cover the common scenarios identified in step 2.
  4. Present the diagram to a subject matter expert who knows the task(s) well enough to check for accuracy.
  5. In collaboration with users and/or subject matter exprts, annotate the task flow diagram to pinpoint areas of interest, risk, or potential frustration.

Additional resources

Considerations for use in government

No PRA implications. No information is collected from members of the public.

User scenarios

What

A method for telling a story about a user’s interaction with your product, service, or website, focusing on the what, how, and why.

Why

To communicate a design idea by telling a story about a specific interaction for a specific user. Through creating user scenarios, you’ll identify what the user’s motivations are for using your product, service, or website, as well as their expectations and goals. User scenarios help teams consider both how the same user’s needs might vary depending on their context and how a diverse group of users in the same scenario might have different needs. By constructing user scenarios, you can help the team answer questions about how accessible, inclusive, and adaptive your product, service, or website is.

Phase

Interpretation

Time required

1-3 hours

How to do it

  1. Determine a few personas or user groups to focus on. Consider what scenario(s) might be the most critical for that user, including scenarios in which users face limited accessibility.
  2. For each user, list out their goals, motivations, and the context/environment in which they interact with your product, service, or website.
  3. Put the details you came up with in step 2 into a story format that includes the following information:
    • who they are (persona or user group)
    • why they are using your site (motivations)
    • where they are (context)
    • what they need to do (their goal)
    • how they go about accomplishing the goal (tasks)

    Keep in mind, the more realistic details you add, the richer and more useful your story becomes for helping to understand your user’s behaviors.

  4. Share the user scenarios that you’ve written with the user group (and other relevant team members) for validation, feedback, and refinement.
  5. Examine your product, service, or website in light of these user scenarios and identify opportunities to make adjustments that would improve users’ experiences.

Additional resources

Time required

1-3 hours

Considerations for use in government

No PRA implications. No information is collected from members of the public.