Discovery or validation: which do you choose when?

We prefer to start the design process with knowledge. So we do research up front: we talk to the people who will use the product, look at how they handle it today and where it pinches, and only then design. Sometimes we do the opposite and work from assumptions, making a design as quickly as we can and then validating it with users. Either way the user is at the center; the difference is the moment they come to the table.

When do you choose discovery, and when validation?

Discovery: when you don't know the problem yet

Then you talk to people. Five to eight conversations per audience, each forty-five minutes to an hour, recorded. You rarely need more. Somewhere around the fifth conversation you hear a story for the second time, and that is the signal that you have the patterns.

The question we ask is never "what would you do". People are poor predictors of their own behavior, and they like to give a friendly answer. We ask what they did last time. How they looked up a client, where the list lived, who they called when it went wrong. The gap between what someone says they do and what they actually did last week is usually the finding.

For a product used by healthcare practices we talked to six practices earlier this year. Everyone called the client file "the truth", and at the same time everyone kept a list of their own, on paper or in a separate checklist, of what still had to happen per client. That list was not in the system. Nobody had asked for it, because nobody saw it as missing; it was just how you worked. That workaround is exactly what you are looking for. The problem hurts enough to build something yourself, and the workaround shows you what the solution should look like.

That is what discovery gives you: the problem nobody had written down, and a team that heard it themselves and argues less about it afterwards. It is the cheapest way to avoid building the wrong thing for six months.

What it costs: time before there is anything to look at. Recruiting, scheduling and working it up is easily two to three weeks, and what you end up with are stories and patterns, not numbers. That is harder to sell to a board that wants a figure. And it never stops by itself. There is always one more audience you could talk to, and at some point asking more questions becomes a way to put off making something.

Validation: when you have something to test

Then you put it in front of people. A clickable prototype, or the product as it is today. Five people per audience, one at a time, with tasks instead of a tour. "Call in sick for tomorrow", not "what do you think of this screen". We say as little as possible and write down where someone hesitates, clicks back or reads something out loud because they do not get it.

Validation gives you hard evidence. Within a day you see where it breaks, you have it on video and nobody needs to argue any more about whether the label is unclear: three out of five read it wrong. That convinces a team faster than any report, and the fix is usually done the same afternoon.

What it costs: it only tests what you made. A test cannot tell you that you are solving the wrong problem. Five people gliding through a flow nobody needs feels like success and is not. You also need something to show first, and the people you test with have to resemble your actual users, or you get confident answers from the wrong panel.

So which do you choose

Ask yourself one question: can you write down, right now, in a single sentence, which problem the product solves and how people handle that today without it? If you cannot, you start with discovery. Five to eight conversations, per audience, about what they did last time. If you can, you know enough to make something, and you validate that with five people and real tasks.

The order matters. Start testing without knowing the problem and you get a screen that works smoothly for something nobody needs. Keep interviewing when the problem has long been clear and you postpone the moment you can be proved wrong. Neither has to take much time. If you are unsure which of the two you need, your problem is not clear enough yet, and you start with discovery.