A short guide to user research

We end up explaining this on discovery calls often enough that it deserved writing down. Everything we would tell a client about user research in the time it takes to drink a coffee.

The projects that go badly are rarely the ones with the hardest technical problems. The version that survives contact with a real deadline is the simple one.

Why this earns attention

Five conversations beat a hundred assumptions. None of that requires a large budget, only a decision and someone to own it. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

What good looks like

Watch what people do, not only what they say. In practice this is a scheduling problem more than a technical one. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

Where it usually goes wrong

Talk to the people who did not buy. There is a version of this that is over-engineered, and it is worth avoiding. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

What this looks like day to day

Strategy work is mostly deciding what not to do, and writing it down so it stays decided. Three things worth confirming about user research before you move on:

• Someone can say what the current setup is without going to look
• Five conversations beat a hundred assumptions — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Worth checking on your own setup before it becomes someone else's problem to fix.