The Web Design Questionnaire That Replaces the Kickoff Call

The kickoff call is where website requirements go to die. Everyone talks for an hour, the client says "I'll know it when I see it", you scribble a few notes, and you both walk away certain you agree. Then the design comes back and it turns out you were building two different sites the whole time.

A call is a bad instrument for gathering requirements. It happens once, in real time, with no second take. You ask the questions you remember, in whatever order they occur to you, and the client answers off the top of their head while half-thinking about their next meeting. The unglamorous questions (who owns the domain, who is writing the copy) get skipped because they kill the mood, and those are exactly the ones that sink the project later.

A written web design questionnaire fixes all of that. It asks every question in the same order every time, gives the client room to go and find a real answer, and leaves you with something you can read back instead of a memory of a friendly chat. Below is a complete one you can copy and send today: fourteen questions across the six sections that actually matter, plus a filled-in example so you can see what good answers look like.

Why a questionnaire beats the kickoff call

This is not an argument against ever talking to your clients. It is an argument against using a live conversation as your primary requirements-gathering tool, because a conversation has three properties that work against you:

1. 1It is improvised. You ask whichever questions come to mind, so coverage depends on your memory and the client's mood that day. A written form asks all fourteen, every time, in the same order, whether you are sharp or running on four hours of sleep.
2. 2It rewards fast answers, not good ones. Put on the spot, a client guesses. "What's your budget?" gets a number they regret; "who writes the copy?" gets an airy "oh, we'll sort that out". Given a form to fill in over coffee, the same client checks with their colleague and gives you a real answer.
3. 3It leaves no record. Three weeks later, nobody can prove what was agreed. A questionnaire is a document both sides can point back to, which is the first step toward a brief that actually holds.

The web design questionnaire (copy this)

Fourteen questions, grouped into six sections. Send it as a form, a shared doc, or paste it straight into an email. Keep the section headers, because they tell the client these are six different kinds of thing, not one undifferentiated wall of questions. Phrase them in your own voice, but keep the framing: every question gives the client a concrete handle to grab instead of an empty box to dread.

1 · Project goals

1. 1Why are you building or rebuilding this site right now? Every project has a trigger. A competitor relaunched, a rebrand happened, the current site is embarrassing you in sales calls. The trigger is the real brief, and it tells you which deadlines are real.
2. 2What should a visitor be able to do on the new site that they cannot do easily today? This pushes the goal toward an action ("book a consultation in under a minute") instead of a vibe ("look more modern"). The action is what you will design around.

2 · Target audience

1. 1Who is the main person this site is for? Describe one real visitor. "Everyone" is not an audience. One named, concrete person ("a stressed facilities manager comparing three suppliers on her phone") drives a hundred design decisions.
2. 2What do you want that person to think or do within ten seconds of landing on the homepage? Forces the client to prioritise. If everything is important, nothing leads, and you will spend the project arguing about the homepage hero.

3 · Design preferences

1. 1Link two or three websites you like, with one line on what you like about each. They do not have to be in your client's industry. The "why" matters more than the "what": "clean" and "calm" mean very different things to different people, and the examples decode their vocabulary.
2. 2Are there any sites, especially competitors, you actively dislike, and why? Knowing what to avoid is as useful as knowing what to aim for, and clients are often clearer and more honest about what they hate.
3. 3Do you already have brand assets (logo, colours, fonts, guidelines), or does the look need creating from scratch? This is a scope question hiding in the design section. "From scratch" is a different project, and a different quote, than "apply the existing guidelines".

4 · Technical requirements

1. 1Is the platform already decided (WordPress, Webflow, Shopify, custom), or is that our call? If they are wedded to a platform because their team knows it, that constrains everything downstream. Better to know on day one than in week six.
2. 2What does the site need to connect to: CRM, booking system, newsletter, payments, analytics? Integrations discovered late reopen decisions you thought were closed. Asked up front, each one is an architecture input instead of an ambush.
3. 3Who will update the site after launch, and how comfortable are they editing it themselves? A non-technical client who wants to edit everything needs a very different build from one happy to send you change requests. This quietly decides your whole CMS approach.

5 · Budget and timeline

1. 1Is there a hard date this needs to be live by, and what is driving it? A date with a reason behind it (a trade fair, a product launch) is real. A date with no reason is a preference you can negotiate. The "why" tells you which one you are dealing with.
2. 2What budget range are we working within for this phase? Agencies skip this to avoid awkwardness and pay for it in mismatched expectations. A range is enough; you are scoping to reality, not haggling.

6 · Existing assets and content

1. 1Who is writing the copy and supplying photography, and by when? The least glamorous question and the best predictor of whether you ship on time. Finished builds sit for months waiting on an "About us" page. Get a name and a date for every asset.
2. 2What from the current site must carry over: specific pages, search rankings, form destinations, tracked links? The fastest way to a furious client is to launch a beautiful new site that quietly drops their best-ranking page or breaks the contact form. Ask now what must not break.

That is the whole thing. Fourteen questions, six sections, no jargon a client has to decode. Notice that several "design" and "technical" questions are really scope questions in disguise, which is deliberate: the questionnaire is doing double duty as the first draft of your brief.

What good answers look like, filled in

A blank questionnaire is easy to find. The hard part is what comes back. Here is the same questionnaire answered for a fictional but very recognisable project: a small garden-design studio replacing a tired one-page site. The answers have been tidied into a brief, which is exactly what a completed questionnaire becomes once you organise it.

If you want to see the finished shape in full rather than a single example, there are three complete, filled-out project brief examples you can copy, covering a bakery site, a booking platform, and an internal tool.

The framing does half the work

A questionnaire only beats a call if the questions are written well. A lazily phrased field gets the same useless answer a blank brief would. Compare the design question asked two ways:

The first asks the client to be a designer and write a paragraph from nothing. Most people freeze and write "clean and modern", which tells you exactly nothing. The second gives them a small, concrete task they can do in two minutes, and the examples reveal what their words actually mean. Apply that test to all fourteen: every question should hand the client a specific thing to react to, never an empty category to define.

The same principle is why static briefs fail in the first place. If you want the longer version of how to phrase questions so clients answer them properly, it is the whole subject of how to write a project brief clients actually fill out.

What a questionnaire still cannot catch

Honesty check: a static questionnaire, however well written, has one weakness a conversation does not. It cannot follow up. When a client answers "the budget is flexible" or "anyone can update it", a good interviewer pushes back on the spot. A form just records the vague answer and moves on, and you discover the gap weeks later.

There is also a layer of questions a website form does not naturally surface at all: the second decision-maker you have never met, the system everything must secretly feed into, the previous agency that left scar tissue. Those are the conditions around the project rather than the brief itself, and they have their own list in the seven questions to ask clients before starting a project. Worth reading alongside this if you want the kickoff to be genuinely thorough.

So the ideal is a questionnaire that can follow up: one that asks all fourteen questions in order, but also pushes back on a vague answer the way a good interviewer would. That is the gap ReqBrief was built to close. Instead of sending a static form and hoping, you send your client a link, and an AI interviews them one question at a time, follows up when an answer is too thin, and turns the whole conversation into a structured brief shaped like the example above. You get the consistency of a questionnaire and the follow-up of a call, without having to be on the call.

Frequently asked questions