User Centered Design Process - DOI-ONRR/nrrd GitHub Wiki

Process Diagram

This is the high level process to ensure we're designing with our users. See sections below for details about each step. Following best practices and to be compliant with the 21st IDEA act,  we base our website design for both of our websites on users. The user-centered design process is ongoing, it never ends. It starts by understanding problems based on previous user research, data requests or analytics. We then shape solutions by putting ourselves in the shoes of the users. Then we build and validate products using agile processes. We repeat and iterate as we learn more about users. More details of each step that are conveyed in the diagram are in text form below.

Understand Problems

Clearly identify problems to ensure we're solving for real user needs.

Identify problems

Sources of problems

  • Previous user research
  • Calls/emails to Data Optimization, Retrieval, and Coordination (DORC) or Open Data, Design, and Development (ODDD)
  • Freedom of Information Act (FOIA) requests
  • Analytics
  • Internal contacts who interact with customers
  • Outreach efforts to discover new users and their needs
  • Best practices (accessibility, heuristic reviews, technical etc.)
  • Regulatory requirements
  • Internal stakeholder requests

Levels of problems to solve

  • Bug
  • Easy, obvious fix - Features we’ve heard a lot about from users and there is a quick way to provide some relief. We should monitor the quick fix to probe if a major change is needed.
  • Medium level problem to an existing piece of functionality without a clear fix
  • New Feature

Priority of problems to solve

  • Balance against product framing document to prioritize
  • Technical difficulty
  • Resource constraints

Define & scope the problem to solve

Start with a raw idea

  • Talk about team’s hunches
  • State assumptions and ideas we have going in.

Understand the current state process and problems

  • How well do we understand the current state process?
  • How well do we understand the problem?
  • Do we know for sure it is a problem?
  • How obvious is the solution?
  • Think through the user's current state process.
  • Map the user's journey.
  • Formulate hypotheses, so we know what type of user research we need to conduct.

Conduct exploratory user research

Example methods:

  • Interviews
  • Analogous feature review (Could be competitors or could be best in class sites using the type of feature we’re considering designing for)
  • Formative usability testing (testing current state)
  • Testing competitor’s site with users
  • Card sorting
  • Create journey maps or personas out of the research findings

Narrow the problem

  • Group needs by user type
  • Prioritize groups

Determine the appetite

  • Decide how much effort we’re willing to put into a solution
  • Decide what to go after

Shape Solutions

Explore solutions to the problem that was identified in the previous stage.

Generate & test solutions

Sketch solutions

Coming up with ideas to solve the identified problem(s). We do most sketching offline to allow team members time to think and use whatever means they’re comfortable with to present their ideas.

Review sketches

Showing ideas that we come up with using whatever makes sense to communicate.

  • Hand drawn sketches
  • Storyboards
  • Using competitor sites
  • Static mockups (even ones in documents or spreadsheets)
  • Clickable prototypes

Narrow down the options

Decide on which ideas we like and if iterating is necessary.

Poke holes in the selected options

Team members looks at the options and analyze what does and doesn’t work and open questions.

Review hole-poking findings

Discuss things uncovered in the hole poking analysis.

Choose the options with which to move forward

Based on how well the problem is solved and whether it fits into the appetite.

Iterate sketches

Conditions that let us know we need to iterate:

  • Finding out something that’s missing from the design
  • Finding out that pieces of different designs work but we haven’t tested them together and there is more than one way we could fit them together.
  • If we find out that we’re not solving the problem at all or creating new problems with the mockups shown in interviews

Test with users

  • Present findings and recommendations to the project team
  • Discuss findings to gain consensus on next steps
  • Decide whether to iterate (and what) or to start building (and what)

Select Final Solution

Balance:

  • User needs
  • Technical constraints
  • Data constraints
  • Business priorities
  • Timeline
  • Other constraints

Build & Validate Products

Build the solution and make sure it works for users.

Scope for build

  • Break down the work into an initial list of scopes
  • Create GitHub issues for each broken down piece of work
  • Determine scope order & prioritize
  • Factor scopes and tasks as we go
  • Decide what will be good enough to be considered done

Build solution

Flesh out design details and build using agile

  • We factor tasks in every phase into our agile backlog, sprints, and epics.
  • Detailed design to fill in what’s missing from concept. Go through all the details of what happens when you click on each link and making sure it works with all the nuances of the data.
  • Build concurrently with detailed design.
  • Review design and built feature to make sure essence of design is correctly captured.

Iterate as necessary

  • Modify design as needed to meet constraints discovered during build process.
  • Ensure the build works at all viewport sizes and modify the design, as needed.

Validate built product

Usability testing

  • Test the built product with users
  • Synthesize and analyze the findings

Iterate design/build as needed or feed into future problem identification

  • Determine whether findings necessitate a change to the current product or if they are new problems we need to solve later.
  • Determine plan for making changes.