Freelancers guide
Web Design Proposal Template: Build Clarity Before You Build Pages
A practical structure for outcomes, scope, pricing, feedback, dependencies, and change requests.
Practical guide · 6 min read
A useful web design proposal does more than look professional. It gives the client a concrete picture of the outcome, shows exactly what work is included, and exposes the decisions that can change price or timing. Adapt this structure to the project and pair it with an appropriate service agreement; it is not legal advice.
1. Start with the client's outcome
Avoid opening with a long biography. Summarize the situation in the client's language:
[Client] needs a clearer path for [audience] to [priority action]. This project will redesign and build [site scope] so the team can [operational outcome].
If the client has not supplied evidence for a claim, label it as an assumption. Do not promise revenue, rankings, or conversion improvements you cannot guarantee.
2. Name the scope in observable terms
Replace “complete website” with a list someone can inspect:
- Sitemap for a stated number of pages.
- Wireframes and responsive designs for named page types.
- Development in the agreed platform or stack.
- Entry of client-approved copy up to a defined limit.
- Browser, accessibility, launch, and handoff checks.
Use a separate exclusions list for services people often assume are included: copywriting, photography, paid fonts, multilingual content, e-commerce, ongoing SEO, hosting fees, or maintenance.
3. Connect deliverables to acceptance
“Two design concepts” describes an output but not the decision. Add a review artifact and acceptance point.
| Deliverable | Client reviews | Accepted when |
|---|---|---|
| Sitemap | Page hierarchy | Agreed pages and relationships are present |
| Design direction | Key desktop/mobile screens | Consolidated feedback is resolved |
| Staging build | Functional checklist | No agreed launch blocker remains |
| Handoff | Access and documentation | Client confirms receipt |
Acceptance should be tied to the written scope—not “perfect,” “modern,” or another subjective word.
4. Show pricing without hiding the model
For a fixed-scope project, show meaningful phases instead of one unexplained total. State when each payment is due, whether taxes or third-party costs are included, and what happens before handoff.
| Phase | Fee |
|---|---|
| Discovery and structure | [amount] |
| Design | [amount] |
| Development and QA | [amount] |
| Total | [amount] |
If scope is still uncertain, propose a paid discovery phase instead of presenting a falsely precise implementation price.
5. Put dependencies next to the timeline
A launch date depends on more than freelancer availability. Name one decision-maker, a feedback window, content and access deadlines, and who owns legal or compliance approval. Explain that late dependencies move later milestones by at least the same delay.
Define reviews and changes
State how many consolidated review rounds are included at each stage. For work outside the approved scope, use a calm written process:
A request outside the included scope receives a written estimate of its fee and timeline impact. Work begins only after written approval.
6. Pre-send checklist
- The client and project names are correct.
- Included and excluded work are both visible.
- Fees, currency, tax treatment, and payment dates are unambiguous.
- Dates include client dependencies.
- Review rounds and change control are explicit.
- The PDF contains no placeholder text and works on mobile and desktop.