Exploration

Make some things based on your interpretation.

Design pattern library

What

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.

Why

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.

Templates

Time required

1–2 hours per pattern; ongoing maintenance.

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.
  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.
  3. Include any code or snippets that front end developers can use to implement the pattern.
  4. Show examples of how the same pattern could work in different solutions.
  5. Publish the design pattern library in an open, accessible space where the product team can use and extend it. (Common implementations of a design pattern library are in a wiki or brand style guide.)

Considerations for use in government

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

Design studio

What

An illustration-based way to facilitate communication (and brainstorming) between a project team and stakeholders.

Why

To create a shared understanding and appreciation of design problems confronting the project team.

Templates

Time required

3–4 hours

How to do it

  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 (unless users will be present), and the design prompt for the exercise.
  2. Bring drawing materials. At the start of the meeting, review the design prompt and research you shared.
  3. 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.
  4. Have participants present their ideas to one another in groups of three and solicit critiques.
  5. Ask the groups to create a design that combines the best aspects of members’ individual contributions.
  6. Regroup as a whole. Have each group of three present their ideas to everyone. Discuss.
  7. 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

Considerations for use in government

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.

Prototyping

What

A rudimentary version, either static or functional, of something that exhibits realistic form and function.

Why

To enable direct examination of a design concept’s viability with a number of other methods such as usability testing or a cognitive walkthrough. Static prototypes (often paper) are helpful for gaining feedback on users’ intentions and various design elements. Functional prototypes (often coded) are helpful for observing how users interact with the product.

Templates

Time required

4 hours

How to do it

  1. Create a rudimentary version of your product. It can be static or functional. Think in the same way you would about a wireframe: demonstrate structure and relationships among different elements, but don’t worry about stylized elements.
  2. Give the prototype to the user and observe their interactions without instruction.
  3. After this observation, ask them to perform a specific task.
  4. Ask clarifying questions about why they do what they do. Let the user’s behavior guide the questions you ask. It can be helpful to have them narrate their thought process as they go along.
  5. Iterate! Prototypes should be quick and painless to create, and even more quick and painless to discard.

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.

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.

Templates

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.

Additional resources

Considerations for use in government

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

Wireframing

What

A simple visual representation of a product or service interface.

Why

To prioritize substance and relationships over decoration as you begin defining the solution. Wireframing also gives designers a great opportunity to start asking developers early questions about feasibility and structure.

Templates

Time required

1-3 hours

How to do it

  1. Build preliminary blueprints that show structure, placement, and hierarchy for your product. Steer clear of font choices, color, or other elements that would distract both the researcher and the reviewer. Lightweight designs are conceptually easier to reconfigure. A few helpful tools for building wireframes are OmniGraffle and Balsamiq, which purposefully keep the wireframe looking like rough sketches.
  2. Use this opportunity to start listing what UX/UI patterns you will need.
  3. Review your wireframes with specific user scenarios and personas in mind. Can users accomplish their task with the wireframe you are sketching out?
  4. Use the wireframes to get the team’s feedback on feasibility and structure.

Considerations for use in government

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