Examples
UX case study examples that read like judgment, not a process diagram
Four worked examples with the structure exposed: the problem in business terms, the research method, the decisions and their trade-offs, and one number that moved.
Illustrative examples written to show structure. They are not client work.
Onboarding redesign, B2B SaaS
Cut first-week drop-off from 61% to 38% by removing three setup steps
Problem
New accounts had to connect data, invite a teammate and name a workspace before seeing anything useful. Most left at step two.
Research
12 session recordings, 6 interviews with churned trials, funnel analysis by step.
Decisions
- Moved data connection after the first dashboard view
- Made teammate invites optional and asked again on day 3
- Pre-filled workspace name from the signup email domain
First-week drop-off: 61% to 38% over 6 weeks
“We had argued about onboarding for a year. Seeing six churned users hit the same wall ended the argument in one meeting.”
Checkout flow, e-commerce
Recovered 14% of abandoned carts by fixing one error state
Problem
Card errors returned a generic failure and cleared the form. Support tickets described it as 'the site rejected me'.
Research
Support ticket tagging over 90 days, 8 usability tests on mobile, error-log review.
Decisions
- Kept form values on failure and named the actual reason
- Surfaced an alternative payment method inline
- Added a saved-cart email triggered only after a real error
Recovered carts: +14% within one quarter
“It was not a redesign. It was a paragraph of copy and not wiping the form, and it paid for the whole engagement.”
Design system, 30-person product team
Took new-component build time from 5 days to 1.5 days
Problem
Four squads maintained parallel button, table and modal variants. QA caught the same accessibility issues repeatedly.
Research
Component audit across 3 codebases, 9 developer interviews, contribution-friction mapping.
Decisions
- Consolidated 27 variants into 9 documented primitives
- Wrote the contribution path before writing more components
- Built accessibility checks into the component tests, not review
New component build time: 5 days to 1.5 days
“The audit was uncomfortable to read and it was the only reason leadership funded the work.”
Mobile app accessibility, public sector
Passed WCAG 2.1 AA audit on the second pass instead of the fifth
Problem
Contrast and focus-order failures were being caught in external audits, months after release.
Research
Screen reader testing with 5 users, automated contrast sweep, audit history review.
Decisions
- Replaced the palette with a contrast-tested token set
- Fixed focus order in the three highest-traffic flows first
- Added an accessibility checklist to the design handoff
Audit passes: 5th pass to 2nd pass; 41 issues closed pre-release
“We stopped treating accessibility as a bug category and started treating it as a design input.”
The structure underneath all four
- 1Headline with the measurable outcome, not the project name
- 2Problem, framed as what it cost the business or the user
- 3Research, listed as method plus sample size so it can be trusted
- 4Decisions, three at most, each with the trade-off you accepted
- 5Outcome, one number with a time frame
- 6A verbatim line from a stakeholder or a user
Working from a client's own words instead of a blank page? Read the writing guide.
Questions designers ask
Your last client already wrote half of your next case study
Send one link, get their problem, decisions and numbers back in a structure you can publish.
Get the 5-day Proof Playbook
A few useful emails, no spam. Unsubscribe anytime. See our privacy policy.