Freelance UI Proposal Template: What to Include (and Cut)

A UI/UX proposal is not a brand manifesto. It is a decision document: scope, artifacts, timeline dependencies, money, and how feedback works. Soft language loses you weeks. Fake ROI claims damage trust. This template structure is what solo designers can send after one solid discovery call.

Use it as a Markdown/Notion doc or export to PDF. Pair it with a one-page SOW when they say yes.

What a strong UI proposal must decide

Before aesthetics, the document should answer:

1. What problem are we addressing (without locking a premature UI solution)?
2. What artifacts will exist in Figma when we are done?
3. Which flows/screens are in — and what is explicitly out?
4. How many critique rounds are included, and what counts as a round?
5. What depends on the client (assets, feedback SLA, decision owner)?
6. What it costs, when money moves, and what happens if scope changes?

If any of those are fuzzy, you do not have a proposal. You have a mood board with a price.

Recommended section order

1. Context (short)

Restate their words, then your understanding:

• Users
• Primary job-to-be-done
• Business goal
• Constraints (platform, brand, tech, compliance, deadline)

Keep it under half a page. They should nod, not discover a new strategy deck.

2. Goal of this engagement

List 2–4 outcomes in deliverable language:

• “Redesigned checkout: cart → confirmation, desktop + mobile, including empty/error states”
• not “Improve conversion and delight users”

Add non-goals. Non-goals prevent the “while you’re in Figma…” spiral.

3. Approach (phases)

A phase table beats paragraphs:

Name critique rounds numerically. Define a round: consolidated feedback from one decision owner within N business days, applied once.

4. Deliverables (checkbox-friendly)

Be acceptance-friendly:

• Flows named
• Screen list or clear boundary (“marketing site: Home, Pricing, Docs hub”)
• States: default, loading, empty, error, success (as relevant)
• Breakpoints
• Handoff notes
• Prototype only if you are selling one

State what you will not deliver unless purchased: full design system, illustration set, motion system, copywriting, implementation.

5. Timeline with dependencies

Every milestone needs a client dependency. Feedback late by five days moves handoff by five days. Write that down. Designers who omit it absorb political delay for free.

6. Investment

Show package fee, optional add-ons, deposit percentage, balance trigger, payment methods, Net terms.

For change orders: hourly rate or “fixed quote per change.”

Do not invent ROI percentages. Explain value as risk reduction and clarity of artifacts — outcomes you can own as a designer.

7. Assumptions

Examples that save you:

• One decision owner consolidates feedback
• Brand assets arrive in week one
• Eng implements; you design
• Legal copy is client-owned

8. Next step

Decide-by date. Accept path: sign SOW + deposit → kickoff date. Calm CTA. No countdown gimmicks.

Sample outline you can copy

# Proposal: [Project]
Prepared for / by / date / valid until

## Context
## Goal + non-goals
## Approach (phase table)
## Deliverables
## Timeline (with dependencies)
## Investment + payment schedule
## Assumptions
## Next step

Fill brackets from discovery notes the same day as the call while details are fresh.

Pricing presentation without sleaze

Good: “Fixed fee covers the flows listed. Extra flows are a change order.”
Bad: “This will 10x your revenue.”

Good: three options only when scope truly differs (Audit vs Redesign Phase 1 vs Phase 1+2).
Bad: fake good/better/best where “better” is the only honest scope.

If they negotiate price, negotiate scope or timeline, not your dignity. Prepare three replies: reduce Phase 1, keep scope at fee, or split phases.

Critique and revisions — say it in the proposal

Unlimited revisions are how fixed-fee projects go negative. Put the number in the proposal and the SOW. Spell out that contradictory multi-stakeholder comments must be consolidated. Offer a structured critique format (severity + screen + requested change).

This is not rigid for its own sake. It is how you protect quality: endless micro-nits destroy hierarchy and consistency.

Proposal email (keep short)

Subject: Proposal — [Project] — decide by [date]

Body:

• Thanks for discovery
• Attached/linked proposal covering scope, timeline, fee
• Happy to clarify
• Next step SOW + deposit to hold [start date]

Save personality for the relationship. The email’s job is clarity.

Common mistakes

1. Page-count flex — 14 pages of philosophy, two sentences of deliverables.
2. Deliverables as vibes — “modern UI,” “improved UX.”
3. No lost-reason learning — when deals die, note Budget / Timing / Scope in your pipeline.
4. Sending before discovery — you will under-scope political complexity.
5. Proposal = contract — use a SOW for signatures and IP/payment terms.

After they say yes

1. Send one-page SOW
2. Collect deposit
3. Share onboarding questionnaire
4. Create Project in Notion: Phase Kickoff, link Deal + Client, paste Figma URL
5. Book kickoff with decision owner present

A proposal template only works inside a rail: CRM → Pipeline → Project. Otherwise the PDF wins and the process still lives in your head.

Grab-and-go

If you want a filled Markdown proposal plus matching SOW, onboarding questionnaire, and invoice checklist aimed at freelance UI/UX, packs like Clientrail include those templates beside a Notion OS structure. Either way, hold the standard: specific artifacts, numbered critique rounds, explicit non-goals, dependency-aware timeline.

Ship the proposal within 48 hours of discovery while the problem is still shared language — not after a week of over-designing the deck.