QUICK ANSWER
What should a website design questionnaire ask?
A website design questionnaire should ask about the business outcome, priority audience, current site, required content, proof and media rights, brand constraints, primary action, pages, forms or integrations, accessibility and privacy needs, domain and hosting access, budget and timing constraints, decision owners, and review process. Treat every answer as input to verify, not approved scope.
A website design questionnaire should expose what a client knows, what remains uncertain, which evidence supports each answer, who can decide, and which follow-up must happen before planning. It should not turn early stakeholder reports into approved scope, a quote, a sitemap, or a design brief.
This resource provides twenty controlled questions across ten discovery sections, two editable registers, a fictional completed record, a closed JSON Schema, and a dependency-free validator. The example keeps three blockers visible so teams can see why reported answers, supported evidence, conflicts, and planning readiness are different states.
Collect answers without pretending discovery is finished
Use one controlled revision, role-based respondents, stable question IDs, and explicit unknown states. The questionnaire is a discovery record that prepares planning; it is not the plan itself.
Freeze the revision, purpose, roles, and decision authority
State why the questionnaire exists, which website decision it prepares, who may answer each section, and which role owns final planning decisions. Keep stakeholder assumptions separate from evidence about real user needs.
Sources: [gds-user-needs], [govuk-question-pages]
Ask one bounded question at a time and allow an honest unknown
Give every question a purpose, required flag, sensitivity class, evidence expectation, follow-up trigger, and downstream owner. Do not request passwords, tokens, private keys, regulated records, or unnecessary personal data in the questionnaire or archive.
Reconcile claims, proof, rights, accessibility, and conflicts
Label an answer as reported, supported, needs-evidence, conflicted, decision-required, or not-applicable. Link objective website claims to current support, assign media-rights and accessibility owners, and preserve disagreement instead of choosing the most confident wording.
Sources: [google-helpful-content], [ftc-advertising-faq], [w3c-accessibility-plan]
Gate the handoff to planning without approving scope
Derive the blocker list from mandatory unknowns and conflicts. A record can become ready for planning only after those blockers resolve; even then, the approved brief, pages, requirements, price, schedule, accessibility review, and launch decision remain separate accountable work.
Sources: [gds-user-needs], [w3c-accessibility-plan]
What this questionnaire owns
Use the pack to collect pre-scope stakeholder inputs and organize evidence, uncertainty, conflicts, owners, and follow-up. Stop before those inputs become an approved plan or commercial commitment.
Included
- Controlled questionnaire identity, revision, dates, respondent roles, decision owner, and readiness state
- Twenty stable questions covering outcomes, audiences, actions, content, claims, media rights, pages, workflows, providers, brand, accessibility, migration, constraints, launch, and operation
- Response states, confidence, evidence, conflicts, sensitivity, follow-up, downstream ownership, and derived blockers
- Editable Markdown and CSV files, fictional JSON example, closed JSON Schema, strict validator, tests, README, and deterministic ZIP build
Not included
- An approved website brief, plan, scope, price, quote, contract, timeline, sitemap, wireframe, content plan, BRD, PRD, RFP, proposal, or vendor recommendation
- A substitute for user research, analytics review, accessibility evaluation, privacy or legal review, security review, rights clearance, or provider verification
- A native Playcode intake system, contact form, generic form builder, client onboarding process, design-feedback process, or live respondent database
- A promise of fewer revisions, lower cost, faster delivery, design quality, accessibility conformance, compliance, rankings, traffic, leads, sales, revenue, approval, launch, or project success
DOWNLOADABLE RESOURCE
Download the website design questionnaire pack
The ZIP contains the editable question set, a response ledger, a completed fictional record with three visible blockers, its closed schema, and the validator used to catch false readiness, broken references, unsafe content, CSV formulas, and archive drift.
Website design questionnaire template pack
A controlled pre-scope discovery record for client answers, evidence, unknowns, conflicts, follow-up, owners, and planning readiness.
Format: Markdown, CSV, JSON, JSON Schema, and dependency-free Node.js validator/tests in one deterministic ZIP
Locally reproduced August 1, 2026. SHA-256: 6178ad6b01fb7404a2a925fdaf7e8a7c56f80593342ac772453cd4f4bb78c7f1
Included
- Editable twenty-question Markdown template across ten discovery sections
- Question catalog and response register CSV files with stable IDs and explicit answer states
- Fictional reserved-domain JSON example, closed local-reference JSON Schema, strict validator, and thirty-two deterministic tests
Verification boundary
The ten-file allowlist is rebuilt twice, extracted, byte-compared with its source, validated, and tested locally. This proves artifact structure and coherence only, not truth, authority, user research, approved scope, compliance, design quality, feasibility, price, timeline, public deployment, or outcomes.
Three questionnaire records with different unknowns
Use the same controlled fields for different website jobs, but change the questions, evidence, sensitivity, and follow-up owners. None of these examples is an approved website plan.
New service-business website discovery
Use when: A small business knows its services and enquiry goal but has not yet approved audience evidence, claims, pages, or media rights.
Collect the priority customer job, primary enquiry action, current proof, content owner, service-page inputs, form purpose, minimum fields, brand references, decision authority, and launch ownership.
Structure
- Reported service and audience inputs with evidence owners and honest unknown states
- Claim, proof, media-rights, form-data, accessibility, and review follow-ups
- A planning gate that remains blocked until mandatory evidence and decision conflicts resolve
Watch for: Stakeholder answers do not replace customer research and do not prove that the website will generate leads or revenue.
Sources: [gds-user-needs], [ftc-advertising-faq], [govuk-question-pages]
Existing-site redesign and migration discovery
Use when: A team needs to record current-site evidence, retained content, URLs, providers, rights, and migration unknowns before planning a redesign.
Capture current owners, analytics and user evidence, claims, media rights, domain and hosting authority, URL inventory, SEO continuity inputs, accessibility review needs, maintenance ownership, and unresolved migration decisions.
Structure
- Current-state evidence and owners separated from desired redesign changes
- Content, claims, rights, URL, provider, accessibility, and recovery questions
- Explicit handoff to a later website plan rather than an automatic sitemap or redirect specification
Watch for: The questionnaire does not audit the current site, certify accessibility, approve redirects, or guarantee ranking preservation.
Public website plus authenticated workflow discovery
Use when: The proposed website includes a public experience and a private form, portal, account, or record workflow with provider and data questions.
Separate public content from authenticated roles, minimum-purpose data, access, provider ownership, failure paths, sensitive inputs, export, retention, recovery, and operating responsibility before requirements are approved.
Structure
- Public audience, action, content, proof, and page inputs
- Private workflow, role, data-purpose, provider, failure, privacy, and recovery questions
- Security and specialist-review follow-ups kept outside the questionnaire readiness claim
Watch for: Do not place credentials, production exports, customer records, regulated data, or private provider details in the questionnaire pack.
Sources: [owasp-secrets-management], [w3c-accessibility-plan]
Decide whether answers are ready for website planning
The validator can expose a missing answer or inconsistent state. Accountable people still decide whether the evidence, authority, risks, and follow-up are sufficient for the next planning step.
A required question has no answer and the question does not permit an unknown state.
Choose: Keep the record in review, name an owner and follow-up, and collect the missing input before planning.
Tradeoff: Planning starts later, but it does not silently invent a business, audience, ownership, or workflow decision.
Two answers conflict about authority, claims, rights, provider ownership, budget, timing, pages, or launch responsibility.
Choose: Preserve both inputs, flag the conflict, assign one decision owner, and record the resolution as a new revision.
Tradeoff: The disagreement stays visible instead of being hidden inside a confident but unapproved brief.
A response contains credentials, secret links, unnecessary personal data, regulated records, or private exports.
Choose: Remove the sensitive value, rotate any exposed credential through its owner, and record only the minimum role and follow-up needed for planning.
Tradeoff: The questionnaire carries less operational detail, but it no longer becomes a secret-transfer or private-data store.
Every derived blocker is resolved and the response, evidence, conflict, follow-up, and owner references are internally coherent.
Choose: Mark the revision ready for planning and hand it to the website planning owner without claiming scope approval.
Tradeoff: The next team receives a reviewable input record but must still synthesize and approve the actual brief.
COLLECT THE INPUTS BEFORE APPROVING THE PLAN
Use one controlled questionnaire revision
Download the editable questions, response register, fictional example, schema, validator, and tests. Keep unsupported answers and conflicts visible.
Download the questionnaire packThe pack records discovery inputs. It does not approve scope, price, schedule, design, accessibility, privacy, security, or launch.
Turn reviewed answers into a website planUse the planning guide after the questionnaire blockers are resolved and the input revision is ready for synthesis.
Limits to review before using the questionnaire
A controlled questionnaire makes omissions and conflicts easier to see. It cannot establish whether an answer is true, complete, authorized, lawful, feasible, or valuable.
- The pack is original editorial work, not a contract, proposal, RFP, approved brief, requirements document, research report, legal form, accessibility audit, compliance tool, or professional certification.
- A validator pass checks structure, references, state consistency, safety patterns, parity, and readiness blockers. It does not verify facts, authority, evidence quality, rights, accessibility, privacy, security, providers, feasibility, price, schedule, or outcomes.
- Stakeholder answers can describe beliefs and constraints, but they are not a substitute for current user research, behavioral evidence, analytics review, or direct usability evaluation.
- The fictional organization, roles, questions, dates, evidence, follow-ups, and reserved .example.test links are examples, not client-tested engagement data or universal best practices.
- GOV.UK, W3C, Google, FTC, and OWASP guidance supports the stated question and evidence boundaries; those publishers did not review or endorse this Playcode pack and confer neither compliance nor rankings.
- Keep passwords, tokens, private keys, secret links, private customer or supplier records, payment details, health data, government identifiers, and other regulated data outside the questionnaire and archive.
Primary guidance used for the questionnaire boundary
These current sources support user-needs, question design, accessibility planning, helpful evidence, advertising support, and secret-handling boundaries. The artifact remains Playcode editorial work.
[gds-user-needs] GOV.UK Service Manual:Start by learning user needs
Checked August 1, 2026. Supports: Starting service work from evidenced user needs and avoiding organization-led assumptions about what users need.
[govuk-question-pages] GOV.UK Design System:Question pages
Checked August 1, 2026. Supports: Asking only needed questions, usually one bounded question per page, with suitable hints and answer formats.
[w3c-accessibility-plan] W3C Web Accessibility Initiative:Planning and managing web accessibility
Checked August 1, 2026. Supports: Treating accessibility as planned organizational work with goals, responsibilities, resources, evaluation, and ongoing review.
[google-helpful-content] Google Search Central:Creating helpful, reliable, people-first content
Checked August 1, 2026. Supports: Reviewing whether content is useful, trustworthy, sourced, clear about expertise, and made for the intended audience rather than rankings alone.
[ftc-advertising-faq] Federal Trade Commission:Advertising FAQs: A guide for small business
Checked August 1, 2026. Supports: Keeping objective advertising claims tied to appropriate support rather than treating stakeholder wording as proof.
[owasp-secrets-management] OWASP Cheat Sheet Series:Secrets Management Cheat Sheet
Checked August 1, 2026. Supports: Keeping secrets governed through dedicated lifecycle controls instead of collecting them in ordinary planning documents.
Website design questionnaire questions
Is a website design questionnaire the same as a website brief?
No. The questionnaire collects stakeholder answers, evidence, unknowns, conflicts, constraints, owners, and follow-up before planning. A website brief is a later approved synthesis of the audience, journeys, pages, content, workflows, requirements, acceptance, launch, and operating decisions.
How many questions should a website design questionnaire include?
Use only the questions needed for the decision. This pack starts with twenty questions across ten sections so each question has a purpose, state, owner, and follow-up. Remove irrelevant optional questions rather than asking for information nobody will use.
What if the client does not know an answer?
Record the unknown honestly when the question permits it, assign a follow-up owner, state the evidence or decision needed, and keep planning blocked if the unknown is mandatory. Do not turn a missing answer into an assumption without labeling and review.
Should a website questionnaire ask for budget and timeline?
It can ask for budget and timing constraints as reported planning inputs. Those answers are not an approved quote, fee, estimate, delivery schedule, or commitment. Record who supplied them, their confidence, conflicts, and the role that can later approve commercial scope.
Can the questionnaire replace user research?
No. Stakeholders can report business context, beliefs, constraints, ownership, and available evidence. They cannot substitute for direct evidence about users, their tasks, barriers, behavior, or environment. Keep stakeholder statements labeled until the planning team reviews current user evidence.
Should clients put domain passwords or API keys in the questionnaire?
No. Record the accountable owner and the later secure handoff procedure, not the credential itself. If a secret was pasted into the questionnaire, remove it, rotate it through the provider owner, and review copies, exports, logs, and access.
When is the questionnaire ready for planning?
It is ready when required answers are present or explicitly allowed unresolved, references resolve, conflicts and mandatory unknowns are cleared, follow-up ownership is coherent, and the blocker list is empty. Ready for planning still does not mean scope, price, schedule, accessibility, compliance, or launch is approved.
BUILD AFTER THE BRIEF IS REVIEWED
Turn the approved website plan into a working first version
Resolve questionnaire blockers, approve the brief, then describe the pages, content, workflows, constraints, acceptance evidence, and exclusions you want to build.
Build the website with PlaycodeThe questionnaire remains an informational resource and does not grant signup AI credits. AI credits are included to start on the eligible commercial builder path. No credit card required.