By Mehdi HassanMany website projects that go over budget don't fail in design or development. They fail in week one, when nobody wrote down who the site is for, what it has to make people do, or which pages are actually in scope. The discovery phase is where you settle those questions while changing your mind is still free.
What happens in the website discovery phase?
In the website discovery phase, the team turns a vague request ("we need a new site") into a written agreement on goals, audience, message, scope and success measures. It sits at the start of the website design process, before sitemaps, wireframes or visual design. Nothing gets designed until the brief is signed off.
In practice, discovery is a mix of a kickoff workshop, a review of what exists today and a few follow-up questions. The team reads your current site and analytics, listens to how you pitch the product on calls, looks at the sites your buyers compare you with, and lists every page and integration the new site needs. The work is mostly listening and writing things down precisely.
What discovery is not
Discovery isn't a branding exercise or a mood board session. Visual direction comes later, once the message is clear. It also isn't a sales formality: if the answers change the scope, the scope changes before anyone starts drawing.
Why does a discovery phase save money?
A discovery phase saves money because a sentence changed in a brief costs minutes, while the same change after design or development costs days. The later a wrong assumption is found, the more work sits on top of it. A misunderstood audience found in week one means editing a paragraph. Found at launch, it means rewriting copy, redesigning sections and rebuilding pages.
Discovery also protects the budget from scope creep. When the page list, integrations and content owners are written down, every new request can be compared with the agreement. That makes the conversation about change orders and scope creep calm and factual instead of personal. Without a written scope, every new idea feels like it should be free, and the project slowly grows past what anyone priced.
What questions should a website discovery workshop answer?
A good website discovery workshop answers questions in eight areas: goals, audience, message, proof, competition, scope, content and constraints. Below is the question set we use. It works as a self-serve template too: if you can answer every question in a sentence or two, you're ready to brief any agency.
Area | Questions to answer |
|---|---|
Goals | What must the site make people do? What happens if we don't launch? What number tells us it worked? |
Audience | Who is the main buyer? Who else signs off? What are they trying to get done when they land? |
Message | How do you explain the product on a sales call? What do buyers misunderstand? What's the one claim you can prove? |
Proof | Which logos, case studies, reviews or numbers can we use? What's approved for public use? |
Competition | Which sites do buyers compare you with? What do they say better than you? Where are they vague? |
Scope | Which pages are needed at launch? Which can wait? Which integrations (CRM, analytics, booking) are required? |
Content | Who writes the copy? Who supplies images? Who approves each page, and how fast? |
Constraints | What's the deadline and why? What platform or CMS must the team keep? Who edits the site after launch? |
Who should be involved in project discovery for a website?
Website project discovery needs the person who owns the budget, the person who sells the product and the person who will maintain the site afterwards. At a startup, that's often the founder, a head of growth or sales, and whoever updates the site day to day. More people than that slows the workshop down without adding answers.
The founder matters most in the first session, because the positioning lives in their head. Sales and customer success bring the objections buyers raise. The future site editor brings the practical constraints: how often pages change, who publishes blog posts and what they find painful in the current CMS. Engineering only needs to join if the site touches the product, for example a shared login, a docs site or pricing pulled from the app.
What does a web design discovery deliverable look like?
The web design discovery deliverable should be a one-page brief that anyone on the team can read in five minutes and agree with. Long strategy decks get skimmed once and forgotten. A single page forces decisions, and it becomes the document every later design review is checked against.
- Goal: one primary action (book a demo, start a trial, join a waitlist) and the metric that shows it's working.
- Audience: the main buyer in one sentence, plus who else influences the decision.
- Core message: the headline-level claim and the three supporting points, in plain words.
- Proof: the approved logos, case studies and numbers the site can use.
- Sitemap: the launch page list, with anything deferred to a later phase marked as such.
- Content owners: who writes, who supplies assets and who approves each page.
- Constraints: deadline, platform, integrations, and who edits the site after launch.
- Out of scope: what this project will not do, written down so nobody assumes otherwise.
For example: a filled-in brief for a hypothetical seed-stage startup
For example, suppose a seed-stage company sells scheduling software to dental clinics. Goal: booked demos from clinic owners, measured as demo requests per week. Audience: practice owners with two or more locations; office managers influence the choice. Core message: fewer no-shows without hiring front-desk staff, supported by automated reminders, two-way texting and a simple setup.
Proof: three pilot clinics have agreed to be named, but no numbers are approved yet. Sitemap: home, product, pricing, about, contact, plus a blog added later. Content owners: the studio writes the copy, the founder approves within two working days. Constraints: launch before a trade show, the team keeps its current CRM, and the office manager must be able to edit pricing. Out of scope: patient-facing pages and translations.
How long should a website discovery phase take?
For a startup marketing site, discovery usually takes a few working days, not weeks. One kickoff session of a couple of hours, some async questions and a review of the brief is typically enough. Enterprise projects with many stakeholders take longer because approvals take longer, not because the questions are harder.
If discovery is dragging on, it's usually a sign that a decision is being avoided: who the site is for, what the product's main claim is, or whether a page belongs in scope. Name the open decision, give it an owner and a date, and move on. A brief with one clearly marked open question is better than a perfect brief three weeks late.
What are the common mistakes in a website discovery phase?
The most common discovery mistake is skipping it because the team feels they already know the answers. They usually know them individually, but not the same answers. Writing the brief together exposes the disagreements while they're cheap to resolve.
- Starting with visuals. Picking reference sites before agreeing on the message leads to a pretty site that says the wrong thing.
- No named approver. If nobody owns the final yes, feedback rounds multiply. Our guide to giving website design feedback covers how to keep them short.
- Ignoring existing content. A redesign should begin with a website content audit so good pages and their rankings aren't lost.
- Leaving copy ownership vague. Decide early who writes the website copy, because late content is a common reason launches slip.
- No success metric. Without a number agreed upfront, nobody can tell whether the new site worked.
Once the brief is signed off, keep it visible. Paste it at the top of every design review and check each decision against it. It's also the starting point for your website launch checklist, since the goal and integrations listed in discovery are exactly what you test before going live.
