Design & user research processes
Human-centered design relies on four basic principles and provides the high-level model for our work:
- Put people (users) at the center of what we do. Talk to users to build empathy and understand their wants and needs. Create solutions that best meet those needs. Never assume we know what’s best for the user.
- Solve the right problem. Take time to research and understand the problem before ideating solutions.
- Everything is a system. The platforms we manage are just one part of the user journey at eRulemaking - which is just one part of the user experience with the government - which is just one part of interconnected socio-political-economic systems.
- Make small and incremental improvements. While working in Agile, use rapid iterations of testing, prototyping, and implementation.
There are many models for the phases of human-centered design. eRulemaking uses a six-phase model:
- Define: Make sense of and learn about the problem. Investigate what related work has been done before. Determine if the initially identified problem is really a problem or if further research is needed to specify the problem.
- Research: Gain deep understanding of intended user's experience via user research. Analyze collected data and identify user needs to address with a design solution.
- Ideate: Explore many possible ideas that could evolve into solutions.
- Prototype: Develop some of the ideas into tangible designs or objects.
- Test: Evaluate finished designs with users and collect input for improvement. Based on the findings, return to any of the earlier phases as needed to revise designs and products.
- Implement: Once designs and products meet user wants and needs, implement the solution and push live. Implement the best possible (not perfect) product at that time, knowing improvements will continue to be made.
We put human-centered design into practice with an iterative, user-centered design process. This chart and the text below detail our process.
Clearly identify problems to ensure we're solving for real user needs.
- Previous user research
- Calls/email
- 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
- 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 strategy and roadmap to prioritize
- Technical difficulty
- Resource constraints
- Talk about team’s hunches
- State assumptions and ideas we have going in
- 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.
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
- Group needs by user type
- Prioritize groups
Decide how much effort we’re willing to put into a solution Decide what to go after
Explore solutions to the problem that was identified in the previous stage.
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.
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
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)
Balance:
- User needs
- Technical constraints
- Data constraints
- Business priorities
- Timeline
- Other constraints
Build the solution and make sure it works for users.
- 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
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.
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.