Skip to main content
U.S. flag

An official website of the United States government

The .gov means it’s official.
Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure.
The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

Decide

Elaborate on research from your Discovery phase.

Affinity mapping

What

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

Why

To draw out insights from qualitative data quickly and collaboratively.

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.

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.

18F

Archetypes

What

Archetypes are visual documents that represent a group of users based on their shared goals, needs, attitudes, behaviors, and/or pain points.

Why

Unlike demographic data that can unintentionally introduce creative blocks or bias, archetypes can help better understand product or service users who share the same behaviors and core desires.

Time required

30 mins-1 hour per archetype

How to do it

  1. Gather findings from research activities such as contextual inquiry or stakeholder interviews, user surveys, and analysis of customer data and organize them in a way that’s easy to review.
  2. Analyze and affinity map your research findings for patterns. Note frequently observed goals, motivations, behaviors, pain points, and potential harms (e.g. lack of consent, physical danger, being retraumatized). These patterns help form the foundation of each archetype.
  3. Create sets of user archetypes based on how you believe people will use your solution and the journeys they are on. These archetypes typically get titles, for example, “the marketing specialist” and will include narratives that describe motivations in a relatable way.

Example at 18F

Tips for remote participation

Archetypes can be created virtually using any variety of digital whiteboards or word-processing tools.

Additional resources

Applied in government

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

18F

Coding qualitative data

What

Using flexible coding tools for sorting spreadsheets or databases to analyze qualitative data.

Why

Quickly organize research to help you see patterns and relationships. To help make qualitative data actionable and to give it an even playing ground with quantitative data.

Time required

3–4 hours or more depending on the amount of data collected.

How to do it

  1. Gather and organize qualitative data within your tool of choice.
  2. Sort or tag the data based on themes and categories. Organizing the content from your research using filters or tags.
  3. Analyze the data based on the identified themes. By sorting and resorting your findings, you'll be able to quickly identify patterns, relationships, and insights, which are essential for synthesis.
  4. Share your findings with your team(s) to determine the next steps.

Example from 18F

When doing feedback sessions for a prototype of a new dot gov registrar, we used qualitative data analysis to help sift through the gathered feedback to identify key areas for the next of design and development.

Tips for remote participation

Common for multiple team members to break off to take a pass at sorting data for themes and come back together to share and discuss findings.

Considerations for use in government

When using qualitative data, remove any personally identifiable information (PII) from your documents before sharing.

18F

Comparative analysis

What

A detailed review of existing experiences provided either by direct competitors or by related agencies or services.

Why

To identify competitors’ solutions that excel, are lacking, or are missing critical design elements. Comparative analysis can give you a competitive edge by identifying opportunities, gaps in other services, and potential design patterns to adopt or avoid.

Time required

1–2 hours to analyze and write an evaluation about each competitor.

How to do it

  1. Identify a list of services that would be either direct or related competitors to your service. Pare the list down to four or five.
  2. Establish which criteria or heuristics you will use to evaluate each competing service.
  3. Break down the analysis of each selected competitor into specific focal areas for evaluation. For example, how relevant are search results?
  4. Use a spreadsheet to capture the evaluation and determine how the targeted services and agencies perform based on the identified heuristics.
  5. Present the analysis, which should showcase areas of opportunities that you can take advantage of and design patterns you might adopt or avoid.

Example from TTS

Considerations for use in government

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

18F

Content audit

What

A listing and analysis of all the content on an existing website (including pages, files, videos, audio or other data) that your users might reasonably encounter.

Why

To identify content that needs to be revised in new versions of a website. Content audits can also help you identify who is responsible for content, how often it should be updated, and what role a particular piece of content plays for users.

Time required

3-8 hours

How to do it

  1. Identify a specific user need or user question that you’d like to address.

  2. Create an inventory of content on your website. Navigate through the site from the home page and note the following about every piece of content. (For repeated items like blog posts, consider capturing just a sample.)

    1. Title used in the site’s navigation for that page
    2. Title displayed on the page or item itself
    3. URL
    4. Parent page
  3. Identify the main entry points for the user need you’re addressing. This could be external marketing, the homepage, a microsite, or another page.

  4. From each entry point, trace the pages and tasks a user moves through until they address their need.

  5. For every piece of content they might come across on that task flow, note:

    1. Author(s): who wrote or created the page
    2. Content owner(s): who ensures its credibility
    3. How often or when it was last updated
    4. Comments: qualitative assessment of what to change to better address your identified user need

Example

Additional resources

Considerations for use in government

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

18F

Design hypothesis

What

Framing your work as a hypothesis means no longer just thinking about the thing you’re making or building, but paying more attention to whether that work is achieving your intended goals and outcomes.

This in turn means thinking about your work as a series of experiments you do with your users to learn if you’re on the right path. Instead of asking “Did we ship the shopping cart feature?” you ask: “Did we make it easier and simpler for our customers to buy from us?”

Why

When done collaboratively, hypothesis-building is powerful at getting a team on the same page about what it’s doing and why. It also allows the team to be flexible — if one approach doesn’t result in the outcome you expected, you have implicit permission to change course and try something else.

Time required

1-2 hours

How to do it

  1. As a team, identify and make explicit the problem you’re trying to solve. What goals or needs aren’t being met? What measurable criteria would indicate progress toward those goals?

  2. As a team, write out the hypothesis for the work you want to do to address the problem(s) you’re trying to solve. You may want to write broad hypotheses at the outset of a project and more specific hypotheses each sprint.

    Here’s a common way to structure your hypothesis:

    We believe that doing/building/creating [this] for [this user] will result in [this outcome].

    We’ll know we’re right when we see [this metric/signal].

  3. Once you’ve formulated your hypothesis, consider the following harm prompt to help the team think about and guard against potential unintended consequences of your work.

    But, this could be harmful for [this user] if [this outcome happens].

  4. Identify a user touchpoint that will allow you to test your hypothesis, such as external marketing, the homepage, a microsite, or something else. Test your hypothesis. If you learn something unexpected, refine your hypothesis, test again, and continue to work incrementally towards your goals.

Considerations for use in government

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

18F

Design principles

What

Written statements, generally in the form of imperatives like “Earn people’s trust,” that serve as guiding lights during decision-making.

Why

To give the team and the stakeholders a shared point of reference when negotiating next steps. Good design principles are specific to the project, not general truths, and should help teams say “no” to otherwise interesting proposals or generate ideas when they’re stuck.

Time required

1 week, plus occasional refresher meetings

How to do it

  1. Using internal documents and kickoff activities, gather terms or concepts that seem significant to project goals and organizational culture.
  2. Using existing research, list terms or concepts that seem particularly important to customers or user groups.
  3. Cluster similar terms and concepts together on a whiteboard or other writing space open to everyone in the project. Name the clusters.
  4. Ask the team and stakeholders if they would like to add, change, or edit any concepts or groups.
  5. From the groups on the board, create three to five final principles. Using evidence from partner or user research, write one to two sentences in support of each principle.
  6. Share the principles in a place accessible to the team throughout the project, and refer to them often while making decisions.

Examples

Considerations for use in government

No PRA implications. Generally, no information is collected from members of the public. Even when stakeholders are members of the public, the PRA explicitly exempts direct observation and non-standardized conversation (e.g., not a survey), 5 CFR 1320.3(h)3. See the methods for Recruiting and Privacy for more tips on taking input from the public.

18F

Interface audit

What

A listing and analysis of all the components, design patterns, and interface features of an existing website (including typography, color, graphics/illustration/icons)

Why

To identify components that need to be revised in new versions of a website to create consistency and fill gaps. Interface audits can also help you establish and document a design system for a website.

Time required

Depends on scope of audit (how many pages, how many contributors, etc)

How to do it

An interface audit can be conducted by an individual or in a group setting. Either way, the steps are as follows:

  1. Identify the website and take screenshots of all the pages you want to audit
  2. Create a checklist of aspects you want to audit on each page—for example typography, header and body copy styles, use of color, buttons, icons, etc.
  3. For each page, take notes on each aspect on your checklist.
  4. Once all pages have been audited, compare notes and identify inconsistencies (e.g., headers are inconsistently formatted, sometimes bolded, sometimes italicized).
  5. Decide how to resolve any inconsistencies by choosing one of the existing approaches found on the site (e.g., make all headers bold) or designing a new solution (e.g., make all headers a different color).

Note: It’s helpful to involve developers, who will be able to advise on the feasibility of potential solutions.

Additional resources

Applied in government research

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

18F

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 from the earliest phases of researching a product or service all the way through adoption.

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
    • Potential harms (e.g. financial penalties, anxiety, damaged reputation) 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.

18F

Mental modeling

What

A simple reference model that correlates existing and potential interfaces with user behaviors.

Why

To help designers anticipate how design decisions might facilitate future behaviors.

Time required

1–2 hours

How to do it

  1. Create one three-columned table per persona. Label the columns “Past,” “Present behavior,” and “Future.”
  2. In the middle column (Present behavior), list current user behaviors and pain points broadly related to the project, one per row.
  3. In the left-hand column (Past), list the products, services, features, and/or interfaces that the user encounters as they go about what’s listed in the Present behavior column.
  4. In the right-hand column (Future), list possible products, services, features, and/or interface elements that in the future might change behaviors and pain points in the Present behavior column.

Considerations for use in government

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

18F

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.

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”). Review the archetypes with “who questions:” Who is included? Who is being overlooked? Who is deciding whom to include?
  3. Analyze your records for patterns as they relate to user archetypes. Specifically note frequently observed goals, motivations, behaviors, and pain points, and potential harms (e.g. lack of consent, physical danger, being retraumatized).
  4. Pair recurring goals, behaviors, pain points, and potential harms 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

Additional resources

Considerations for use in government

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

18F

Service blueprint

What

A visual representation of the start-to-finish experience of both using and supporting the delivery of a service, including staff interactions and user experience.

Why

To clarify relationships between intertwined systems and processes. By communicating the full complexity of a service, service blueprints help teams find opportunities for improvement.

Time required

4-12 hours

How to do it

  1. Gather information on the service through desk research and interviews with users, frontline staff, and support staff.
  2. Create a diagram with four rows:
    • User steps: the primary action someone takes when interacting with the service
    • Frontstage actions: the online and offline interactions that users have with the service, including people, places where interactions occur, and physical or virtual objects that users interact with, like forms
    • Backstage actions: activities in the systems and processes that support the frontstage experience, but are not visible to users
    • Support processes: activities executed by the rest of the organization or external partners — such as ongoing data management or software licensing — that don’t fall into the other rows
  3. Map the flow of each user interaction through the service. Note critical points and interactions in delivering the service, as well as any opportunities to handle interactions more efficiently or that would result in a better user experience.

Examples

Considerations for use in government

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

18F

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.

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.

18F

Storyboarding

What

A visual sequence of a specific use case or scenario, coupled with a narrative.

Why

To visualize interactions and relationships that might exist between a user and a solution in the context of the user’s full experience.

Time required

1–2 days depending on the complexity of the scenario(s)

How to do it

  1. Gather any documents that describe the different use cases or scenarios in which users will interact with your service.
  2. Sketch scenes that visually depict a user interacting with the service, including as much context as possible. For example: Are they on the move? Where are they? What else is in their environment?
  3. Annotate each scene with a description of what the user is attempting to do. Describe what general feeling or experience the team wants the user to have.
  4. Review this storyboard with the product team and stakeholders for feedback. Iterate until the storyboard represents a shared vision of the scenario and progression of scenes.
  5. Create a polished version of the storyboard if you plan to use it for future work or in other external contexts.

Considerations for use in government

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

18F

Style tiles

What

A design document that contains various fonts, colors, and UI elements that communicate the visual brand direction for a website or application.

Why

To establish a common visual language between the design team and stakeholders. It also acts as a collaboration artifact that both the design team and stakeholders can use to contribute to the final design direction.

Time required

1–2 days depending on how many rounds of feedback the team offers

How to do it

  1. Gather all the feedback and information that was provided during the initial kickoff of the project.
  2. Distill the information into different directions a solution could take. Label these directions based on what kinds of interactions and brand identity they represent.
  3. Create the appropriate number of style tiles based on the defined directions, which establish the specific visual language for the different directions.
  4. Gather stakeholder feedback. Iterate on the style tiles, eventually getting down to a single style tile which will be the established visual language for the project going forward.

Considerations for use in government

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

18F

Task flow analysis

What

A step-by-step analysis of how a user will interact with a system in order to reach a goal. This analysis is documented in a diagram that 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 design 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. Task flow diagrams also help surface obstacles in the way of users achieving their goal.

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 task 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 experts, 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.

18F

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.

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

Considerations for use in government

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

18F

User stories

What

A short, plain-language description of a product feature or requirement written from the perspective of the user.

Why

To frame the problem we’re solving around the needs of the people who will use the product, rather than the limitations of the technology or the program or agency overseeing it. User stories help us break down a large development effort into smaller, more manageable slices so that we can track progress, plan sprints, and prioritize work around user impact. They also encourage us to talk about features in plain language and make the discussions (and solutions) more accessible.

Time required

1-2 hours per epic

How to do it

  1. Start by defining the project’s epics—typically the larger, high-level “themes” or bodies of work that make up the initiative.
  2. Break down each epic into pieces of work that can be independently estimated, developed, and tested. These will become your user stories.
  3. For each piece of work you identified, write a story from the user’s perspective of who they are, what they want to do, and why. User stories typically follow this template:

    As a < type of user >, I want < some goal > so that
    < some outcome >.

    Note: Only make the type of user as specific as you need to. If the piece of work is needed by all your users, it’s ok to say “as a system user.” That way when it is specific (“as a first-time applicant”) it’s clear that this is a group with particular needs.

  4. Consider possible harms to the user, the system, or external to the system by adding a second part of the sentence:

    …while avoiding < potential negative impacts > to
    < the user, the system, or external to the system >.

  5. User stories can be the basis for tickets—a tool to manage and track work for the solution you’re building. These tickets should include the story, a brief description, and a list of acceptance criteria.

Additional resources

Considerations for use in government

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

18F

18F Methods

An official website of the GSA’s Technology Transformation Services

Looking for U.S. government information and services?
Visit USA.gov