Client Onboarding Questionnaire for Web Design

A web design onboarding questionnaire covers goals, audience, brand, content, and technical needs — asked before design starts, not discovered midway.

Why the order matters

Most botched web projects don't fail because of bad design. They fail because a decision that should have been made in week one — the real target audience, a hard launch date, who actually signs off — surfaces in week five, after work has already gone in the wrong direction. An onboarding questionnaire exists to force those decisions early, while changing course still costs an afternoon instead of a rebuild.

The temptation is to open with "tell us about your project" and let the client talk. That gets you enthusiasm, not information. A structured list, asked in a deliberate order, gets you the handful of facts that actually change what you build — and it gets you the same facts from every client, so nothing depends on whether this particular one happened to think of it.

The 35 questions below are grouped into six categories: business and goals, audience, brand and style, content, technical, and timeline and budget. Ask them roughly in that order — goals first, budget last — because each category narrows what the next one needs to cover.

Business and goals

• What does this site need to accomplish in the first six months? Turns "make it look professional" into a measurable target — more bookings, fewer support calls, a credible presence for a funding pitch.
• What is the single action you want a visitor to take? Every page design changes depending on whether the goal is a phone call, a purchase, a booking, or a newsletter signup.
• Who are your two or three biggest competitors, and what do you like or dislike about their sites? Gives you real reference points instead of abstract style words, and often reveals a feature the client assumes is standard.
• What's driving this project now — a rebrand, a broken old site, a new business, something else? The reason for the project shapes what "done" looks like more than any design brief does.
• What would make this project a failure, even if the site looks great? Surfaces the one hidden requirement — a specific integration, a legal disclosure, a family member's opinion — before it becomes a week-five surprise.
• Do you already use analytics, a CRM, or an email platform that this site needs to connect to? Flags integration work early, when it's a scoping conversation instead of a launch-week scramble.

Audience

• Who is your ideal customer? The basis for every other content and design decision — a site for retirees and a site for university students shouldn't share a template.
• What device do most of your visitors use — mostly phone, or mostly desktop? Tells you where to spend the mobile-testing time, rather than treating both equally by default.
• What questions do people ask before they buy or book with you? This is your FAQ page and half your homepage copy, already written by the client without them realizing it.
• What makes someone hesitate to choose you over a competitor? The honest answer to this is worth more than any tagline — it tells you what the copy needs to overcome.
• Is this site mainly for new customers, existing ones, or both? Changes whether the homepage leads with a pitch or with a login/account link.

Brand and style

• Do you have an existing logo and brand guidelines? Determines whether this is a design project or also a branding project, which is a scope and price conversation, not a design one.
• Name three websites you like the look of, and say why. Concrete references settle arguments about taste far faster than adjectives do.
• Pick three words for how you want the brand to feel. "Playful," "clinical," and "luxury" each rule out entire design directions before you've drawn anything.
• Any colors, fonts, or styles you specifically want to avoid? Often more useful than what they want — a client with a strong negative opinion about their previous designer's choices will tell you.
• Do you have brand fonts already, or should we choose them? A small scope question that avoids a wasted round of "no, not that font either."
• Is there an existing style guide, or files from a previous designer, we should see? Reusable assets that save time, and a signal of what's already been tried and rejected.

Content

• Do you have your own copy ready, or do you need copywriting help? The single biggest driver of both timeline and price on most small web projects, and the one most clients underestimate.
• What pages does the site need — home, about, services, contact, blog, others? The sitemap, stated in the client's own words before you impose a structure on it.
• Do you have product or service descriptions ready to go? Distinguishes "we have a menu" from "we have a menu but it's four years old and half the dishes changed."
• Do you have professional photos, or will this need a shoot or stock images? A photo gap discovered in week four stalls a launch; discovered in week one, it's a line item.
• Do you have testimonials, reviews, or case studies we can use? Trust content that's usually sitting in an email inbox or a Google review page, unused, until someone asks.
• What are your opening hours, service area, and pricing structure, if public? Small factual details that block a launch far more often than any design decision does.
• Do you have a privacy policy and terms of service already, or do these need drafting? A compliance gap that's easy to miss until a payment processor or an ad platform asks for one.

Technical

• Do you already have a domain, or does one need to be registered? A same-day task if asked early; a launch-blocker if discovered the week you meant to go live.
• Is there an existing site being replaced? If so, what needs to carry over — page URLs for SEO, email accounts, a redirect plan? Missing this is how a redesign quietly loses two years of search ranking.
• Do you have a platform preference — WordPress, Shopify, custom-built, or no preference? Sets the technical constraints for everything that follows, including who can edit the site later.
• Do you need e-commerce, bookings, or integration with a payment processor, calendar, or CRM? Each of these is its own scoping conversation, better had before a quote than after one.
• Who currently manages your hosting and business email, and will that change with this project? A frequent source of launch-day surprises when it isn't asked until launch day.
• Do you want analytics or ad tracking set up (Google Analytics 4, a Meta pixel, etc.)? Cheap to add during the build, awkward to retrofit once traffic is already flowing.

Timeline and budget

• Is there a hard deadline — an event, a launch, a funding round, a trade show? Distinguishes a real constraint from an aspirational one, which changes how you sequence the work.
• What's the budget range for this project? Uncomfortable to ask, essential to know before you scope a solution the client can't afford.
• Who has final sign-off on the design — one person, or a committee? The single best predictor of how many revision rounds a project will need.
• How available will you be for feedback and approvals during the project? A client who disappears for two weeks mid-project needs a different schedule than one who replies within the hour.
• Do you want ongoing maintenance and support after launch, or a one-time build? Changes what "finished" means, and whether the relationship continues after the invoice is paid.

How to deliver the questionnaire

The format matters as much as the questions. Two options, and they suit different questions:

A form or link, answered asynchronously. Best for anything factual that doesn't benefit from discussion — domain status, existing platform, opening hours, whether photos exist. The client can look things up (their current hosting login, an old invoice with pricing) instead of guessing on a call. It also produces a written record you can refer back to, rather than a memory of what was said.

A live call. Best for anything that benefits from follow-up questions — brand feel, competitor opinions, what makes a customer hesitate. These answers are usually short and vague in writing ("modern, but not too corporate") and only become useful once you ask "modern like what, specifically?" A form can't do that; a fifteen-minute call can.

A practical split: send the factual and asset-check questions — business basics, technical setup, existing content and brand assets — as a form before the kickoff call. That gives the client time to actually look things up instead of answering from memory, and it means the call itself is spent on the questions worth discussing (goals, audience, style direction) rather than reading a form out loud. Content that takes time to gather — final copy, a photo shoot, testimonials — is collected after kickoff, on its own schedule, since holding the kickoff hostage to a copywriter who hasn't started yet helps no one.

If you're structuring this as a formal request rather than a shared document, each of the questions above maps cleanly onto a typed item — a short text field for a domain name, a file upload for a logo, a structured object for opening hours — which is exactly the shape BriefGate's item types are built around, so the client's answers come back ready to use rather than as another loose page of text.

Where BriefGate fits

Everything above works as a plain document — a shared form, a call script, a checklist in your project management tool. BriefGate exists for what happens after the questionnaire is answered: it turns this list into a branded client portal with no login required, chases the client automatically on a schedule (see the chase engine) until every item is in, and hands the answers back as typed data instead of a pile of email replies to reconcile. If you're also fighting to get clients to actually respond to a request like this, see our guide on why clients don't send materials for the reminder cadence and contract language that fixes it. Start at briefgate.dev to see the full flow.