UI/UX designer proposals: show process without a 2,000-word case study

Design clients ask for portfolios, then complain that proposals feel generic. They want to know how you think, how you collaborate, and what they will receive at the end of week two. They do not want a pasted case study that has nothing to do with their product.

The fix is not a longer proposal. It is a visible process: named phases, tangible deliverables, decision points, and one relevant proof point. You can do that in a screen or two of text and still sound senior.

This guide is for UI/UX freelancers replying to marketplace posts, agency overflow gigs, and founder DMs. It pairs with portfolio in a freelance proposal and referencing past work without ten links.

What buyers skim in design proposals

Assume they scroll in this order:

1. First two lines: do you understand their product and constraint?
2. Deliverables: wireframes, Figma, prototype, handoff?
3. Timeline shape: how many feedback rounds, how you handle approvals
4. One proof point: similar industry, similar platform, similar problem
5. Price signal or path to quote
6. Next step

They are not reading your design philosophy essay. They are checking risk: will this person disappear into Figma and return with the wrong thing?

The compact process block (use this spine)

Insert a short “How I would approach this” section with four parts:

Discover (timeboxed): what you read, who you talk to, what you produce (audit notes, journey sketch, competitor scan).

Define: what gets agreed (personas only if relevant, success metric, scope of flows).

Design: what artifacts appear in what order (lo-fi, hi-fi, prototype level).

Deliver / handoff: files, specs, dev support, documentation.

Each phase gets one or two lines and a named output. That is your process, not adjectives.

Example process paragraph (SaaS dashboard)

I would run this in four steps over [timeline]:

1. Discover (week 1): review your current analytics views, interview one operations user and one manager, map the three tasks they do daily.
2. Define: agree on the primary dashboard job-to-be-done and what we are not redesigning yet.
3. Design: lo-fi wireframes for the main dashboard and filters, then hi-fi in your existing design system (or a light system if none exists), then a clickable prototype for the happy path.
4. Handoff: Figma dev-ready frames, a short component notes doc, and one sync with your developer to answer spacing and state questions.

That is under 120 words and more convincing than “user-centered design expert.”

Show process without dumping a case study

You do not need to paste a 2,000-word Behance story. You need one relevant mini-proof tied to their context.

Format:

• Situation (one line)
• Constraint you handled (one line)
• Outcome (metric or concrete result if you have it; otherwise ship fact)
• Link or image only if the platform allows and it is truly similar

Example:

Last quarter I redesigned a B2B scheduling dashboard where users were missing filter state. We simplified the filter bar, added saved views, and support tickets on “where did my list go” dropped in the first month after ship.

No link wall. No twelve thumbnails. One story, one mechanism, one result.

If you are early career, use process proof instead of brand names: “On a student logistics app, I ran three user interviews and changed the checkout from five steps to three; task completion in tests improved.” Honest beats inflated. See beginner proposals without case studies for more positioning help.

Match deliverables to the job post language

Clients use different words for the same work. Mirror their nouns.

They say	You propose
Wireframes	Low-fi flows, annotated
UI design	Hi-fi screens, components
Prototype	Clickable Figma, defined paths only
Design system	Tokens, components, usage notes
UX audit	Heuristic review, prioritized issues
Handoff	Specs, redlines, dev Q&A window

If they say “UI/UX” with no split, propose a sensible default sequence (flows first, UI second) and mention what happens if they only want cosmetics.

Example proposal: mobile app redesign (medium length)

Hi [Name],

You need the existing [app] checkout and account area to feel modern without breaking dev capacity. I focus on product UI/UX for [industry] apps, and I would approach your scope like this:

Scope I understand: checkout, profile, and order history screens; you already have a React Native codebase and brand colors.

Process

• Week 1, discover: audit current screens (you share TestFlight build), note drop-off points from your analytics if available, align on “must not change” backend rules.
• Week 2, flows: lo-fi wireframes for the three areas, one review call, one consolidated feedback round.
• Weeks 3-4, UI: hi-fi frames per agreed flows, components documented for dev, prototype for checkout happy path only.
• Week 5, handoff: dev-ready Figma, export notes, 60-minute handoff call with your engineer.

Proof: I shipped a similar checkout simplification for a [niche] subscription app (fewer steps, clearer error states). Happy to share one before/after screen in chat.

Not included unless we add it: illustration packs, new brand identity, user research recruiting, or QA after dev build.

Price: fixed milestone plan after a 90-minute kickoff ([fee] credited toward project if we proceed). If you already have a budget range, share it and I will map tiers.

Next step: confirm whether you want wireframes only or full UI, and send the current build link.

This hits outcome, process, proof, boundaries, and action.

Example proposal: UX audit only (short post)

Hi [Name],

For a UX audit of [site/app], I would deliver a written report and a prioritized backlog, not a full redesign in week one.

Included

• Heuristic review on the flows you name ([checkout, onboarding, etc.])
• 10-15 minute async walkthrough if you can record the session
• Severity-tagged issue list (blocker / major / minor)
• Quick wins you can ship without a full redesign

Timeline: [X] business days after access.

Follow-on: if you want UI concepts for the top three issues, we scope that as a second fixed phase.

Audits are easy to underprice. State what is not infinite (number of flows, one feedback call).

Revisions, stakeholders, and design-by-committee

Design proposals should cap feedback loops:

• One consolidated comment round per phase (not endless Slack pings).
• Stakeholder list: who approves, who advises.
• What happens if feedback conflicts (you facilitate one decision call or they pick a lead).

Phrase it calmly:

To keep timeline intact, feedback is batched per phase. I include one revision round on wireframes and one on hi-fi; additional exploration is scoped separately.

That is not rigid. It is how you avoid twelve parallel opinions.

Tools and collaboration (brief, not a sales pitch)

Name the tools you will use (Figma usual). Mention how you share work (link, comments, Loom only if you actually do short walkthroughs). Do not list every plugin you own.

If the client names a stack (Webflow, existing Bootstrap site), say how you adapt: design in Figma for dev, or design directly in Webflow if that is the deliverable.

Pricing design work without vague “depends”

Design posts are often vague. Use ranges tied to artifacts:

Based on three flows and roughly [N] screens, similar projects land around [range] assuming your team provides copy and stock assets. If you need net-new research or a full design system, I would price that as phase one.

Offer a paid discovery kickoff if the scope is mushy. It filters serious clients and gives you real numbers for a fixed quote.

For fixed deliverables (logo-adjacent product UI, landing page only), borrow clarity from fixed-price project proposal pricing.

Mistakes designers make in proposals

Leading with tools and awards. Figma mastery is assumed. Lead with their user problem.

Attaching a PDF portfolio without context. One link, one sentence on why it matters. See attach-vs-link guidance elsewhere on the blog if you debate PDFs.

Promising unlimited concepts. State how many directions you explore (usually one primary direction with controlled variations).

Skipping dev handoff. Developers are stakeholders. Mention handoff and support window.

Writing like a marketing agency. Founders want a person. Use “I” and concrete verbs.

No next step. End with: confirm scope tier, share access, or book kickoff.

When to shorten vs lengthen

Shorter proposals work when the post is small, the client is repeat, or the platform caps length. Show process in four bullets and one proof line.

Longer proposals help when there are multiple stakeholders, regulated industries, or RFP-style lists. Still avoid case study dumps. Use headings and tables only if they clarify decisions.

If fifty designers already applied, differentiation is specificity, not length. See competitive-post guidance on the blog; the core move is the same: quote their words back with a plan.

Checklist before you send

• Opening sentence states their user outcome and constraint.
• Process has named phases and tangible outputs.
• One proof point matches their context (not a random award).
• Revisions and approvals are bounded.
• Exclusions are listed with examples.
• Price is a range, tier, or paid discovery path.
• Next step is singular and clear.
• No em dashes; no fenced code blocks for proposal text.

Run the proposal checklist and compare tone to freelance proposal examples if you want a second pattern. Design hires go to the freelancer who makes week two feel predictable, not the one with the longest portfolio story.