Skip to content

Commit

Permalink
Merge pull request 18F#197 from 18F/staging
Browse files Browse the repository at this point in the history
Pushing some content edits from staging to master.
  • Loading branch information
MelissaBraxton authored Apr 27, 2017
2 parents 8f4043c + 733d901 commit e7a3506
Show file tree
Hide file tree
Showing 18 changed files with 70 additions and 112 deletions.
3 changes: 0 additions & 3 deletions _config.yml
Original file line number Diff line number Diff line change
Expand Up @@ -113,9 +113,6 @@ navigation:
url: make/
internal: true
children:
- text: Protosketching
url: protosketching/
internal: true
- text: Wireframing
url: wireframing/
internal: true
Expand Down
12 changes: 6 additions & 6 deletions _pages/decide/comparative-analysis.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,23 +10,23 @@ A detailed review of existing experiences provided either by direct competitors

## Reasons to use it

To identify competitors’ solutions that excel, are lacking, or are missing critical design elements. Comparative analysis can give new solutions a competitive edge by identifying areas of opportunity, gaps in experience offerings, and potential design patterns to adopt or avoid.
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

**Medium:** 1–2 hours per identified competitor. One hour to analyze each competitor. 4–8 hours total to generate a report.
**Medium:** 1–2 hours to analyze and write an evaluation about each competitor.

## How to do it

1. Identify a list of services or agencies that would be either direct or related competitors to the service or client agency. Pare the list down to four or five.
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 heuristics you will use to evaluate each service or agency offering.
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.
4. Use a spreadsheet to capture the evaluation and determine how the targeted services 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.
5. Present the analysis, which should showcase opportunities that you can take advantage of and design patterns you might adopt or avoid.

## Applied in government research

Expand Down
4 changes: 2 additions & 2 deletions _pages/decide/journey-mapping.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ A visualization of the major interactions shaping a user’s experience of a pro

## Reasons to use it

To provide design teams with a bird’s-eye view of a design system, helping them see the order, complexity, successes, pain points, and interactions that make up a user’s experience.
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.

## Time required

Expand All @@ -22,7 +22,7 @@ To provide design teams with a bird’s-eye view of a design system, helping the
- People involved and their related goals
- Their behaviors in pursuit of their goals
- Information, devices, and services that support their behaviors
- Discrete moments or major decisions they make
- 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]({{ '/decide/personas/' | prepend: site.baseurl }}). Identify where personas share contextual components.
Expand Down
4 changes: 4 additions & 0 deletions _pages/decide/site-mapping.md
Original file line number Diff line number Diff line change
Expand Up @@ -29,3 +29,7 @@ To audit an existing website by assessing its structure and content. Site maps a
## Applied in government research

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

## Examples from 18F

- [Example site map from the Federal Election Commission project]({{ '/assets/downloads/FEC-Sitemap.pdf' | prepend: site.baseurl }})
20 changes: 12 additions & 8 deletions _pages/decide/task-flow-analysis.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,27 +6,31 @@ redirect_from: /task-flow-analysis/

## What it is

A step-by-step analysis of a common task a user must perform that diagrams the various touch points and decision points a user goes through to accomplish the task. The touch points should be represented as steps taken by the user, as well as steps taken by the system.
A step-by-step analysis of steps a user must take 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. If reaching the goal requires that the user interact with a system, tasks and decision points should represent steps taken by the user, as well as steps taken by the system.

## Reasons to use it

To illustrate in a solution-agnostic way the overall flow that a user progresses through to accomplish a single task. Task flow analysis also demonstrates the relationship between tasks, and how they interconnect across a site.
To validate a design team's understanding of users' goals, common scenarios, and process, 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.

## Prerequisites

**User research** Task flow analysis requires that you have a baseline understanding of your users' knowledge, goals, and behaviors.

## Time required

**Medium:** 1-2 hours per task
**Medium:** 2-3 hours per user goal

## How to do it

1. Identify the task(s) that need to be analyzed.
1. Based on user research, identify target users' goals that need to be analyzed.

2. Break each high-level task down into the subtasks and decisions that the user or system must perform. Specify the subtask in terms of objectives. Across all subtasks, you should cover the whole area of interest. Don’t make assumptions about which steps are understood.
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 layered task diagram of each subtask and decision point. The diagram must cover each step or decision necessary to accomplish the task.
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](http://www.bpmn.org/) 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. Annotate the layered task diagram to pinpoint areas of interest, risk, or potential frustration.
4. Present the diagram to a subject matter expert who knows the task(s) well enough to check for accuracy.

5. Present the analysis to a potential user or stakeholder who was not involved in creating the diagram(s) but who knows the task(s) well enough to check for consistency and 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.

## Applied in government research

Expand Down
17 changes: 6 additions & 11 deletions _pages/decide/user-scenarios.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,30 +6,25 @@ redirect_from: /user-scenarios/

## What it is

Stories and context — focused on identifying the what, who, how, and why — behind why a specific user or user group comes to your site.
A method for telling a conceptual story about a user's interaction with your website or service, focusing on the what, how and why.

## Reasons to use it

To remind a team, during both the design and validation phases, of the overarching goal(s) that users have when interacting with a solution. Scenarios help the team consider the design of the solution as a whole rather than getting caught up by specific pages, elements, or interactions. They note questions and goals and sometimes define the possibilities of how the user(s) can achieve them.
To communicate a design idea by telling a story about a specific interaction that a system supports. Through creating user scenarios, you'll identify what the user's motivations are for coming to your site as well as their expectations and goals. User scenarios also help the team answer questions about what the product should do as well as how it should look and behave.

## Time required

**Small:** 1-3 hours

## How to do it

1. Identify the target user group and any common user goals and scenarios that a person must go through when interacting with a solution.
1. Determine a [persona]({{ '/decide/personas/' | prepend: site.baseurl }}) or user group to focus on.

2. Decide which type of scenario you’re going to write.
- Goal or task-based: Short and specific, focus on the core aspects of the goal or task.
- Elaborate: Provide additional details about the environment and context.
- Full scale: Include various steps a user needs to take as well as their environment and context.
2. Begin to list out the user’s goals, motivations, and the context/environment in which they interact with your site or service.

3. Describe why it’s important for a user to be able to accomplish their goal or complete the scenario.
3. Put the details you came up with in step 2 into a story format that includes information about who they are (persona or user group), why they are using your site or service (motivations), where they are (context), what they need to do (their goal), and how they go about accomplishing their goal (tasks). Keep in mind, the more realistic details you add, the richer and more useful your story becomes for helping in understanding your user’s behaviors.

4. Share with the full team for feedback and refinement.

5. If you want to use the scenarios for [usability testing]({{ '/validate/usability-testing' | prepend: site.baseurl }}), write them so they do not lead the participant to the correct outcome.
4. Share the user scenarios you’ve written with the larger team for feedback and refinement.

## Applied in government research

Expand Down
6 changes: 3 additions & 3 deletions _pages/discover/cognitive-walkthrough.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ redirect_from: /cognitive-walkthrough/

## What it is

An evaluation method in which evaluators work through a set of representative tasks and ask questions about the task as they go.
An evaluation method in which people work through a set of representative tasks and ask questions about the task as they go.

## Reasons to use it

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 i 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.
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.

## Time required

Expand All @@ -22,7 +22,7 @@ To get quick and early feedback on whether a design solution is easy for a new o

2. Develop a set of representative tasks that emphasize new use or infrequent use.

3. Designate a member of the design team to play the role of a user who has the traits you’ve identified to participate in a moderated usability testing session. (The traits can overlap.)
3. 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.)

4. 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.
- Don't lead the user through the task, but encourage them to stay focused on what they’re trying to accomplish.
Expand Down
5 changes: 2 additions & 3 deletions _pages/fundamentals/incentives.md
Original file line number Diff line number Diff line change
Expand Up @@ -10,13 +10,12 @@ Offering usability test or user research participants gifts to encourage partici

## Why it is important

Incentives often result in a more diverse, representative set of participants. Without incentives, 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 but larger pool of users. With incentives, you can encourage less interested, more representative people to participate.

Incentives often result in a more diverse, representative set of participants. Without incentives, 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 incentives, you can encourage less interested, more representative people to participate.

## How to do it

1. **Figure out what’s legal and appropriate.** Consult your agency’s Office of General Counsel on options for providing incentives or gifts 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.

2. **Consider contracting for a recruiting service to help you get an effective research pool.**

3. **If incentives are determined to be permissible, clearly communicate when and how participants will receive incentives.** In the emails, postings or other materials you use to recruit your participants, describe the incentive and how participants will receive it (via mail, pick up at an office, etc.). This is particularly important for “remote” research.
3. **If incentives are determined to be permissible, clearly communicate when and how participants will receive incentives.** In the emails, postings, or other materials you use to recruit your participants, describe the incentive and how participants will receive it (via mail, pick up at an office, etc.). This is particularly important for research conducted virtually rather than in person.
4 changes: 2 additions & 2 deletions _pages/fundamentals/privacy.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ redirect_from: /privacy/

## What it is

Our obligation to keep data about research participants secure. Covered by laws like the Privacy Act, Federal Information Security Management Act and eGovernment Act.
Our obligation to keep data about research participants secure. Covered by laws like the Privacy Act, Federal Information Security Management Act, and eGovernment Act.

## Why it is important

You have a moral, legal, and ethical obligation to protect people’s privacy. Also, if people do not believe you will protect their privacy, they will be unlikely to participate in your research.
You have a moral, legal, and ethical obligation to protect people’s privacy. Also, if people do not believe you will protect their privacy, they'll be unlikely to participate in your research.

## How to do it:

Expand Down
22 changes: 11 additions & 11 deletions _pages/fundamentals/recruiting.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ redirect_from: /recruiting/

## What it is

Identifying and gathering people to interview or who will test your product.
Identifying and gathering people to interview or test your product.

## Why it is important

Expand All @@ -18,18 +18,18 @@ Recruiting people who represent your core user group is a critical and oft-overl

## Seek out people who:

- 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.
- Are trying to use the thing you're working on right at that very moment
- Recently tried to use the thing you're working on
- Used the thing you're working on less recently
- Have used something like what you're working on and are likely to use what you're working on

## Reach them through
## Reach them through:

- Relevant community organizations.
- Impromptu requests in or near the relevant environment.
- Your personal and professional network.
- The new or existing website.
- Existing mailing lists.
- Relevant community organizations
- Impromptu requests in or near the relevant environment
- Your personal and professional network
- The new or existing website
- Existing mailing lists

## Applied in government research

Expand Down
1 change: 0 additions & 1 deletion _pages/make.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,6 @@ Move toward a final product that’s ready to be released and tested.

### Conceptual design

- [Protosketching](protosketching/)
- [Wireframing](wireframing/)

### Detailed design
Expand Down
10 changes: 5 additions & 5 deletions _pages/make/design-pattern-library.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,21 +6,21 @@ redirect_from: /design-pattern-library/

## What it is

A collection of UI elements used frequently across a design system, consisting of the base patterns and helpful information about how to use them.
A collection of user interface elements (for example colors, icons, and buttons) used frequently across a website or service, consisting of the base patterns and helpful information about how to use them.

## Reasons to use it

To aid in designing a solution that uses UI elements consistently. Maintaining a set of approved, reusable patterns makes it easier to produce new features or make updates to the current solution.
To aid in designing a solution that uses user interface elements consistently. Maintaining a set of approved, reusable patterns makes it easier to produce new features or make updates to existing products or services.

## Time required

**Large:** 1–2 hours per pattern for initial documentation, with ongoing maintenance and extension.

## How to do it

1. Start identifying common components as early as possible, ideally while you and the team are creating new design elements. These common pieces form the patterns that you will create guidelines for. Specify the components that make up each UI pattern and note possible constraints or restrictions.
1. Start identifying common components as early as possible, ideally while you and the team are creating new design elements. These common pieces form the patterns that you will create guidelines for. Specify the components that make up each user interface pattern and note possible constraints or restrictions.

2. Describe or visualize how someone will use the pattern and how it should respond to the user. (For example: how a button renders on load, hover, and click.) Provide any data as to why it is good for the end user.
2. Describe or visualize how someone will use the pattern and how it should respond to the user. (For example: how a button renders on load, hover, and click.) Provide any data as to why it's good for the end user.

3. Include any code or snippets that front end developers can use to implement the pattern.

Expand All @@ -34,7 +34,7 @@ No PRA implications. No information is collected from members of the public.

## Examples
- [The Draft U.S. Web Design Standards, a pattern library for the federal government from 18F](https://standards.usa.gov/)
- [Blog posts from 18F about the process of creating the U.S. Web Design Standards](https://18f.gsa.gov/tags/web-design-standards/)
- [Blog posts from 18F about the process of creating the Draft U.S. Web Design Standards](https://18f.gsa.gov/tags/web-design-standards/)
- [Open FEC's pattern library from 18F](https://github.com/18F/fec-pattern-library)

## Additional resources
Expand Down
Loading

0 comments on commit e7a3506

Please sign in to comment.