What a Discovery Phase Actually Covers
Article by Rostislav Georgiev
Discovery isn’t a week of workshops for the sake of it. It’s how we make sure the thing we design is the thing your business needs. Here’s what goes into it and what you get out.
Most projects that go wrong don’t fail in design or in code. They fail earlier, when everyone agrees on a goal that nobody has written down. Discovery is the part of a project where we slow down on purpose, so the rest of it can move fast.
What we look at
We start with the business: who pays, who uses the product, and where those two groups want different things. Then we look at what already exists: analytics, support tickets, sales calls, the screens your team apologises for. Short interviews with a handful of real users usually tell us more than a long survey.
What you get
At the end you have a short, readable brief: the problem in one paragraph, the people we’re designing for, the flows that matter most, and the risks we’d test first. Alongside it comes a rough map of the product and a realistic plan with priorities, not a wish list.
How long it takes
For most teams it’s one to three weeks, depending on how much is already known. It’s the cheapest phase of any project, and the one that saves the most money later, because changing a sentence in a brief costs far less than changing a shipped feature.
