A website project often begins with a broad request: a client needs a new site, a refresh or a place to send potential customers. That is a useful starting point, but it is not yet enough to make good decisions about pages, copy, design or functionality. A thoughtful client questionnaire turns that broad request into practical information you can use before work begins.
The goal is not to create a long form for its own sake. It is to ask the questions that prevent avoidable delays later: what the business needs from the website, who it is for, what content already exists, who can approve decisions and what access is available. The answers give both designer and client a shared starting point.
Why ask these questions before website work starts?
Without a structured discovery step, important details can arrive after a sitemap is drafted, a layout is designed or copy is written. A new decision-maker may appear late in the project. A key service may be missing from the proposed pages. The client may expect online booking, a members area or a content migration that was never discussed.
A questionnaire does not replace a conversation. It makes that conversation more useful. It gives the client time to gather information from colleagues, locate files and consider priorities before a kickoff call. It also creates a record you can return to when choices about scope, content or timing need to be confirmed.
Business and company background
Begin with the business itself. You need enough context to understand what it offers, how it describes its work and what makes it distinct. Ask the client to explain their products or services in plain language, identify their main locations or service areas, and describe where their revenue or enquiries usually come from.
Useful questions to include
- What does your business do, and which services or products matter most on the new website?
- What should a first-time visitor understand about your business within a few seconds?
- Are there services, audiences or locations you want to grow?
- What makes your approach different from alternatives a customer might consider?
Website goals and target audience
“Get more business” is a reasonable ambition, but it needs to become a clearer website goal. A site may need to generate enquiries, make booking easier, explain a complex service, support an existing sales process or give current clients access to useful information. The desired action should guide page hierarchy, calls to action and the information placed near the top of each page.
Ask who the site is for as well. A business may serve several audiences, but they may arrive with different questions and levels of knowledge. Knowing which audience is most important helps you decide what to explain first and which proof, examples or services deserve prominence.
- What should visitors do after visiting the website?
- Who are the primary and secondary audiences?
- What questions, concerns or barriers do those people commonly have?
- How will the client know the new site is supporting its intended goal?
Pages, structure, content and copy
Before proposing a sitemap, ask what pages the client expects and why. A simple service business may need a home page, service pages, about page, contact page and a small resource area. Another business may need location pages, case studies, a team directory, frequently asked questions or a product catalogue. The important point is to identify the purpose of each page, not merely create a list of headings.
Content is often the slowest part of a web project. Find out what the client already has: current copy, brochures, presentations, photography, videos, logos, testimonials they are allowed to use, policies and service descriptions. Clarify who will provide missing copy and who will review it. If content is being migrated from an old site, establish which pages still matter and which should be retired.
Branding and visual direction
Ask for existing brand assets before discussing colours or layouts. This includes logo files, colour references, fonts, photography, illustrations and any brand guidelines. If the brand is still being developed, note that early: a website design should not be expected to settle every larger brand decision by itself.
Reference websites can be helpful when they are treated as a discussion tool, not a template. Ask what the client likes about an example: the clarity, photography, navigation, tone or way services are explained. Also ask what they do not want. This gives you useful direction without promising to reproduce another company’s site.
Functionality, features and technical access
List the features that need to work on launch day. This might include a contact form, appointment booking, newsletter signup, online payments, an events calendar, a client portal, search, maps or connections to another system. Ask how each feature is used now and who owns the related account. A feature request is easier to scope when its purpose and current process are clear.
Technical access deserves its own section. Confirm the domain registrar, hosting provider, current website platform and any connected services. Identify who can grant access and whether logins can be shared securely through the client’s normal process. Do not assume the person approving the design also controls the domain or email account.
Timeline, approvals and decision-makers
A realistic timeline depends on more than the design schedule. It also depends on content collection, feedback, approvals and access. Ask whether there is a fixed launch date, why it matters and what must be ready by then. Then agree on the practical rhythm for feedback: who reviews work, how many people can comment and who has final approval.
One point of contact can make a project easier to coordinate, but it is still useful to name every decision-maker early. That helps prevent contradictory feedback and reduces the risk that a major concern appears after the project has moved into build or launch preparation.
Post-launch expectations
Launch is not the end of the conversation. Ask what the client expects to manage after the site is live, whether they need training and who will handle future edits. Discuss any planned marketing activity, analytics review, search visibility work, content updates or support arrangements separately from the initial build. This keeps the launch scope clear while making the next steps visible.
A practical questionnaire checklist
Before you send a questionnaire, check that it gives you a way to collect the following:
- Business overview, priority services and differentiators
- Website goals, primary audiences and desired visitor actions
- Required pages, page priorities and existing site content
- Copy, images, logos, policies and other assets already available
- Brand guidelines, visual preferences and reference websites
- Launch-day functionality and any connected tools or accounts
- Domain, hosting, platform and access contacts
- Timeline, feedback process, decision-makers and final approver
- Training, handover and post-launch expectations
Keep the questions specific enough to guide useful answers, but leave room for context. When an answer raises a new question, use the kickoff conversation to explore it instead of trying to anticipate every situation in the first form.
When you want a reusable starting point
Building onboarding documents from scratch takes time, especially when you want the same process to be clear and consistent from one client to the next. The existing Web Designer Client Onboarding Kit includes a Website Discovery Questionnaire alongside templates for branding, content, assets, SEO information, kickoff and pre-launch review.