What is human-centered design and why is it important in modular contracting?
Human centered design is an approach to engage the end user in software development to yield actionable, prioritized, and assumption-challenging results. By directly engaging users throughout, HCD builds products that work better for users, require less rework, and prompt fewer support calls. We believe that theses approaches need to be incorporated at every step of the agile process. From conducting design research before and at the beginning of an acquisition, and usability testing for every sprint and user story developed.
Four tenets of human-centered design
- Put people before technology.
- Conduct design research.
- Focus on common user needs.
- Only accept proof in use.
Put people before technology.
This does not mean that people design the system. In human-centered design we figure out the best way to meet people’s needs and then figure out how to make it work within our constraints. If we start with user needs, we can see what needs we can’t meet within our current limitations and work on expanding them. This often maximizes meeting user’s needs. Moreover, it helps us prioritize what needs should be met and which needs can be adapted given our constraints.
Conduct design research.
We find out people’s needs by observing and speaking directly with them with design research methods — not via surrogates or our own assumptions.
In conducting design research, participants are users, people who touch the software. This helps us better understand the diversity of users experience that we cannot capture from experts.
We interact with many participants in one-on-one sessions, not large groups, so that we can observe them as they would use the software and minimize pressure they might feel in a group. It also helps prevent group think that might be different from when we talk to a user independently.
We use standardized questions and targets of observation so that we identify common patterns across participants and observe a similar workflow for multiple users, rather than just a piece of that workflow. With a standardize targets of observation, we try to talk about all parts of process with everyone.
We observe and ask about behaviors, instead of their opinions, because opinions — without an understanding of what people actually do — are rarely actionable.
We leverage a number of different methods that are ok within government such as:
- Stakeholder and user interviews
- Card sorting
- Multivariate testing
- Usability testing
- Visual preference testing
- Contextual inquiry
- Dot voting
- KJ method
For more on how to use these methods check out methods.18f.gov.
One tool that is especially helpful prior to conducting an acquisition is contextual inquiry, that occurs where a user will likely be when they use your tool.
- Go to the places users work.
- Ask them what they do.
- Observe and ask follow up questions.
- Repeat with different users.
Focus on common user needs.
We build products that meet the needs shared by the most people and meet address business goals. If we chase idiosyncratic practices we will build an overly-complicated system, that could actually make it harder for most users.
Only accept proof in use.
We’re only done when we see — via design research — evidence users can accomplish their goals. Usually, what we hear, what we make, and what’s needed aren’t aligned the first time. So we often conduct usability testing to obtain feedback about how users attempt to accomplish those goals in a product.
We are ok that we don’t get it right the first time, because we often learn a lot more by showing users a rough draft, than just describing to them the idea of what we are thinking.
Conducting usability testing
- Give a user a functioning product.
- Ask them to complete a task.
- Observe and be quiet.
- Repeat with different users.
For more on how to run a usability test, check out the method card on it