How long does website discovery take?

It depends on the size of the site, the number of audiences and how quickly decisions get made. For a typical established business site it is a matter of weeks, not months. The bottleneck is almost always internal availability for interviews and approvals, so book those early.

What is the difference between discovery and a website audit?

An audit looks at the current site and reports what is working and what is not. Discovery uses that audit as one input and goes further: it decides what the new site must do, for whom, with what content structure and requirements. An audit tells you where you are; discovery decides where you are going.

Can we skip discovery if we already know what we want?

You can shorten it, but writing down what you already know is still discovery, and it is usually where hidden disagreements surface. If leadership truly agrees on audiences, content types, conversion paths and integrations, documenting it is quick. If they do not, you want to find out before design rather than during it.

Should discovery be a separate contract from the website build?

It often makes sense. A separate discovery engagement produces a brief you own, which you can use to get comparable quotes for the build. It also gives you a low-risk way to see how a vendor thinks before committing to the larger project.

Website Discovery: What to Decide Before Design Begins

What discovery is for

Every website project makes the same set of decisions eventually. The only question is when. Make them at the start and they cost a meeting. Make them during design and they cost a round of revisions. Make them during development and they cost a change order. Make them after launch and they cost a second project.

Discovery is simply the phase where you choose to make them early. It is not research for its own sake, and it is not a workshop that ends with sticky notes on a wall. It ends with decisions written down and approved by the person who has the authority to approve them.

If you are planning a full redesign, the redesign planning guide covers the whole project from objectives to governance. This article zooms in on one phase of it: the four areas discovery has to settle before anyone opens a design tool, and what a finished discovery should hand to the designer.

Decision one: audience and the tasks they came to do

“Our audience is everyone” is how websites end up with seven equally loud buttons on the home page. Discovery forces a ranking.

Start by listing the groups who actually visit, then the job each group is trying to get done. For most established organizations the list looks something like this:

New prospects comparing you to two or three alternatives, usually on a phone, often after a referral.
Existing clients looking for a login, a document, a phone number or a billing contact.
Job candidates checking whether you are a place they would want to work.
Partners, media and funders verifying that you are who you say you are.

Then rank them by commercial importance, not by volume. Existing clients may make up most of the visits, but the site probably exists to win new ones. Both matter. Only one gets the prime real estate.

The evidence for this ranking comes from three places: your analytics (top landing pages and the pages viewed before an inquiry), the people who answer the phone (they know which questions the website fails to answer), and a handful of conversations with recent clients about how they chose you. That last one is the most skipped and the most useful. Five short calls will tell you more about what buyers need to see than any amount of internal debate.

The output is a short list of audiences, each with its top three tasks and the questions it needs answered before acting. That list is what the rest of discovery is measured against. It is also the core idea behind treating your website as a decision system rather than a design project.

Decision two: the content model

A sitemap tells you what pages exist. A content model tells you what kinds of content exist and how they relate. The difference sounds academic until you try to add your fortieth case study to a site that was designed around six.

A content model defines your content types (service, case study, team member, location, article, event, job posting) and the fields each one has. A case study might have a client, a sector, a service, a challenge, an outcome and a related set of services. Once that is defined, the site can do useful things automatically: show relevant case studies on each service page, filter by sector, list every location with consistent hours and contact details.

Discovery should answer, for each content type:

What fields does it need? Be specific. “Text and an image” is not a content model.
How does it connect to other types? Services to case studies, locations to staff, articles to topics.
Who creates and maintains it? If nobody owns the team pages, they will be wrong within a year.
Does it exist in more than one language? In New Brunswick this is often a legal question as well as a marketing one, and the bilingual website planning guide covers how language scope shapes the model.

An illustrative example: a regional engineering firm with four offices assumes it needs a page per office. The content model shows that what actually differs by office is a short list of fields (address, hours, team, a local project or two). One location template with those fields replaces four hand-built pages that would have drifted apart within months.

Decision three: conversion paths

A conversion path is the route from arriving on the site to doing something useful for the business. Most sites have one: a Contact Us button on every page. That works for exactly one kind of visitor, the one who has already decided.

Discovery should define a small number of paths matched to readiness:

Ready now: book a consultation, request a quote, call. Make this short and obvious.
Still comparing: read a case study, download a guide, see pricing approach or process. Give them something that moves them forward without demanding a meeting.
Not a buyer today: subscribe, follow, apply for a job. Valuable, but not the same thing as a lead.

For each path, decide three things: what action counts as the conversion, where the submission goes (which inbox, which CRM pipeline, which person), and how fast someone responds. The third one is not a website decision, which is exactly why it gets missed. A beautifully designed quote form that lands in a shared inbox nobody checks on Fridays is a leak, not a conversion path.

These decisions also become the tracking plan. If you have defined the paths, you have defined the events analytics needs to record, and the conversion tracking plan can be written from the same document.

Decision four: technical requirements

This is the part people assume discovery is entirely about, and it is usually the shortest section if the first three are done properly. The technology follows from the audiences, the content model and the conversion paths. Settle these questions in writing:

Integrations. CRM, email platform, booking system, payment, job board, client portal, chat. Each one is scope. The detail of how data should flow between them is its own topic, covered in website integrations: CRM, forms and analytics.
Editing. Who will update the site, how often, with what skills? A platform that suits a developer is not the same as one that suits a marketing coordinator publishing on a Thursday afternoon.
Languages. One, two, or one with a few translated pages? Each answer implies a different build.
Accessibility. Which standard you are building to and how it will be verified.
Existing assets. Domain, hosting, analytics properties, ad accounts, the current site’s search visibility. Who owns each, and in whose name?
Constraints. Security or privacy requirements, data residency, an IT department’s approval process, a busy season that rules out certain launch dates.

Notice that the platform choice is not on the list as a starting point. It is an output. If someone arrives at discovery having already decided the site will be built on a particular CMS, ask what problem that choice solves. Sometimes there is a good answer (the team already knows it, an integration requires it). Often the answer is habit.

What a finished discovery hands to design

Discovery is done when the following exist and have been approved by one accountable person, not a committee:

A written brief of a few pages: objectives with measures, ranked audiences and their tasks, constraints.
A sitemap showing every planned page and how it is reached.
The content model: content types, fields, relationships and owners.
Conversion paths with destinations and response owners.
Technical requirements including integrations, languages and accessibility standard.
Wireframes for the key templates (home, a service page, a case study, a location, the main form), showing what goes where and in what order, without visual design.

Wireframes are where most disagreements surface, and that is their purpose. It is far cheaper to argue about whether testimonials belong above or below the process section in a grey box diagram than in a finished design.

This document has a second use. If you are going to market for a vendor, a discovery brief is the best foundation for an RFP, because every bidder prices the same scope. The guide to writing a website RFP that produces better proposals covers how to turn it into one.

Red flags, and the questions to ask

Whether you run discovery internally or a vendor runs it, watch for these:

Design concepts appear in the first two weeks. Someone is selling you a look before understanding the job.
Nobody talks to your clients or your front-line staff. The brief will reflect what leadership believes, which is not always what buyers experience.
The content model is missing. You will find out when you try to add something the templates did not anticipate.
Integrations are listed but not tested. “Connects to your CRM” means nothing until someone has confirmed which fields map where.
There is no sign-off. If the brief is never formally approved, it will be quietly reopened in every design review.

Discovery on our website projects includes a live audit of the current site and conversations with the people who use it, because the gap between what an organization thinks its site does and what it actually does is usually where the most useful decisions come from. However you run it, the test is simple: could a designer who has never met you start work from what discovery produced? If the answer is no, discovery is not finished.