What Good Discovery Looks Like

Most project problems have a common origin. Not in development, not in design, and not in the client relationship — but in week one, before any of those things began. A brief that was too vague. Stakeholders who disagreed about goals but never surfaced the disagreement. Assumptions about users that turned out to be wrong. Requirements that emerged mid-project because no one asked the right questions at the start.

Discovery is the practice of asking those questions before expensive work begins. It is not a phase that exists to make agencies look methodical or to generate billable hours before the "real" work starts. It is the most risk-reducing investment a project can make — and it is the most commonly compressed, abbreviated, or skipped phase in the entire engagement.

The projects that go smoothly, finish on time, and land where the client hoped are almost always the projects where discovery was taken seriously. This is not a coincidence.

Why Most Projects Skip Discovery

Three pressures reliably compress or eliminate discovery: time, budget, and the desire to see things.

Time pressure is real. Organizations often come to agencies with launch deadlines already established — a trade show, a product launch, a fiscal year boundary. Discovery feels like it delays the "start" of the real work, so it gets compressed into a kickoff call and a single requirements document, or eliminated entirely.

Budget pressure compounds this. Discovery is a line item that produces documents, not screens. Clients who are allocating limited budgets often feel that money spent on discovery is money not spent on design or development. The logic is understandable. It is also backwards. A week of discovery that prevents three weeks of rework is a dramatically positive return on investment.

And then there's the desire to see things. Clients want to see designs. They want visual momentum. Showing up to a meeting with a discovery brief feels less exciting than showing up with initial concepts. Agencies that skip discovery and go straight to mockups win more pitches and lose more projects.

Skipping discovery doesn't save time — it borrows it from later in the project, with interest.

The pressure is understandable on all sides. But the outcome is consistent: projects that skip discovery are faster to start and slower to finish, with more rework, more scope disagreements, and more difficult conversations along the way.

What Discovery Actually Means

Discovery is not a checklist. It is an investigation. The goal is to understand the actual problem well enough that the solution can be designed with confidence — not guessed at.

A genuine discovery phase answers a specific set of questions:

• Why does this project need to happen? Not the surface-level answer ("our site is outdated") but the business reason beneath it. Is the real problem that the site isn't converting qualified traffic? That the brand has repositioned and the site no longer reflects it? That the content team can't publish without engineering? Each answer implies a different solution.
• What does success look like, and how will we measure it? A project without measurable success criteria is a project without accountability. Success metrics don't have to be complex — they have to be specific. "More leads" is not a success criterion. "25% increase in contact form submissions from organic traffic within 90 days of launch" is one.
• Who are we designing for, and what do they actually need? Not who the organization assumes the audience to be, but who the audience demonstrably is, based on analytics, research, and direct conversation.
• What constraints exist? Technical constraints (existing systems, integration requirements), organizational constraints (who approves content, what workflows must be supported), and timeline and budget constraints. Constraints discovered in week two are manageable. Constraints discovered in week eight are crises.

Stakeholder Alignment

One of the most valuable and least discussed functions of discovery is surfacing stakeholder disagreement before it becomes a problem.

In most organizations, the people who commission a website project are not a monolith. There is often a sponsor with budget authority, a marketing lead with strong opinions about brand, an operations person worried about CMS usability, a sales leader who wants the site to generate more leads, and a founder who has a specific vision they haven't fully articulated. These people may not disagree explicitly — but they almost certainly have different priorities, and those priorities will surface eventually. The question is whether they surface in week two or week ten.

Week two is far cheaper. A structured stakeholder interview process — individual conversations before any group sessions — reliably uncovers the real landscape of opinions, priorities, and concerns. The discovery team can then design a working session that surfaces tensions directly, facilitates resolution, and produces a documented brief that all stakeholders can sign off on.

A brief that has genuine stakeholder sign-off is one of the most valuable artifacts a project can have. It doesn't prevent all scope disagreements, but it creates a shared reference point when they arise. "We agreed in the brief that the primary conversion goal was contact form submissions from enterprise buyers" is a sentence that resolves a lot of late-project debates.

User Research Essentials

User research is the part of discovery that most organizations want to skip because it feels like an academic exercise or a luxury reserved for large budgets. Neither is true. A minimal but well-executed research effort produces insights that consistently change project direction in ways that matter.

Five to eight user interviews is a practical minimum. Research consistently shows that patterns emerge rapidly in qualitative research — by the fifth or sixth interview, you are largely confirming patterns rather than discovering new ones. Eight interviews is achievable in a week with focused effort, and the insights are almost always more surprising than the client expected.

What to look for in user interviews:

• Mental models: How do users think about the problem your product or service solves? Their vocabulary and framing may be different from yours, and if your site uses your internal language instead of theirs, they won't find what they're looking for.
• Decision criteria: What do users evaluate when making a decision in your category? What questions do they need answered before they'll contact you, make a purchase, or take the desired action?
• Friction points with the current site: Where do existing users get confused, frustrated, or lost? This is the fastest path to prioritizing improvement areas.
• Job to be done: What is the user actually trying to accomplish? Not what they're doing on your site, but the underlying goal that brought them there. The answer shapes the content hierarchy and navigation structure more than any other single input.

Complementing interviews with a heuristic evaluation of the existing site — a structured review against established usability principles — provides a baseline for design decisions and prevents the redesign from repeating current mistakes with a fresher coat of paint.

Analytics review rounds out the research picture. Analytics tell you what users actually do (as opposed to what they say they do in interviews). Pages with high exit rates, poor scroll depth, or consistently low conversion tell you where the current experience is failing. Combining behavioral data with qualitative context from interviews produces a rich, accurate portrait of user needs.

Audit and Gap Analysis

Discovery includes an audit of the existing assets — not just the design, but everything that shapes the project scope and constraints.

Content audit: An inventory of all existing content — pages, posts, assets, documents. Categorized by quality, relevance, and destination in the new site architecture. A content audit frequently reveals that a site has far more pages than anyone realized, that significant portions of the content are outdated or redundant, and that the content migration will require substantially more effort than initially assumed. Discovering this in discovery rather than mid-project is worth a great deal.

Technical audit: An assessment of the current platform, hosting environment, integrations, and performance. Identifies what can be preserved, what must be replaced, and what technical constraints will shape the new architecture. This is the input that determines whether a project needs a redesign, a rebuild, or both.

Competitive analysis: A structured review of how direct competitors and category leaders approach the same problems. Not to copy, but to understand the baseline expectations users bring from elsewhere in the market — and to identify differentiation opportunities that the design should exploit.

SEO foundation audit: An assessment of existing organic search equity — rankings, backlinks, indexed pages, technical SEO health. A site that has accumulated meaningful organic traffic needs a migration strategy that preserves that equity. A site that has none needs a strategy that builds it. Both require knowing the starting point before the project begins.

What You Get at the End

A properly executed discovery phase produces a set of artifacts that guide everything downstream. The format varies by project and agency, but the content should consistently include:

• A project brief: The single source of truth for the project. Documents goals, success metrics, audience definitions, key messages, constraints, and scope. Signed off by all primary stakeholders.
• A problem statement: A concise articulation of the core problem being solved, grounded in the research. This is the test against which every design decision will be evaluated.
• User research synthesis: Key insights from interviews, organized into themes. Includes representative quotes, identified patterns, and implications for design.
• A proposed information architecture: A site map that reflects the research findings — how users think about the content, what they need to find, and how the navigation should be structured to support their goals.
• Design principles: 3–5 principles that will guide design decisions. These are specific enough to be useful as decision-making tools ("Clarity over cleverness: every design choice should reduce cognitive load, not add to it") rather than generic aspirations.
• A prioritized requirements list: Features and content organized by must-have, should-have, and nice-to-have. The foundation for scope management throughout the project.
• A risk register: A list of identified risks with mitigation strategies. Content risks, integration risks, timeline risks, organizational risks. Most of these risks are predictable — the value of naming them in discovery is that it creates accountability for managing them.

These artifacts do not guarantee a successful project. Nothing does. But they dramatically improve the odds by ensuring that the project is solving the right problem, that everyone agrees on what success looks like, and that the team building the solution has the information they need to make good decisions.

Agencies that skip discovery aren't being more efficient. They're being faster — and speed without accuracy is just expensive iteration.