-
Notifications
You must be signed in to change notification settings - Fork 6
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 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
- 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
- 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.
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.
Team members looks at the options and analyze what does and doesn’t work and open questions.
Discuss things uncovered in the hole poking analysis.
Based on how well the problem is solved and whether it fits into the appetite.
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
- 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
- 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.
- 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.
- Problem statement
- Product vision
- User scenarios
- What we're not trying to do
- Product risks
- Prioritization scale
- Technical overview
- Contributing to code
- Creating a new branch
- How to prepare and review PRs
- Releasing changes
- Database change management
- Tech Solutions
- Data overview
- How to upload monthly data
- How to upload OGOR-B Data
- Troubleshooting for specific datasets
- Goals and metrics
- Analytics
- DAP-GA4 templates & instructions
- DAP-UA templates & instructions
- User research plans & findings
- Joining the team
- Onboarding checklist
- Working as a distributed team
- Planning and organizing our work
- Sample retro doc
- Human centered design process
- User research study process
- Design Standards
- Usability testing process
- User research participant guide
- User research agreement
- Observing user research
- Design and research in the federal government
- Shaping process
- Research wiki
- Data catalog
- Problem statement (2016)
- Hypotheses (2016)
- Outcomes workshop (2017)
- Transition goals (2018)
- Product management training (2018)
- Information architecture
- NRRD-flavored Markdown (Jekyll site)
For information about our other website see our ONRR.gov wiki.