- {% renderFile this_method.content, this_method, "md" %}
+ {{ content }}
diff --git a/assets/methods/styles/_category.scss b/assets/methods/styles/_category.scss
index ab1b5ce8..2df7aed3 100644
--- a/assets/methods/styles/_category.scss
+++ b/assets/methods/styles/_category.scss
@@ -9,6 +9,7 @@
line-height: line-height('sans',3);
margin: 0;
font-weight:bold;
+ color: $color-body-dark;
}
.category--subtitle {
@@ -16,7 +17,7 @@
font-size: font-size('heading',lg);
font-weight: font-weight('semibold');
line-height: line-height('sans',4);
- // max-width: measure(1);
+ color: $color-body-dark;
}
.category--header {
diff --git a/assets/methods/styles/_method.scss b/assets/methods/styles/_method.scss
index b337c567..2779b2e5 100644
--- a/assets/methods/styles/_method.scss
+++ b/assets/methods/styles/_method.scss
@@ -167,6 +167,10 @@
margin-bottom: 1.4em
}
+.method--panel--back .usa-icon {
+ color: $color-body-dark;
+}
+
.method--section--government-considerations {
ul {
list-style: none;
@@ -228,8 +232,3 @@
.category--fundamentals .method--title {
border-color: $color-blue-dark;
}
-
-.method--title a,
-.method--title a:visited {
- text-decoration: none;
-}
diff --git a/assets/methods/styles/_methods-colors.scss b/assets/methods/styles/_methods-colors.scss
index d5fc0c59..a87fa7f1 100644
--- a/assets/methods/styles/_methods-colors.scss
+++ b/assets/methods/styles/_methods-colors.scss
@@ -19,3 +19,6 @@ $color-decide: $color-green;
$color-decide-text: #538200; // $green-50v
$color-fundamentals: $color-blue-dark;
$color-fundamentals-text: $color-blue-dark;
+
+// Custom font colors
+$color-body-dark: #1b1b1b;
diff --git a/content/methods/about.md b/content/methods/about.md
index 46418b81..3f71f7aa 100644
--- a/content/methods/about.md
+++ b/content/methods/about.md
@@ -3,6 +3,7 @@ title: About
permalink: /methods/about/
layout: layouts/page
tags: methods
+eleventyExcludeFromCollections: true
---
The 18F Methods are a collection of tools that describe how our teams put human-centered design into practice. We’ve gathered them here and created simplified instructions to help other organizations and federal offices adopt human-centered design into their own projects. These cards are focused on design in the context of digital services, but can be adapted to non-technical design projects as well.
diff --git a/content/methods/decide/affinity-mapping.md b/content/methods/decide/affinity-mapping.md
index 55a92b5c..758e7658 100644
--- a/content/methods/decide/affinity-mapping.md
+++ b/content/methods/decide/affinity-mapping.md
@@ -15,5 +15,17 @@ method:
why: To draw out insights from qualitative data quickly and collaboratively.
timeRequired: 1 hour
category: decide
- content: ./_includes/methods/markdown/affinity-mapping.md
---
+
+## How to do it{#how-to-affinity-mapping}
+
+1. Record ideas, quotes, or observations from [interviews]({{ "/methods/discover/stakeholder-and-user-interviews/" | url }}), [contextual inquiry]({{ "/methods/discover/contextual-inquiry/" | url }}), or other sources of research on sticky notes.
+1. Place the sticky notes on a white board (in no particular arrangement). Move the sticky notes into related groups.
+1. 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{#consideration-affinity-mapping}
+
+No PRA implications. This method may use data gathered from members of the public, but does not require their involvement.
+
diff --git a/content/methods/decide/comparative-analysis.md b/content/methods/decide/comparative-analysis.md
index 12e3bbb5..972a64c7 100644
--- a/content/methods/decide/comparative-analysis.md
+++ b/content/methods/decide/comparative-analysis.md
@@ -15,5 +15,27 @@ method:
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.
timeRequired: 1–2 hours to analyze and write an evaluation about each competitor.
category: decide
- content: ./_includes/methods/markdown/comparative-analysis.md
---
+
+## How to do it{#how-to-comparative-analysis}
+
+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.
+1. Establish which criteria or heuristics you will use to evaluate each competing service.
+1. Break down the analysis of each selected competitor into specific focal areas for evaluation. For example, how relevant are search results?
+1. Use a spreadsheet to capture the evaluation and determine how the targeted services and agencies perform based on the identified heuristics.
+1. 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{#example-comparative-analysis}
+
+- [Draft U.S. Web Design Standards comparative analysis — USWDS GitHub](https://github.com/18F/web-design-standards/wiki/Comparative-Analysis)
+
+
+
+
+
+## Considerations for use in government{#considerations-comparative-analysis}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/content-audit.md b/content/methods/decide/content-audit.md
index 38b00d78..dbb47d26 100644
--- a/content/methods/decide/content-audit.md
+++ b/content/methods/decide/content-audit.md
@@ -15,5 +15,46 @@ method:
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.
timeRequired: 3-8 hours
category: decide
- content: ./_includes/methods/markdown/content-audit.md
---
+
+## How to do it{#how-content-audit}
+
+1. Identify a specific user need or user question that you'd like to address.
+1. 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
+ 1. Title displayed on the page or item itself
+ 1. URL
+ 1. Parent page
+
+1. Identify the main entry points for the user need you're addressing. This could be external marketing, the homepage, a microsite, or another page.
+1. From each entry point, trace the pages and tasks a user moves through until they address their need.
+1. For every piece of content they might come across on that task flow, note:
+
+ 1. Author(s): who wrote or created the page
+ 1. Content owner(s): who ensures its credibility
+ 1. How often or when it was last updated
+ 1. Comments: qualitative assessment of what to change to better address your identified user need
+
+
+
+## Example{#ex-content-audit}
+
+- [Content debt: What it is, where to find it, and how to prevent it in the first place — 18F Blog](https://18f.gsa.gov/2016/05/19/content-debt-what-it-is-where-to-find-it-and-how-to-prevent-it-in-the-first-place/)
+
+
+
+
+
+## Additional resources{#add-content-audit}
+
+- [Content plays: Audit your content — USDA](https://www.usda.gov/digital-strategy/content/plays#content3)
+
+
+
+
+
+## Considerations for use in government{#con-content-audit}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/design-hypothesis.md b/content/methods/decide/design-hypothesis.md
index 559d4bd1..380b9c52 100644
--- a/content/methods/decide/design-hypothesis.md
+++ b/content/methods/decide/design-hypothesis.md
@@ -18,5 +18,34 @@ method:
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.
timeRequired: 1-2 hours
category: decide
- content: ./_includes/methods/markdown/design-hypothesis.md
---
+
+## How to do it{#how-design-hypo}
+
+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?
+
+1. 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.
+
+
+## Considerations for use in government{#con-design-hypo}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/design-principles.md b/content/methods/decide/design-principles.md
index 9f16ba57..a8beda7b 100644
--- a/content/methods/decide/design-principles.md
+++ b/content/methods/decide/design-principles.md
@@ -15,5 +15,29 @@ method:
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.
timeRequired: 1 week, plus occasional refresher meetings
category: decide
- content: ./_includes/methods/markdown/design-principles.md
---
+
+## How to do it{#how-design-principals}
+
+1. Using internal documents and kickoff activities, gather terms or concepts that seem significant to project goals and organizational culture.
+1. Using existing research, list terms or concepts that seem particularly important to customers or user groups.
+1. Cluster similar terms and concepts together on a whiteboard or other writing space open to everyone in the project. Name the clusters.
+1. Ask the team and stakeholders if they would like to add, change, or edit any concepts or groups.
+1. 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.
+1. Share the principles in a place accessible to the team throughout the project, and refer to them often while making decisions.
+
+
+
+## Examples{#ex-design-principals}
+- 18F Design Principles Guide — [Create](https://github.com/18F/design-principles-guide/blob/18f-pages/pages/create.md), [Define](https://github.com/18F/design-principles-guide/blob/18f-pages/pages/define.md), [Usage](https://github.com/18F/design-principles-guide/blob/18f-pages/pages/usage.md)
+- [Making more consistent decisions with design principles: A new 18F guide — 18F Blog](https://18f.gsa.gov/2016/04/08/making-more-consistent-decisions-with-design-principles-a-new-18f-guide/)
+
+
+
+
+
+## Considerations for use in government{#con-design-principals}
+
+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]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
diff --git a/content/methods/decide/interface-audit.md b/content/methods/decide/interface-audit.md
index ebcc4143..a3a07bae 100644
--- a/content/methods/decide/interface-audit.md
+++ b/content/methods/decide/interface-audit.md
@@ -15,5 +15,29 @@ method:
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.
timeRequired: Depends on scope of audit (how many pages, how many contributors, etc)
category: decide
- content: ./_includes/methods/markdown/interface-audit.md
---
+
+## How to do it{#how-inter-audit}
+
+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
+1. 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.
+1. For each page, take notes on each aspect on your checklist.
+1. Once all pages have been audited, compare notes and identify inconsistencies (e.g., headers are inconsistently formatted, sometimes bolded, sometimes italicized).
+1. 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{#add-inter-audit}
+- [Conducting an interface inventory — Brad Frost](https://bradfrost.com/blog/post/conducting-an-interface-inventory/)
+
+
+
+
+
+## Applied in government research{#app-inter-audit}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/journey-mapping.md b/content/methods/decide/journey-mapping.md
index 3086aa39..774370dd 100644
--- a/content/methods/decide/journey-mapping.md
+++ b/content/methods/decide/journey-mapping.md
@@ -17,3 +17,30 @@ method:
category: decide
content: ./_includes/methods/markdown/journey-mapping.md
---
+
+## How to do it{#how-journey-mapping}
+
+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]({{ "/methods/decide/personas/" | url }}). Identify where personas share contextual components.
+3. Discuss the map with stakeholders. Point out insights it offers. Use these insights to establish [design principles]({{ "/methods/decide/design-principles/" | url }}). 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{#add-journey-mapping}
+
+- [3-part series on the what, why, and how of journey mapping — GSA Customer Experience Center of Excellence](https://coe.gsa.gov/2019/04/17/cx-update-9.html)
+
+
+
+
+## Considerations for use in government{#con-journey-mapping}
+
+No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for
+[Recruiting]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
diff --git a/content/methods/decide/mental-modeling.md b/content/methods/decide/mental-modeling.md
index b43f9515..0d6b92ab 100644
--- a/content/methods/decide/mental-modeling.md
+++ b/content/methods/decide/mental-modeling.md
@@ -15,5 +15,18 @@ method:
why: To help designers anticipate how design decisions might facilitate future behaviors.
timeRequired: 1–2 hours
category: decide
- content: ./_includes/methods/markdown/mental-modeling.md
---
+
+## How to do it{#how-mental-model}
+
+1. Create one three-columned table per [persona]({{ "/methods/decide/personas/" | url }}). Label the columns "Past," "Present behavior," and "Future."
+1. In the middle column (Present behavior), list current user behaviors and pain points broadly related to the project, one per row.
+1. 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.
+1. 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{#con-mental-model}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/personas.md b/content/methods/decide/personas.md
index 7b2739bc..cf28d1e0 100644
--- a/content/methods/decide/personas.md
+++ b/content/methods/decide/personas.md
@@ -15,5 +15,35 @@ method:
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.
timeRequired: 2–3 hours
category: decide
- content: ./_includes/methods/markdown/personas.md
---
+
+## How to do it{#how-personas}
+
+1. Gather research from earlier activities like [contextual inquiry]({{ "/methods/discover/contextual-inquiry/" | url }}) or [stakeholder interviews]({{ "/methods/discover/stakeholder-and-user-interviews/" | url }}) 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.
+1. 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?
+1. 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).
+1. 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.
+1. 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{#ex-personas}
+
+- [Personas for Cloud.gov — 18F GitHub](https://github.com/18F/federalist-design/wiki/Personas)
+
+
+
+
+
+## Additional resources{#add-personas}
+
+- [Improving customer experience with digital personas — Digital.gov](https://digital.gov/2017/06/20/improving-customer-experience-with-digital-personas/)
+
+
+
+
+
+## Considerations for use in government{#con-personas}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/service-blueprint.md b/content/methods/decide/service-blueprint.md
index 820b8ca4..ee85d9f7 100644
--- a/content/methods/decide/service-blueprint.md
+++ b/content/methods/decide/service-blueprint.md
@@ -17,5 +17,30 @@ method:
To clarify relationships between intertwined systems and processes. By communicating the full complexity of a service, service blueprints help teams find opportunities for improvement.
timeRequired: 4-12 hours
category: decide
- content: ./_includes/methods/markdown/service-blueprint.md
---
+
+## How to do it{#how-service}
+
+1. Gather information on the service through desk research and [interviews]({{ "/methods/discover/stakeholder-and-user-interviews/" | url }}) 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 which 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.
+
+
+
+## Example from 18F{#ex-service}
+
+18F created [this service blueprint of getting a burger]({{ "/methods/service-blueprint-example/" | url }}) as an example to illustrate what this could look like
+
+
+
+
+
+## Considerations for use in government{#con-service}
+
+No PRA implications. No information is collected directly from members of the public.
+
+
diff --git a/content/methods/decide/site-mapping.md b/content/methods/decide/site-mapping.md
index ef8f468a..593037ba 100644
--- a/content/methods/decide/site-mapping.md
+++ b/content/methods/decide/site-mapping.md
@@ -15,5 +15,18 @@ method:
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.
timeRequired: 2–3 hours
category: decide
- content: ./_includes/methods/markdown/site-mapping.md
---
+
+## How to do it{#how-site-mapping}
+
+1. List each page of a website or section.
+1. Take a screenshot of each page. Create a thumbnail for each screenshot.
+1. 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.
+1. Use the diagram to guide choices about things like information architecture and URL structures.
+
+
+
+## Considerations for use in government{#con-site-mapping}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/storyboarding.md b/content/methods/decide/storyboarding.md
index fa07fe0a..61b6ebbf 100644
--- a/content/methods/decide/storyboarding.md
+++ b/content/methods/decide/storyboarding.md
@@ -15,5 +15,19 @@ method:
why: To visualize interactions and relationships that might exist between a user and a solution in the context of the user's full experience.
timeRequired: 1–2 days depending on the complexity of the scenario(s)
category: decide
- content: ./_includes/methods/markdown/storyboarding.md
---
+
+## How to do it{#how-storyboard}
+
+1. Gather any documents that describe the different use cases or [scenarios]({{ "/methods/decide/user-scenarios/" | url }}) in which users will interact with your service.
+1. 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?
+1. 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.
+1. 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.
+1. 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{#con-storyboard}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/style-tiles.md b/content/methods/decide/style-tiles.md
index 2f475e62..1c0be9f2 100644
--- a/content/methods/decide/style-tiles.md
+++ b/content/methods/decide/style-tiles.md
@@ -15,5 +15,18 @@ method:
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.
timeRequired: 1–2 days depending on how many rounds of feedback the team offers
category: decide
- content: ./_includes/methods/markdown/style-tiles.md
---
+
+## How to do it{#how-style-tiles}
+
+1. Gather all the feedback and information that was provided during the initial kickoff of the project.
+1. Distill the information into different directions a solution could take. Label these directions based on what kinds of interactions and brand identity they represent.
+1. Create the appropriate number of style tiles based on the defined directions, which establish the specific visual language for the different directions.
+1. 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{#con-style-tiles}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/task-flow-analysis.md b/content/methods/decide/task-flow-analysis.md
index 7aef8098..5fc66530 100644
--- a/content/methods/decide/task-flow-analysis.md
+++ b/content/methods/decide/task-flow-analysis.md
@@ -15,5 +15,27 @@ method:
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.
timeRequired: 2-3 hours per user goal
category: decide
- content: ./_includes/methods/markdown/task-flow-analysis.md
---
+
+## How to do it{#how-task-flow}
+
+1. Based on user research, identify target users' goals that need to be analyzed.
+1. 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).
+1. 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.
+1. Present the diagram to a subject matter expert who knows the task(s) well enough to check for accuracy.
+1. 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{#add-task-flow}
+
+- [Task Analysis - Usability.gov](https://www.usability.gov/how-to-and-tools/methods/task-analysis.html)
+
+
+
+
+
+## Considerations for use in government{#con-task-flow}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/decide/user-scenarios.md b/content/methods/decide/user-scenarios.md
index 5943b20e..3fd6b299 100644
--- a/content/methods/decide/user-scenarios.md
+++ b/content/methods/decide/user-scenarios.md
@@ -15,5 +15,35 @@ method:
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.
timeRequired: 1-3 hours
category: decide
- content: ./_includes/methods/markdown/user-scenarios.md
---
+
+## How to do it{#how-user-scenario}
+
+1. Determine a few [personas]({{ "/methods/decide/personas/" | url }}) 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]({{ "/accessibility/" | url }}).
+1. For each user, list out their goals, motivations, and the context/environment in which they interact with your product, service, or website.
+1. 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.
+
+1. Share the user scenarios that you’ve written with the user group (and other relevant team members) for validation, feedback, and refinement.
+1. 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{#add-user-scenario}
+
+- [Scenarios — Usability.gov](https://www.usability.gov/how-to-and-tools/methods/scenarios.html)
+
+
+
+
+
+## Considerations for use in government{#con-user-scenario}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/discover/cognitive-walkthrough.md b/content/methods/discover/cognitive-walkthrough.md
index 17f35840..1b553b70 100644
--- a/content/methods/discover/cognitive-walkthrough.md
+++ b/content/methods/discover/cognitive-walkthrough.md
@@ -13,5 +13,24 @@ method:
why: To get quick and early feedback on whether a design solution is easy for a new or infrequent user to learn, and why it is or isn’t easy. This method is useful for catching big issues at any stage in the design process when you don't have access to real users, but it is not a substitute for user evaluation.
timeRequired: 30 minutes to one hour per person
category: discover
- content: ./_includes/methods/markdown/cognitive-walkthrough.md
---
+
+## How to do it{#how-to-cog-walkthrough}
+
+1. Identify specific traits for new or infrequent users of a design solution.
+1. Develop a set of representative tasks that emphasize new use or infrequent use.
+1. Designate a member of the design team to play the role of a user. That person will use the traits you've identified to participate in a moderated usability testing session. (The traits can overlap.)
+1. Ask the user to accomplish their goal using a printed or interactive design. As they go, ask what they would attempt to do next or how they would learn.
+ 1. Don't lead the user through the task, but encourage them to stay focused on what they're trying to accomplish.
+ 1. Pay attention to expected outcomes and how quickly/easily participants are able to pick up a task.
+1. Analyze the walkthrough results to highlight where the user struggled and what needs improvement.
+
+
+
+
+## Considerations for use in government{#considerations-cog-walkthrough}
+
+No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation (e.g., not a survey) that a cognitive walkthrough entails, 5 CFR 1320.3(h)3.
+
+If you are not working with government employees, you will need to observe standard precautions for archiving personally identifiable information.
+
diff --git a/content/methods/discover/contextual-inquiry.md b/content/methods/discover/contextual-inquiry.md
index 8806c4f3..f243fc43 100644
--- a/content/methods/discover/contextual-inquiry.md
+++ b/content/methods/discover/contextual-inquiry.md
@@ -15,5 +15,39 @@ method:
why: To learn how and why users do what they do; to discover needs and attitudes that might not emerge in an interview to map how tools, digital and otherwise, interact during complex activities.
timeRequired: 1-2 hours per user
category: discover
- content: ./_includes/methods/markdown/contextual-inquiry.md
---
+
+## How to do it{#how-contextual-inquiry}
+
+1. With permission from a supervisor and from the participant, schedule a time to watch a typical work activity and record data.
+1. While observing, ask the participant to act normally. Pretend you're a student learning how to do the job. Ask questions to help you understand what the person is doing and why.
+1. At the end of the session, explain what you have learned and check for errors.
+1. Immediately after, write up your notes.
+
+
+
+## Example{#ex-contextual-inquiry}
+
+A pair of 18F team members visited two Department of Labor/Wage Hour Division investigators as they interviewed home health care workers who were subject to unpaid overtime and other infractions. Since it was a sensitive subject, the 18F team did not question the health care workers directly, but instead asked the investigators clarifying questions in private. 18F staff also made sure that photos did not include faces.
+
+
+
+
+
+## Additional resources{#add-contextual-inquiry}
+
+-
+ Observational research: 5 tips for improving your approach - GOV.UK
+
+
+
+
+
+
+## Considerations for use in government{#con-contextual-inquiry}
+
+No PRA implications, if done properly. Contextual interviews should be non-standardized, conversational, and based on observation. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for
+[Recruiting]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
+For internal folks, get permission from the right level of management. If participants could be under union agreements, contact the agency's labor relations team.
+
diff --git a/content/methods/discover/design-studio.md b/content/methods/discover/design-studio.md
index 3428ac8e..389c6d81 100644
--- a/content/methods/discover/design-studio.md
+++ b/content/methods/discover/design-studio.md
@@ -15,5 +15,29 @@ method:
why: To create a shared understanding and appreciation of design problems confronting the project team.
timeRequired: 3–4 hours
category: discover
- content: ./_includes/methods/markdown/design-studio.md
---
+
+## How to do it{#how-design-studio}
+
+1. Invite between six and 12 participants: stakeholders, users, and team members who need to build a shared understanding. Before the meeting, share applicable research, [user personas]({{ "/methods/decide/personas/" | url }}) (unless users will be present), and the design prompt for the exercise.
+1. Bring drawing materials. At the start of the meeting, review the design prompt and research you shared.
+1. Distribute drawing materials. Ask participants to individually sketch concepts that address the prompt. Remind them that anyone can draw and artistic accuracy is not the goal of the exercise. 15–20 minutes.
+1. Have participants present their ideas to one another in groups of three and solicit critiques.
+1. Ask the groups to create a design that combines the best aspects of members' individual contributions.
+1. Regroup as a whole. Have each group of three present their ideas to everyone. Discuss.
+1. After the meeting, note areas of consistent agreement or disagreement. Incorporate areas of consensus into design recommendations and areas of contention into a research plan.
+
+
+
+## Example from 18F{#ex-design-studio}
+
+- ["User-centered design at 18F: a design studio for natural resource revenues"](https://18f.gsa.gov/2014/09/25/design-studio-onrr/) Chris Cairns , Michelle Hertzfeld , Nick Bristow.
+
+
+
+
+
+## Considerations for use in government{#con-design-studio}
+
+No PRA implications. If conducted with nine or fewer members of the public, the PRA does not apply, 5 CFR 1320.5(c)4. If participants are employees, the PRA does not apply.
+
diff --git a/content/methods/discover/dot-voting.md b/content/methods/discover/dot-voting.md
index cc81241e..f6ee47fc 100644
--- a/content/methods/discover/dot-voting.md
+++ b/content/methods/discover/dot-voting.md
@@ -17,5 +17,21 @@ method:
why: To reach a consensus on priorities of subjective, qualitative data with a group of people. This is especially helpful with larger groups of stakeholders and groups with high risk of disagreement.
timeRequired: 15 minutes
category: discover
- content: ./_includes/methods/markdown/dot-voting.md
---
+
+## How to do it{#how-dot-voting}
+
+1. Bring plenty of sticky notes and colored stickers to the meeting.
+1. Gather everyone on the product team and anyone with a stake in the product.
+1. Quickly review the project's goals and the conclusions of any prior user research.
+1. Ask team members to take five minutes to write important features or user needs on sticky notes. (One feature per sticky note.)
+1. After five minutes, ask participants to put their stickies on a board. If there are many sticky notes, ask participants to put their features next to similar ones. Remove exact duplicates.
+1. Give participants three to five colored stickers and instruct them to place their stickers on features they feel are most important to meeting the project's goals and user needs. If the group is recently formed, or for other reasons has a low level of established trust and equity, consider a set-up where people can vote privately, e.g. on paper. You’ll need a few extra minutes to compile and display.
+1. Identify the features with the largest number of stickers (votes). Have the team review the voting for whether familiarity bias is resulting in enshrining the status quo.
+
+
+
+## Considerations for use in government{#con-dot-voting}
+
+No PRA implications: dot voting falls under "direct observation", which is explicitly exempt from the PRA, 5 CFR 1320(h)3. See the methods for [Recruiting]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
diff --git a/content/methods/discover/five-whys.md b/content/methods/discover/five-whys.md
index c8120b5a..42060493 100644
--- a/content/methods/discover/five-whys.md
+++ b/content/methods/discover/five-whys.md
@@ -15,5 +15,33 @@ method:
why: To identify the root cause(s) of an issue or problem.
timeRequired: Less than 1 hour
category: discover
- content: ./_includes/methods/markdown/five-whys.md
---
+
+## How to do it{#how-five-whys}
+
+Select a particular issue or problem from your user research to investigate further. This could be the most commonly occurring problem or a problem that has been prioritized by the team.
+Ask why the problem occurred and write down an answer. Repeat this process another four times, building off of the previous response each time to drill down to a root cause. As you probe, make sure you remain sensistive to the emotional response of the interviewee. Sometimes asking why multiple times can cause the interviewee to feel frustrated or defensive if they don’t feel as if they are being heard. See example below:
+
+Starting problem: “We didn’t meet our goal for public feedback during the open comment period.”
+1. *Why?*
+“Not enough people submitted comments.” +1. *Why?*
+“Not enough people made it to the comment submission form.” +1. *Why?*
+“The comment submission form was hard to find.” +1. *Why?*
+“The link to the comment submission form was buried on the page.” +1. *Why?*
+“We didn’t formulate and publish a call to action to submit comments.” + +After getting to a root cause, frame or reframe your problem solving approach to address it (e.g., “how might we create a call to action for comment submission?”). + +*Note: You may ask “why” more or less than five times during this process. The purpose of this exercise is to help identify what is the root cause. Ask “why” as many times as needed to get to what you think the root cause is, while keeping the mental cost of the interviewee in mind.* + +
+
+## Considerations for use in government{#con-five-whys}
+
+No PRA implications. No information is collected from members of the public.
+
+
diff --git a/content/methods/discover/heuristic-evaluation.md b/content/methods/discover/heuristic-evaluation.md
index ed9e6659..08fdc6f1 100644
--- a/content/methods/discover/heuristic-evaluation.md
+++ b/content/methods/discover/heuristic-evaluation.md
@@ -17,5 +17,29 @@ method:
why: To quickly identify common design problems that make websites hard to use without conducting more involved user research.
timeRequired: 1–2 hours
category: discover
- content: ./_includes/methods/markdown/heuristic-evaluation.md
---
+
+## How to do it{#how-heuristic-eval}
+
+1. Recruit a group of three to five people familiar with evaluation methods. These people are not necessarily designers, but are familiar with common usability best practices. They are usually not users.
+1. Ask each person to individually create a list of "heuristics" or general usability best practices. Examples of heuristics from Nielsen's "10 Usability Heuristics for User Interface Design" include:
+ 1. The website should keep users informed about what is going on, through appropriate feedback within reasonable time.
+ 1. The system should speak the user's language, with words, phrases and concepts familiar to the user, rather than system-oriented terms.
+1. Consider what hazards the service or product might hold for its users, and include heuristics to evaluate whether the site protects against possible harms.
+1. Ask each person to evaluate the website against their list and write down possible problems.
+1. After individual evaluations, gather people to discuss what they found and prioritize potential problems.
+
+
+
+## Additional resources{#add-heuristic-eval}
+
+- [10 usability heuristics for user interface design — Nielsen Norman Group](https://www.nngroup.com/articles/ten-usability-heuristics/)
+- [USDA Digital strategy tools — Research — Heuristic review template](https://www.usda.gov/digital-strategy/tools)
+
+
+
+
+## Considerations for use in government{#con-heuristic-eval}
+
+No PRA Implications, as heuristic evaluations usually include a small number of evaluators. If conducted with nine or fewer members of the public, the PRA does not apply, 5 CFR 1320.5(c)4. If participants are employees, the PRA does not apply. See the methods for [Recruiting]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
diff --git a/content/methods/discover/hopes-and-fears.md b/content/methods/discover/hopes-and-fears.md
index 12b5a8dc..e038b23b 100644
--- a/content/methods/discover/hopes-and-fears.md
+++ b/content/methods/discover/hopes-and-fears.md
@@ -15,5 +15,31 @@ method:
why: To establish a baseline understanding of a group’s expectations and concerns about a project and to give each person an opportunity to voice their perspective
timeRequired: 30–60 mins
category: discover
- content: ./_includes/methods/markdown/hopes-and-fears.md
---
+
+## How to do it{#how-hopes-fears}
+
+ 1. Ahead of the session, establish what you want to elicit hopes and fears about. For example, you could ask participants to focus on the whole project or that day’s workshop.
+ 2. At the beginning of the session, create two columns labeled “Hopes” and “Fears” on a white board or large sticky pad.
+(In a remote setting, you can do this online using collaboration software such as Mural or Google Docs)
+ 3. Ask participants to take 1-2 mins to write down their hopes on sticky notes (one hope per sticky note).
+ 4. Invite participants to come up one at a time and add their “hopes” sticky notes to the board and say more about what they wrote. Have participants group their sticky notes as they add them to the board to illustrate emerging themes.
+ 5. Repeat steps 3 and 4 with fears.
+
+This format can be adapted to include other categories. For example, asking participants to write down skills and experiences can help contextualize each person’s place in the group.
+
+
+
+## Example{#ex-hopes-fears}
+
+- [Three small steps you can take to reboot agile in your organization — 18F Blog](https://18f.gsa.gov/2016/10/25/three-small-steps-you-can-take-to-reboot-agile-in-your-organization/)
+
+
+
+
+
+
+## Considerations for use in government{#con-hopes-fears}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/discover/kj-method.md b/content/methods/discover/kj-method.md
index ce210962..16aa973e 100644
--- a/content/methods/discover/kj-method.md
+++ b/content/methods/discover/kj-method.md
@@ -15,5 +15,26 @@ method:
why: To reach a consensus on priorities of subjective, qualitative data with a group of people. This is especially helpful with larger groups of stakeholders and groups with high risk of disagreement.
timeRequired: 1–2 hours
category: discover
- content: ./_includes/methods/markdown/kj-method.md
---
+
+## How to do it{#how-kj}
+
+1. Gather four or more participants for 90 minutes. Provide sticky notes and markers.
+1. Create a focused question about the project's needs and select a facilitator to run the exercise.
+1. Give participants five minutes to write at least three responses to the question, each on its own note.
+1. Give participants 15 minutes to put their answers on the wall, read everyone else's, and make additions. Have participants cluster similar answers without discussion.
+1. Ask participants to write names for each cluster on their own - this is mandatory. They may also split clusters.
+1. Put each name on the wall by its cluster. Exclude word-for-word duplicates.
+1. Reiterate the question and have each person rank their three most important clusters. Visually tally points.
+1. Combine duplicates and their points if the entire group agrees they're identical. Three or four groups usually rank higher than the rest - these are the priorities for the question.
+
+
+
+## Example from 18F{#ex-kj}
+
+18F conducted this exercise with 20 Federal Election Commission staff members to define priorities around conflicting requests. We used this method to get data from staff (not the decision makers) about what they saw as the most pressing needs. We synthesized and presented the data back to the decision makers.
+
+
+## Considerations for use in government{#con-kj}
+
+At 18F, KJ participants are almost always federal employees. If there is any chance your KJ workshop could include participants who are not federal employees, consult OMB guidance on the Paperwork Reduction Act and the Privacy Act. Your agency's Office of General Counsel, and perhaps OIRA desk officers, also can ensure you are following the laws and regulations applicable to federal agencies.
diff --git a/content/methods/discover/lean-coffee.md b/content/methods/discover/lean-coffee.md
index e5c177ba..a7bb9347 100644
--- a/content/methods/discover/lean-coffee.md
+++ b/content/methods/discover/lean-coffee.md
@@ -15,5 +15,30 @@ method:
why: To give everyone equal opportunity to surface ideas and vote on agenda topics, allowing meeting attendees to be co-owners in the meeting agenda.
timeRequired: Flexible
category: discover
- content: ./_includes/methods/markdown/lean-coffee.md
---
+
+## How to do it{#how-lean-coffee}
+
+1. Give meeting participants two minutes to write what they would like to talk about on sticky notes (one idea per sticky note)
+1. Have meeting participants review the topics generated and [dot vote]({{ "/methods/discover/dot-voting/" | url }}) on the topics they are most interested in
+1. Decide how much time will be spent talking about each topic
+1. Start with the topic that got the most votes
+1. At the end of the allotted time, have meeting participants vote:
+ - Thumbs up: Continue talking about the topic for a shorter set amount of time
+ - Thumbs down: Move to the next topic
+
+
+
+## Example from 18F{#ex-lean-coffee}
+
+At 18F, Lean coffee is often used to facilitate community of practice meetings and team meetings when the objective is to provide a forum for the meeting attendees to raise issues that are of interest to them. This method provides structure to these meetings and ensures topics are democratically selected for conversation.
+
+
+
+
+
+## Considerations for use in government{#con-lean-coffee}
+
+No PRA implications. No information is collected from members of the public.
+
+
diff --git a/content/methods/discover/stakeholder-and-user-interviews.md b/content/methods/discover/stakeholder-and-user-interviews.md
index 1ffb73eb..b3a62305 100644
--- a/content/methods/discover/stakeholder-and-user-interviews.md
+++ b/content/methods/discover/stakeholder-and-user-interviews.md
@@ -15,5 +15,29 @@ method:
why: To build consensus about the problem statement and research objectives.
timeRequired: 1–2 hours per interviewee
category: discover
- content: ./_includes/methods/markdown/stakeholder-and-user-interviews.md
---
+
+## How to do it{#how-stake}
+
+ 1. Create a guide for yourself of some topics you'd like to ask about, and some specific questions as a back up. Questions will often concern the individual's role, the organization, the individuals' needs, and metrics for success of the project. Consider how the interview could harm the participant, and adjust your questions to avoid those hazards. For example, might your questions trigger thoughts of painful experiences?
+ 1. Sit down one-on-one with the participant, or two-on-one with a note-taker or joint interviewer, in a focused environment. Introduce yourself. Explain the premise for the interview as far as you can without biasing their responses.
+ 1. Follow the conversation where the participant takes it. They will focus on their priorities and interests. Be comfortable with silences, which allow the participant to elaborate. To keep from getting entirely off course, use your interview guide to make sure you cover what you need to. Ask lots of "why is that" and "how do you do that" questions. Consider asking if there are ways the service or product could cause harm to its users if not done carefully, or what assumptions are being made (leaving it ambiguous as to whether we’re referring to our questions or in the service/product).
+ 1. If there are other products they use or your product doesn't have constraints imposed by prior work, observe the stakeholders using a competing product and consider a [comparative analysis]({{ "/methods/decide/comparative-analysis/" | url }}).
+
+
+
+## Additional resources
+
+- [Interview checklist]({{ "/methods/interview-checklist/" | url }})
+- [Tips for capturing the best data from user interviews — 18F Blog](https://18f.gsa.gov/2016/02/09/tips-for-capturing-the-best-data-from-user-interviews/)
+- [Build empathy with stakeholder interviews, part 1: Preparation — 18F Blog](https://18f.gsa.gov/2016/06/20/build-empathy-with-stakeholder-interviews-part-1-preparation/)
+- [Build empathy with stakeholder interviews, part 2: Conversation — 18F Blog](https://18f.gsa.gov/2016/07/22/building-empathy-with-stakeholder-interviews-part-2-conversation/)
+
+
+
+
+
+## Considerations for use in government{#con-stake}
+
+No PRA implications. The PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3. See the methods for [Recruiting]({{ "/methods/fundamentals/recruiting/" | url }}) and [Privacy]({{ "/methods/fundamentals/privacy/" | url }}) for more tips on taking input from the public.
+
diff --git a/content/methods/discover/stakeholder-influence-mapping.md b/content/methods/discover/stakeholder-influence-mapping.md
index e3867c2f..dff59aab 100644
--- a/content/methods/discover/stakeholder-influence-mapping.md
+++ b/content/methods/discover/stakeholder-influence-mapping.md
@@ -15,5 +15,25 @@ method:
why: To uncover and describe power dynamics — the often-unspoken balances of influence and control — that could impact project outcomes; prioritize which stakeholders to engage with and how, and inform a communication and engagement approach.
timeRequired: ~1 hour
category: discover
- content: ./_includes/methods/markdown/stakeholder-influence-mapping.md
---
+
+## How to do it{#how-stake-i}
+
+1. Gather the team and, ideally, at least one crucial stakeholder familiar with their organization and how it works from both a technical and an interpersonal point of view.
+1. If meeting in person, you’ll need sticky notes and a whiteboard; if meeting remotely, use a virtual whiteboard or tools that support online document collaboration, ideally simultaneously.
+1. Divide the whiteboard into four areas, as a grid. Label the x axis influence and the y axis interest.
+1. List out stakeholders together. Write down names of people, groups, communities, or organizations that your work may impact, and organize them into the four quadrants based on your understanding of their relative influence and interest.
+1. Look at each quadrant to sort who to engage with and how:
+ - interested and influential - collaborate with them
+ - either influential or interested - keep them informed
+ - neither influential nor interested - allow them to drive their own involvement
+1. If your map reveals power dynamics that route around policy, consider whether the information poses personal or professional risk to any stakeholders. Avoid possible harm by sharing this map with only the people who need to understand it, and consider the consequences of those you do share with — or share an edited version.
+1. Review and update the map as you understand the situation better.
+
+
+
+## Considerations for use in government{#con-stake-i}
+
+No PRA implications. No information is collected from members of the public.
+
+
diff --git a/content/methods/fundamentals/compensation.md b/content/methods/fundamentals/compensation.md
index 93d2548e..88a08326 100644
--- a/content/methods/fundamentals/compensation.md
+++ b/content/methods/fundamentals/compensation.md
@@ -16,7 +16,29 @@ method:
what: Offering usability test or user research participants compensation to encourage participation and to thank them for their time.
why: Compensating participants for sharing their time and lived experience with your team often results in a more diverse, representative set of participants. Without compensation, you often end up recruiting people with a strong intrinsic interest in your website. These people may not have the same needs and experiences as a less interested pool of users. With compensation, you can encourage less interested, more representative people to participate.
timeRequired: N/A
- content: ./_includes/methods/markdown/compensation.md
---
+## How to do it{#how-to-compensation}
+
+1. Figure out what's legal and appropriate. Consult your agency's Office of General Counsel on options for providing compensation to encourage participation in usability testing, consistent with your agency's authorities. The options will depend upon your agency's authorities and the specific facts.
+1. Consider contracting for a recruiting service to help you get an effective research pool.
+1. If compensation is allowed, clearly communicate when and how participants will receive compensation. In the emails, postings, or other materials you use to recruit your participants, describe the compensation and how participants will receive it (via mail, pick up at an office, etc.). This is particularly important for "remote" research.
+
+
+
+## Example{#example-compensation}
+
+- [Compensating research participants — TTS Handbook](https://handbook.tts.gsa.gov/18f/how-18f-works/research-guidelines/#compensating-user-research-participants)
+
+
+
+
+
+## Considerations for use in government{#considerations-compensation}
+
+No PRA implications. Even when users are present, the PRA explicitly exempts direct observation and non-standardized conversation, 5 CFR 1320.3(h)3.
+
+If you are not working with government employees, you will need to observe standard precautions for archiving personally identifiable information.
+
+
diff --git a/content/methods/fundamentals/privacy.md b/content/methods/fundamentals/privacy.md
index b52eb72f..774d6d0d 100644
--- a/content/methods/fundamentals/privacy.md
+++ b/content/methods/fundamentals/privacy.md
@@ -16,6 +16,30 @@ method:
what: Designers potentially might work with many different categories of information, across a number of different contexts. You have an obligation to steward information in a way that respects privacy.
why: Designers have an obligation to respect and protect privacy. People will not honestly participate in design processes, nor make use of products and services, they do not trust.
timeRequired: N/A
- content: ./_includes/methods/markdown/privacy.md
---
+## How to do it{#how-to-privacy}
+
+ 1. Familiarize yourself with the [Fair Information Practice Principles](https://www.fpc.gov/resources/fipps/), a set of precepts at the heart of the U.S. Privacy Act of 1974.
+ 1. Consult your organization's privacy office, which may include your general counsel, if you plan to substantially make use of information that could potentially identify specific individuals.
+ 1. Inform and collect the voluntary consent of anyone who participates in moderated design research. Ensure that all unmoderated forms of research (for example, web analytics) are covered by an easy-to-access privacy policy.
+ 1. Pay special attention to all categories of information used throughout the design process. Note contexts in which it's not okay to share certain categories of information.
+
+
+
+## Additional resources{#add-privacy}
+
+- [Doing research at TTS — TTS Handbook](https://handbook.18f.gov/research-guidelines/)
+- [Privacy — TTS Handbook](https://handbook.tts.gsa.gov/launching-software/privacy)
+
+
+
+
+## Considerations for use in government{#con-privacy}
+
+The government's use of information about people is subject to a number of laws and policies, including: the Privacy Act of 1974, the Federal Information Security Management Act of 2002, and the eGovernment Act of 2002.
+
+Conduct a Privacy Threshold Analysis in collaboration your agency's privacy office whenever a design calls for the creation of a new data store (for example, a database).
+
+Ensure all collections of personally identifiable information (PII) are accompanied by a Privacy Act Notice. See, for example, GSA's Privacy Act Notice for Design Research.
+
diff --git a/content/methods/fundamentals/recruiting.md b/content/methods/fundamentals/recruiting.md
index c43fd5e0..f355431c 100644
--- a/content/methods/fundamentals/recruiting.md
+++ b/content/methods/fundamentals/recruiting.md
@@ -16,5 +16,26 @@ method:
what: Identifying and gathering people to interview or who will test your product.
why: Recruiting people who represent your core user group is a critical and oft-overlooked part of research. Time spent with the right people using the wrong methods is better than time spent with people who aren’t your core users while using the right methods.
timeRequired: 1–2 weeks for 5–10 participants
- content: ./_includes/methods/markdown/recruiting.md
---
+
+## How to do it{#how-recruiting}
+
+### Seek out people who{#seek-recruiting}
+- Are trying to use the thing you are working on right at that very moment.
+- Recently tried to use the thing you are working on.
+- Used the thing you are working on less recently.
+- Have used something like what you are working on, and are likely to use what you are working on.
+
+### Reach them through{#reach-recruiting}
+- Relevant community organizations.
+- Impromptu requests in or near the relevant environment.
+- Your personal and professional network.
+- The new or existing website.
+- Existing mailing lists.
+
+
+
+## Considerations for use in government{#con-recruiting}
+
+No PRA implications. No information is collected from members of the public.
+
diff --git a/content/methods/index.md b/content/methods/index.md
index 7e8e9370..b7a2165c 100644
--- a/content/methods/index.md
+++ b/content/methods/index.md
@@ -7,6 +7,7 @@ redirect_from:
- methods/archive/bodystorming/
layout: layouts/default
tags: methods
+eleventyExcludeFromCollections: true
---
+ 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]. +
+ +1. 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]. +
+ +1. 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. + ++“Not enough people submitted comments.” +1. *Why?*
+“Not enough people made it to the comment submission form.” +1. *Why?*
+“The comment submission form was hard to find.” +1. *Why?*
+“The link to the comment submission form was buried on the page.” +1. *Why?*
+“We didn’t formulate and publish a call to action to submit comments.” + +After getting to a root cause, frame or reframe your problem solving approach to address it (e.g., “how might we create a call to action for comment submission?”). + +*Note: You may ask “why” more or less than five times during this process. The purpose of this exercise is to help identify what is the root cause. Ask “why” as many times as needed to get to what you think the root cause is, while keeping the mental cost of the interviewee in mind.* + +
diff --git a/content/methods/interview-checklist.md b/content/methods/interview-checklist.md
index 85f7fe23..13899da0 100644
--- a/content/methods/interview-checklist.md
+++ b/content/methods/interview-checklist.md
@@ -3,6 +3,7 @@ title: Interview checklist
permalink: /methods/interview-checklist/
layout: layouts/page
tags: methods
+eleventyExcludeFromCollections: true
---