What discovery is for
Projects often arrive with an idea that’s close but not quite right. Discovery closes the gap while changing course is still cheap.
Discovery answers five questions:
- Who is this for, really? Who’ll use it, what they already know and what they’re trying to get done.
- What’s the actual problem? Requests often describe a solution; we look for the need behind it.
- What exists already? Systems, content, data, workarounds and competitors, and what’s worth keeping.
- What are the constraints? Budget, time, technology, regulation, accessibility, and the capacity of the team who’ll run it.
- What does success look like? Measurable, or at least recognizable, and agreed before building starts.
Why it matters more now
Faster building can make discovery look optional: why not build it and see? Because AI tools build exactly what they’re pointed at. Point them the wrong way and you get a polished version of the wrong thing, quickly.
Testing won’t catch it either: it picks the better option without judging whether any is good. Good options come from understanding the problem.
AI has changed the shape of discovery: prototypes are now cheap, so we build rough working versions in the first weeks and learn from how people use them.
Methods we use
Methods suit the question. Common ones:
- Stakeholder conversations. Goals, history and politics inside the organization.
- User interviews and observation. With the people who’ll use it, ideally in their own context.
- AI-guided interviews. Our AI discovery interviewer, which we built and use with clients, lets more people take part.
- Content and system audits. Pages, data, tools and integrations, and how they’re really used.
- Analytics review. What people actually do on current sites and products (often not what anyone assumed).
- Competitive and comparative review. How others, in your sector and outside it, solve similar problems.
- Testing packaging and messaging. Which ways of presenting information people respond to.
- Workshops. To align a team, map a process or make a decision together.
- Rapid prototypes. Rough working versions, tested with real people before anyone commits.
We trained in classical user experience and keep its research methods, minus the long phases, exhaustive documentation and sign-offs built to prevent expensive rework. Cheap change made that machinery mostly unnecessary.
What discovery produces
Depending on the project, discovery ends in:
- A product definition: what we’re building, for whom, and what we’re not.
- A working prototype of the core idea.
- An information architecture and content plan.
- A prioritized list of opportunities, with a recommendation for where to start.
- For Applied AI work, an audit of how the organization works, often with one or two working tools that show the value.
Findings are written plainly, with their evidence, so decisions can be revisited and explained later.
Taking the idea seriously
Clients often bring us the nucleus of an idea, which is a good time to come. We take it seriously, sometimes more than the person who brought it, and use discovery to find its best form, often bigger and better than first described.
We’ll also ask questions that can change the brief. Uncomfortable, sometimes, but cheaper than learning it after launch.
How much discovery you need
Discovery is scaled to the question: a few conversations and a prototype for a focused product idea, a fuller audit and more research for a large institution with many audiences. We recommend the smallest amount that gives us confidence.
