How to Write a Website Redesign Proposal That Wins

Start with the real promise: outcomes + effort

Clients don’t need more ideas—they need clarity. Your proposal should answer two questions quickly:

• What will we improve (outcomes)?
• What will it take (effort and scope)?

When you write your redesign proposal this way, people can say “yes” with less back-and-forth. It also protects your time, because expectations are written down.

1) Discovery and goals (make the problem legible)

This is where you show you understand the current site and what “better” means for them.

What to include in this section

Use short subsections so scanning is easy:

• Current state review: what you’re looking at (pages, navigation, design, performance, forms, SEO basics).
• Goals: 3–5 measurable goals. Examples:
  • Increase lead conversions from the homepage
  • Improve usability for mobile visitors
  • Make content easier to update
  • Reduce load time for key pages
• Success metrics: what you’ll track (even if it’s “before vs after”).
• Audience and use cases: who the site is for and what they need to do.
• Constraints: brand rules, CMS limits, legal/compliance needs, timeline requirements.
• Assumptions: what you’re assuming the client will provide (content, access, approvals).

Common mistake

Avoid writing: “We’ll redesign the website to be more modern and user-friendly.”

Instead, tie the redesign to goals, like: “We’ll redesign the homepage and main service pages to increase form submissions by clarifying value, improving mobile layout, and tightening the navigation path to contact.”

2) Redesign approach (audit → UX/IA → UI → dev handoff)

Now you explain how you’ll get from “current state” to “goals.” This is your credibility section.

A practical approach you can copy

A clear redesign flow often looks like this:

1. Audit (what’s working, what’s not, what’s missing)
   • Quick review of analytics (if available)
   • Page-by-page content check
   • UX friction notes (where users get stuck)
2. UX + IA (structure and user paths)
   • Site map / information architecture
   • User journeys or key task flows
   • Wireframes for key templates (not every single page at once)
3. UI design (visual direction that fits the brand)
   • Design system basics (typography, colors, components)
   • Page designs for key templates
   • Responsive states (mobile/tablet/desktop)
4. Dev handoff (so development doesn’t stall)
   • Specs and component usage
   • Asset export and guidelines
   • QA checklist for layout, responsiveness, and key interactions

Keep it simple. You’re not writing a textbook—you’re giving a client a map.

AI prompt you can use (drafting assist)

You can use AI to help you draft a first version of this section. Paste in your notes and ask for a structured approach like this:

“Act as a senior web designer. Draft a proposal section titled ‘Redesign approach’ for a website redesign. Use this sequence: audit → UX/IA → UI → dev handoff. Make it concise, client-friendly, and specific to a freelancer proposal. Include bullet points for what you do in each step and what the client provides (access, approvals, content).”

Then edit it so it matches your real process.

3) Deliverables list (be specific enough to price and approve)

A deliverables section is where good proposals win. It turns “What exactly do we get?” into a clean list.

How to write deliverables that feel “complete”

For each deliverable, include:

• What it is (wireframes, UI designs, design system)
• What pages/templates (homepage, service pages, blog index, etc.)
• What “done” means (approved, responsive, handed off with specs)
• What’s included (revisions count, accessibility pass if you offer it, performance considerations)

If you’re not careful, deliverables become vague like “We’ll redesign pages.” That’s hard to price and easy to renegotiate.

Example “specificity” language

Here are phrases you can adapt:

• “Wireframes for Homepage + 3 core page templates (Service, About, Contact), including mobile layout.”
• “UI design for Homepage + 3 core templates, using a small design system (type scale, colors, buttons, cards, form styles).”
• “Responsive implementation notes for desktop/tablet/mobile layout behaviors for each template.”
• “Dev handoff package including component list, spacing rules, and redlines where needed.”

Deliverables checklist (pasteable)

Copy this checklist and tick what applies:

• Discovery outputs: goals summary, content/information gaps list
• Audit findings: UX friction notes + quick priority list
• UX/IA: site structure + key user paths (as needed)
• Wireframes: [ ] Homepage [ ] Core templates (list) [ ] Mobile states
• UI design: [ ] Homepage [ ] Core templates (list) [ ] Responsive design
• Design system: [ ] Components + styles [ ] Form elements [ ] Buttons/typography
• Responsive pages: [ ] Key templates designed for all breakpoints
• Performance pass (lightweight): [ ] Image and asset guidance [ ] Key layout weight checks
• Dev handoff: [ ] Specs/redlines [ ] Component usage notes [ ] QA checklist
• Handover: [ ] Assets + documentation for client/developer

Note: Only include items you truly provide.

4) Timeline and milestone suggestions (so “yes” has momentum)

A timeline makes the project feel real. It also prevents the “we’ll get to it soon” trap.

A milestone pattern that works

A solid redesign proposal often uses 4–6 milestones:

1. Kickoff + Discovery (Week 1)
   • Goals confirmed, access collected, timeline and approvals set
2. Audit + UX/IA (Week 2)
   • Findings + site structure + wireframe plan
3. Wireframes Approval (Week 3)
   • Wireframes reviewed and signed off
4. UI Design (Weeks 4–5)
   • UI for key templates + responsive states
5. Design Handoff + Build Support (Weeks 6–7)
   • Handoff package delivered; QA and fixes supported
6. Launch Prep (Week 8)
   • Final review, content checklist, go-live support (as agreed)

Adjust to your scope, but keep milestones short enough that the client sees progress.

Common mistake

Avoid a timeline that’s just one line: “Project will take 6–8 weeks.”

Instead, show what happens in each stage and what the client approves.

5) Risks and assumptions (neutral language that protects margins)

This section reads like a contract-lite. It’s professional, not defensive.

Write risks/assumptions like a professional contract-lite

Use neutral bullets. Cover the things that commonly affect timelines and cost:

• Content readiness: “Client will provide or confirm ownership of all text, images, and brand assets by [date]. If content is delayed, timelines may shift.”
• CMS constraints: “The redesign assumes the current CMS can support the required templates/components. If not, we’ll propose an adjustment.”
• Third-party dependencies: “Integrations (forms, scheduling, CRM, email) depend on client-provided access and confirmation from third-party tools.”
• Performance expectations: “Performance will be improved using best practices and asset guidance. Final results depend on hosting and current infrastructure.”
• Approvals: “Timelines assume timely feedback (for example, 2–3 business days per review cycle).”

Common mistake

Don’t write threats like “If you don’t do X, we won’t deliver.”

Write what will happen in a calm, predictable way: scope and dates adjust through a change request.

Not sure where your freelance business stands? The Freelance Business Check is a quick way to spot weak spots before they turn into late nights or lost income.

6) Revisions and change request language (turn “small edits” into process)

Your revisions policy helps you stay sane and keeps clients from treating every request as “included.”

A clear revisions policy structure

Use a structure like:

• Review cycles: “You’ll receive up to [X] rounds of revisions per milestone.”
• What counts as revision: clarifications, layout tweaks, minor copy adjustments.
• What counts as change request: new pages, major scope changes, brand direction changes, new integrations not covered.
• Turnaround time: “Edits are scheduled within [timeframe] after feedback is received.”

Practical tip for AI-assisted proposals

Ask AI to rewrite your policy in plain language. Prompt:

“Rewrite this revisions policy in clear client-friendly English. Keep it fair, specific, and short. Use bullets and avoid legal-sounding wording.”

Then verify it matches your real process.

Related reading: Proposal Software for Freelancers: How to Choose · How to Write a Social Media Management Proposal

7) Pricing models (fixed vs phased) and how to present them

Pricing shouldn’t feel like a fight. Present it as a fit for the kind of uncertainty in the project.

Fixed-fee works best when scope is bounded

Use fixed-fee when you have:

• clear page/template list
• known CMS or clear implementation plan
• content and integrations mostly understood

Present it like:

• Fixed redesign package: “Includes discovery, audit, UX/IA for key templates, UI design for key templates, and dev handoff.”
• Exclusions: “Not included: new feature development, content writing, or major CMS changes.”

Phased pricing works best when discovery is truly unknown

If the client hasn’t decided on structure, goals, or content scope, you can reduce risk with phases:

• Phase 1: discovery + audit + UX/IA (fixed)
• Phase 2: wireframes + UI design (fixed after wireframes approval)
• Phase 3: build support/implementation (fixed or hourly)

This keeps momentum while letting scope firm up with real decisions.

How to present pricing without triggering negotiations

Avoid leaving pricing as a single “take it or leave it” number. Instead, show what they get for that price.

Use language like:

• “This price covers the deliverables listed above. If additional pages or features are needed, we’ll add them via a change request with a clear estimate.”

That signals fairness and reduces surprise.

What not to do

Don’t price by vague categories like “design work” or “development work” without describing deliverables.

Also avoid “$X for redesign” without stating what’s included and what isn’t.

Where Jolix fits (without changing your process)

If you use AI to draft faster, treat it like a starting point—not the final voice. Jolix can help you turn your notes into a clearer proposal structure (especially deliverables, milestones, and revisions language), so your proposal reads like you wrote it after thinking.

Keep your unique details: page list, your actual process, and your real revision policy.## Close with a simple next step

End with one clear call to action. Examples:

• “If this scope matches what you need, I’ll send a short kickoff form and we’ll schedule discovery.”
• “Reply with your preferred start date and I’ll share the proposal agreement and kickoff checklist.”

When your next step is simple, the project moves forward.