Discovery sometimes gets treated as the meeting before the project begins.
We see it differently.
The project has already begun.
Discovery is where assumptions become questions and questions become direction.
Start with the business
Before discussing pages, understand the organization.
- What changed?
- Why is this project happening now?
- Where is the company going?
- What does the website need to make possible?
These questions give the project context.
Understand the audience
- Who needs to use the experience?
- What do they already know?
- What are they trying to understand?
- What questions are they bringing?
- What needs to happen before they feel confident taking the next step?
Good information architecture depends on those answers.
Surface constraints early
Every project has constraints.
- Timeline.
- Budget.
- Technology.
- Content.
- Internal resources.
- Approvals.
- Integrations.
Pretending those constraints don’t exist doesn’t create more creative freedom.
Understanding them creates a more realistic design space.
Turn conversations into decisions
Discovery shouldn’t end with a transcript of what everyone said.
It should produce direction.
- Priorities.
- Audience understanding.
- Requirements.
- Information architecture.
- Content needs.
- Technical considerations.
- Measures of success.
The objective is to reduce ambiguity before expensive execution begins.
Discovery prevents the wrong work
Without it, teams can move quickly in the wrong direction.
A beautifully designed solution to the wrong problem is still the wrong solution.
That’s why Understand is the first step in our approach.
Discovery isn’t time spent before the work. Discovery is the work that makes the rest of the work make sense
