I was chatting today to a colleague about having access to users for interviews and user testing. I took the chance to clarify (I think) my thinking a bit and scribble it down.
Summary: to give a project the best chance of success (good work, happy users), we need frequent access to the users of the software. Without it, we run the risk of making incorrect assumptions and spending time and money building something that doesn’t solve their problems.
When we make software there are two things that we try and keep in mind: build the thing right and build the right thing.
By build the thing right we mean use development best practices (often following agile ways of doing things, using Test-Drive Development, writing clean code, doing code reviews).
By build the right thing we mean doing User Experience stuff, usually with a User-Centered Design flavour.
UCD process
A UCD process often follows steps like this:
Plan → Design → Build → Measure.
The Build phase is development.
The Measure phase is stats and user testing after launch, to keep the ship on an even keel.
The Design phase involves Information Architecture and a content plan, sketches, making Prototypes (and testing them), and Graphic Design (sometimes using Style Tiles). Doing the best work in this phase (and then building the right thing) isn’t possible without a proper Plan phase.
The Plan phase
This phase is about research and Product Discovery. We usually start with a Problem Frame Diagram: identifying User Needs, Business Needs, Core Skills and where they intersect. This helps us make sure that we know what their problems are before we start figuring out how to solve them.
In this phase we conduct research. We use existing user insights, user statistics, the team’s domain expertise, user interviews and shadowing, bug reports and customer service reports to give us information on what the users' problems are. Doing this research isn’t possible without frequent access to users.
After the research, we make Personas (to help us make better decisions) and Journey Maps (to give us a view of the whole process and the user’s context).
Why do we need frequent access to users?
- To see how they use the system.
- To see what parts of the system they avoid or don’t like.
- To make the system better for the users, we have to know what better means to them.
- To make the system simpler for the users, we need to know what they find complex, and what defaults we could set to smooth the process.
- To test prototypes we need to put it in front of them.
- To establish priorities for fixing things, and for content layout, we need to know what’s most important to them.
- To know if we’re solving the right problem(s), we need to find out what those problems are.
- To find any areas where small changes could make a big difference, we need to discuss the system with users.
- To identify our blind spots and biases.
- To reduce risk by testing our assumptions. Every decision we make is an assumption. We want those decisions to be as well-informed as possible. We do that by asking lots of questions.
- To save (potentially lots of) time later, redoing things that aren’t needed, don’t solve the right problem, or don’t solve the problem in the right way.
- To save time during development by having a clear direction and guidance for decisions about functionality and UI.
- To find an innovative solution, by fully understanding the problems facing the users.