QUICK ANSWER
What should a website design proposal include?
A website design proposal should identify the parties and revision, project context, intended outcomes, included and excluded scope, deliverables, client responsibilities, accessibility roles, milestones, fees, external costs, review rounds, acceptance evidence, change control, rights questions, handoff contents, and authorized decision. Keep legal terms in a governing agreement reviewed for the parties and jurisdiction.
A website design proposal should make the commercial decision reviewable before design work starts. It needs an exact revision, authorized decision owners, included and excluded scope, named deliverables, client inputs, review rounds, acceptance evidence, schedule assumptions, fees, external costs, change control, rights questions, accessibility responsibilities, and handoff boundaries.
The downloadable pack includes an editable Markdown template, a completed fictional JSON example, a JSON Schema, and dependency-free validation tests. It helps expose missing decisions without pretending to be a signed agreement, legal advice, accessibility certification, a business requirements document, or a product requirements document.
Build the proposal around decisions, not sales copy
A useful proposal lets both sides see what is being decided, which evidence applies, what remains outside scope, and what must happen before work or acceptance can move forward.
Control the revision and decision owners
Give the proposal a stable ID, revision, prepared date, expiry date, status, and one authorized decision owner for each party. Link it to the governing agreement rather than silently mixing a sales document with unreviewed legal terms. A new revision should supersede the old boundary instead of overwriting its evidence.
Sources: [aiga-standard-agreement]
Connect scope to deliverables and acceptance evidence
Name each included activity, exclusion, client input, deliverable, output format, review round, milestone, fee item, and acceptance criterion with stable IDs. State what happens when required content, rights, feedback, or approval arrives late. Route additions through change control before changed work begins.
Sources: [aiga-standard-agreement]
Assign accessibility through the production process
Record the applicable objective or policy, client, design, development, content, and acceptance responsibilities, required resources, evaluation checkpoints, monitoring plan, and unresolved risks. Review accessibility early and repeatedly; do not treat a proposal, design file, automated check, or validator as proof of conformance.
Sources: [w3c-planning-accessibility]
Close with rights, handoff, and operation boundaries
Identify pre-existing and third-party materials, the governing transfer or license terms, portfolio permission, source and export files, domain and hosting account ownership, documentation, credential-transfer channel, launch evidence, maintenance boundary, and backup or recovery responsibility. Keep credentials outside the proposal and archive.
Sources: [aiga-standard-agreement], [w3c-planning-accessibility]
What this proposal pack owns
Use the pack for the client-provider commercial handoff before website design work starts or changes. Keep adjacent requirement, legal, implementation, and operating artifacts under their accountable owners.
Included
- Proposal identity, revision, status, parties, decision owners, prepared date, expiry, and decision record
- Project context, intended outcomes, non-goals, included scope, exclusions, deliverables, client responsibilities, and dependencies
- Accessibility objectives, roles, checkpoints, evidence, and unresolved-risk boundary across discovery, design, build, and pre-launch
- Milestones, review rounds, acceptance criteria, fees, external costs, change control, rights questions, handoff, maintenance, and recovery boundaries
- Editable Markdown, completed fictional JSON, JSON Schema, validator, thirteen tests, README, and deterministic ZIP build
Not included
- The business problem and business approval owned by a business requirements document
- Detailed users, behavior, interface states, technical requirements, and product acceptance owned by a product requirements document
- A signed contract, legal advice, tax advice, accounting advice, procurement approval, or jurisdiction-specific terms
- Finished copy, information architecture, visual design, implementation, hosting, domain purchase, provider setup, or ongoing maintenance unless separately approved
- Accessibility conformance, legal compliance, security, privacy, rights clearance, delivery date, price fairness, or client approval established by the template or validator
- A promise of traffic, rankings, leads, sales, revenue, approval, accessibility, compliance, or project success
DOWNLOADABLE RESOURCE
Download the website design proposal pack
The ZIP contains one editable proposal, a completed fictional machine-readable example, its schema, and the validator used to expose broken references, totals, dates, accessibility ownership, acceptance, change, rights, and handoff boundaries.
Website design proposal template pack
A revision-controlled website design proposal for scope, deliverables, responsibilities, accessibility, fees, review, acceptance, changes, rights questions, and handoff.
Format: Markdown, JSON, JSON Schema, and dependency-free Node.js validator/tests in one ZIP
Locally reproduced August 1, 2026. SHA-256: 3e94cbd3dc272065dadba70cab9e51aff230263a0ebda5a3552ae46d587e27a6
Included
- Editable thirteen-section Markdown proposal with an explicit governing-agreement boundary
- Completed fictional JSON example and JSON Schema using stable deliverable, acceptance, milestone, and fee identities
- Dependency-free validator and thirteen deterministic positive and negative tests
Verification boundary
The allowlisted archive was rebuilt twice, extracted, byte-compared with its canonical source files, and tested locally. This verifies the pack, not a signed agreement, client decision, project result, public deployment, or accessibility outcome.
Three proposal shapes for different website engagements
The same core record can support different commercial decisions. Change the scope, evidence, owners, and handoff instead of disguising uncertainty with a generic fixed package.
Fixed-scope marketing website proposal
Use when: The client has an approved page inventory, content owner, rights-cleared assets, decision owner, and bounded design deliverables.
Name the exact pages, responsive states, component set, client inputs, review rounds, acceptance criteria, fee items, excluded implementation, and source-file handoff. Keep third-party costs and ongoing operation outside the fixed subtotal unless explicitly included.
Structure
- Six named pages, one visual direction, responsive screen set, annotations, and allowlisted handoff
- One consolidated feedback owner, two named review rounds, acceptance evidence, and written change route
- Fixed fee items with tax and external-cost boundaries rather than an unsupported total-only price
Watch for: A fixed fee is unsafe when the page inventory, content, rights, decision owner, or implementation boundary is still moving. Resolve the dependency or use a phased proposal.
Sources: [aiga-standard-agreement], [w3c-planning-accessibility]
Website redesign and migration proposal
Use when: The engagement must preserve useful content and URLs while creating a new design and transferring approved source material.
Add a source inventory, retain-or-change decision, redirect owner, rights review, content migration boundary, implemented accessibility evaluation, launch acceptance, rollback owner, and post-launch monitoring handoff. Design approval and production launch remain separate decisions.
Structure
- Current-page and asset inventory with owner, rights, status, and destination decisions
- Design deliverables linked to implementation and pre-launch acceptance evidence
- Domain, hosting, analytics, redirect, backup, rollback, documentation, and maintenance accountabilities
Watch for: A visual redesign proposal alone does not establish preserved SEO, migrated content, working redirects, accessibility, analytics, or a safe launch. Name those owners and evidence separately.
Sources: [aiga-standard-agreement], [w3c-planning-accessibility]
Paid discovery followed by a design proposal
Use when: The client knows the business situation but the audience, content, page inventory, technical constraints, accessibility policy, or delivery scope is not yet reviewable.
Propose a bounded discovery phase first. Its deliverables should resolve audience and page decisions, source inventories, responsibilities, risks, and acceptance inputs. Price the later design phase only after the discovery evidence supports a stable revision.
Structure
- Discovery questions, evidence owners, workshops, inventories, risks, decision date, and stop condition
- A separate design-phase proposal triggered by approved discovery outputs
- Explicit right to stop, rescope, or request qualified review when the evidence remains insufficient
Watch for: Do not label an uncertain full project as fixed merely to make the proposal easier to approve. A smaller paid decision phase is more honest than hidden assumptions.
Sources: [aiga-standard-agreement], [w3c-planning-accessibility]
Decide what can be approved now
Treat every unresolved field as a decision or dependency. Do not turn missing information into an implied deliverable, deadline, legal term, or outcome.
The page inventory, content owner, rights status, decision owner, or technical boundary is unresolved.
Choose: Approve a bounded discovery phase or keep the proposal in review until the missing owner and evidence are recorded.
Tradeoff: The full design starts later, but its scope and fee rely on fewer hidden assumptions.
The work is clear but client feedback arrives from several people through separate channels.
Choose: Name one authorized feedback owner and require one consolidated response for the exact revision.
Tradeoff: Internal client alignment takes work, but the design provider receives one reviewable decision instead of conflicting instructions.
A requested change affects deliverables, schedule, fees, rights, or risk.
Choose: Pause the changed work, record a change request, assess every affected boundary, and approve a new proposal revision first.
Tradeoff: The change gains visible cost and schedule effects rather than being absorbed as invisible scope.
Accessibility responsibility is assigned only to development or postponed until the end.
Choose: Assign policy, design, content, development, evaluation, acceptance, and monitoring owners across the full production process.
Tradeoff: More roles participate earlier, reducing the risk that late findings require expensive redesign or remain unresolved.
The proposal is expected to decide ownership, warranties, liability, termination, disputes, taxes, or jurisdiction.
Choose: Use the template to identify the questions, then place the reviewed terms in a governing agreement with qualified advice where needed.
Tradeoff: The commercial record stays understandable while legal terms receive their own accountable review.
FROM APPROVED SCOPE TO A WORKING WEBSITE
Build from the decisions the client actually approved
Use the page inventory, content, visual direction, states, acceptance evidence, and handoff boundary as a grounded website brief.
Explore the AI website builderKeep unresolved rights, accessibility, provider, and operating decisions visible during the build.
Read how to plan a websiteUse the planning guide when the audience, pages, content, functionality, or launch boundary is not ready for a proposal.
Limits to review before using the template
A structured proposal can reveal gaps and keep revisions consistent. It cannot make the commercial, legal, accessibility, content, technical, or delivery decisions correct.
- The pack is an editorial planning artifact, not legal, tax, accounting, insurance, procurement, employment, or jurisdiction-specific advice.
- A validator pass checks internal structure and references. It does not prove facts, authority, signatures, price fairness, enforceability, rights, security, privacy, accessibility, compliance, delivery, or outcomes.
- The fictional amounts, schedule, parties, acceptance evidence, and project boundaries are examples, not market benchmarks or recommendations.
- AIGA and W3C provide source guidance; neither organization reviewed, approved, certified, or endorsed this Playcode artifact.
- Keep passwords, API keys, domain credentials, hosting credentials, client secrets, private evidence, and regulated data outside the proposal and downloadable archive.
- Review the exact implemented website in its target environment. Design files and proposal language cannot establish production behavior or accessibility conformance.
Primary guidance used for the template boundary
These sources support the agreement and accessibility-planning structure. The downloadable pack and its validation rules are Playcode editorial work and carry no source endorsement.
[aiga-standard-agreement] AIGA, the professional association for design:Standard Form of Agreement for Design Services, 2022 update
Checked August 1, 2026. Supports: Using a written, modular design agreement to clarify expectations and adapt services and terms to the engagement with qualified legal review for the parties and circumstances.
[w3c-planning-accessibility] W3C Web Accessibility Initiative:Planning and Managing Web Accessibility
Checked August 1, 2026. Supports: Integrating accessibility throughout web production by planning goals, responsibilities, resources, early and regular evaluation, progress tracking, monitoring, and continued review.
Website design proposal template questions
Is a website design proposal the same as a contract?
Not necessarily. A proposal usually presents the project, scope, deliverables, schedule assumptions, fees, review, and handoff for a commercial decision. The governing agreement should hold the reviewed legal terms that apply to the parties and jurisdiction. This template is not legal advice.
What is the difference between a design proposal, BRD, and PRD?
The proposal owns the client-provider commercial boundary. A business requirements document owns the business problem, outcomes, actors, and business approval. A product requirements document owns users, behavior, states, and product acceptance. Link their exact revisions when the engagement needs all three.
How many revision rounds should a website proposal include?
Use the number supported by the scope, fee, schedule, and feedback process rather than a universal rule. Name what counts as one consolidated review, which deliverables it covers, the response window, and how additional or changed work enters change control.
Should accessibility appear in a website design proposal?
Yes, when the project has accessibility responsibilities. Name the applicable objective or policy, roles, budget, evaluation checkpoints, evidence, acceptance owner, monitoring, and unresolved risks. Do not claim that proposal language, a design review, or an automated test establishes conformance.
What should happen when the client changes scope?
Record the requested change, affected deliverables and acceptance criteria, schedule and fee effects, accessibility and rights effects, decisions, and approved proposal revision. Do not let an informal message silently replace the reviewed scope.
Who should own domains, hosting accounts, and credentials?
The proposal should name the account owner and handoff responsibility explicitly. Keep credentials out of the proposal and archive, and transfer them only through an approved secret-management channel. State who owns launch, backup, recovery, export, and ongoing maintenance separately.
Does the validator approve the proposal?
No. It checks structure, references, totals, dates, accessibility ownership, acceptance, change-control, rights, and handoff fields. Only authorized people can approve a proposal, and qualified reviewers still own its legal, tax, accessibility, security, privacy, rights, and operational meaning.
A REVIEWABLE BRIEF IS THE STARTING POINT
Turn the approved proposal into the first working version
Describe the approved pages, content, direction, responsive states, acceptance evidence, and exclusions. Keep every changed assumption visible as the website evolves.
Build the website with PlaycodeNo credit card required. AI credits included to start.