This repository has been archived by the owner on Nov 10, 2020. It is now read-only.
User Centered Design Process
This is the high level process to ensure we're designing with our users. See sections below for details about each step.
Clearly identify problems to ensure we're solving for real user needs.
- Previous user research
- Calls/emails to Data Retrieval or Data Display
- 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
- 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
- Balance against product framing document to prioritize
- Technical difficulty
- Resource constraints
- 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.
- State assumptions and ideas we have going in.
- Formulate hypotheses, so we know what type of user research we need to conduct.
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 competitors site with users
- Card sorting
- Create journey maps or personas out of the research findings
- Group needs by user type
- Prioritize groups
- Decide what to go after
Explore solutions to the problem that was identified in the previous stage.
Coming up with ideas to solve the identifies problem(s).
- Grouping exercises to identify themes and patterns in research
- Writing
- Sketching
- Thinking from different perspectives (6 thinking hats)
- Dot voting to pick best ideas
- 2x2 spectrums
Showing ideas that we come up with using whatever makes sense to communicate.
- Hand drawn sketches
- Storyboards
- Using competitor sites
- Static mockups
- Clickable prototypes
- Tree testing if testing information architectures
- Review notes with observers right after each session and identify key themes
- Consolidate notes across participants and identify trends
- Tie findings back to goals of the study
- Prioritize consolidated findings and come up with recommendations
- 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)
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
Balance:
- User needs
- Technical constraints
- Data constraints
- Business priotities
- Timeline
- Other constraints
Build the solution and make sure it works for users.
- 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.
- Concurrent build activities
- Reviewing design and built feature to make sure essence of design is correctly captured.
- 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.
- Test the built product with users
- Synthesize and analyze the findings
- 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.