What good discovery looks like before design starts

Discovery is where uncertainty is brought into the open before expensive work starts. If it is done lightly, the cost shows up later in rework, vague review cycles, and design that keeps circling around unresolved questions.

---

What should exist by the end

By the end of discovery, you should have:

• a clear priority audience
• agreed page and route priorities
• defined scope boundaries
• known content gaps and owners
• visible decision points for design and build

If those are missing, design tends to become exploratory and costly.

---

What discovery should force you to decide

Good discovery is not a pile of documents. It is a forcing function.

You should be able to answer:

• what matters most at launch
• what can wait
• what message choices are already settled
• what uncertainty still needs resolving

If the output cannot answer those questions, it is not ready.

---

Warning signs that discovery is still too light

• outcomes are still described vaguely
• stakeholders disagree on audience priority
• content risk is being pushed later
• scope sounds large but still blurry
• design is being discussed before the basics are settled

A strong partner should challenge this early, not absorb it silently.

---

Why discovery protects budget

Discovery protects budget because it narrows the work to the pages and decisions that matter most first. That means fewer avoidable detours during design and a better chance of comparing real trade-offs early.

It is especially valuable when the offer is complex or the internal decision loop is not yet tight.

---

What you should be able to approve

At the end of discovery, approval should feel practical.

You are not approving "direction" in a vague sense. You are approving:

• what the site is trying to change
• who it is primarily for
• what will be tackled first
• how the next phase will be judged

That is what makes design and build move faster afterwards.

For preparation work before discovery, read what to prepare internally before briefing a web partner. For the ownership model around it, pair this with website project roles: who needs to decide what.