Client Discovery Questions for a Clearer Website Project

A useful discovery conversation turns a request such as “we need a new website” into a problem, evidence and a decision. Ask for a recent example of the difficulty before discussing a theme, builder or hosting package.

The questions below are a suggested agency worksheet. They are not a promise that discovery will eliminate rework, and they are not a substitute for speaking with the people who will use the service.

Start with the event that triggered the project

Ask: “What happened that made this project important now?” Then ask the client to walk through the last time the problem occurred. Capture what someone tried to do, where the process stopped and what happened next.

For example, “our contact page looks old” may conceal unanswered enquiries, confusing service descriptions or a form that fails. These are different problems. Do not treat a redesign as the confirmed answer until you understand the underlying task. The GOV.UK discovery guidance similarly starts with understanding the problem, users and constraints before committing to a build.

Questions that produce useful project evidence

Separate stakeholder opinion from user evidence

A client may know their business well while still guessing how visitors use its website. Label statements as observed, reported or assumed in your notes. If someone says visitors cannot find a service, ask what evidence supports that conclusion and which visitors are affected.

Where appropriate, arrange interviews with actual users rather than asking the client to speak for every audience. The GOV.UK interview guide is a practical reference for planning and conducting those conversations. Obtain permission before recording and follow the project’s agreed handling of research notes. Do not copy personal customer details into a broadly shared discovery document.

Turn answers into a small decision record

Use five headings: problem, evidence, constraints, unresolved questions and next decision. Keep proposed features in a separate list until you can connect each one to a user task.

For a hypothetical appointment business, the record might say: customers need to request an appointment, staff report repeated incomplete requests, and the current scheduling system must remain. The next step could be to observe that request process and test clearer required information. It is too early to promise a replacement booking platform or a conversion increase.

Know when to pause the estimate

Pause a fixed implementation estimate when a critical integration is undocumented, the decision owner is unavailable or the supposed problem has no supporting example. Offer a bounded investigation with an explicit output instead of hiding that uncertainty inside a confident quote.

End the meeting by reading back the problem in plain language and asking the client to correct it. Assign each unresolved question to someone and agree when you will decide whether to proceed. Discovery has done useful work when it makes the next decision clearer, even if the right decision is a smaller change.