UX Case Study Examples That Show How You Think
Heads up: All five examples are example portfolios built with Folioverse (fictional projects, clearly labeled). Metrics in the redesign examples are illustrative sample figures from those fictional projects, not real product results.
Most ux case study examples look polished at first glance. The problem is that hiring reviewers are not only scanning for beautiful screens. They are trying to understand how you framed the problem, made decisions, handled constraints, and stayed honest about results.
This page collects five UX case study examples through that lens — not “copy this layout,” but “notice what this designer proves.” Each one is an example portfolio built with Folioverse, based on a fictional but realistic project.
Use each example to study three things:
- what the designer was responsible for
- how they made decisions when the answer was not obvious
- what a recruiter can understand in the first 30 seconds
How to read these UX case study examples
A strong case study is not a project diary. It is a guided explanation of your thinking.
A weak case study says:
“I conducted research, created wireframes, and improved the user experience.”
A stronger version says:
“I noticed users were abandoning the transfer flow at the confirmation step, and support kept getting ‘I sent money to the wrong person’ tickets. The real issue was not speed — it was that nothing let people verify the recipient before sending.”
The second version shows judgment. It gives the reviewer something to evaluate. That is the goal of the examples below.
Recruiter 30-second scan: “Can I quickly see the problem, the designer’s role, the decisions they made, and why those decisions were reasonable?” If the answer is unclear, the case may look complete but still feel weak.
Example 1 — Fintech transfer redesign (Pilo)
Best for studying: designing for trust and the scary edge case Type: mobile redesign · Read the full teardown →
Pilo is a fictional neobank. The designer redesigned the Send Money flow because users were dropping off at confirmation and support saw repeated wrong-recipient, wrong-amount tickets.
Weak version:
“I redesigned the transfer flow to make it easier to use.”
Strong version:
“I added a non-skippable review screen — even though it adds a tap — because the support-ticket data showed the real cost was wrong sends, not slow sends. I chose trust over raw speed and defended it with evidence.”
What this proves:
- the designer optimized for the right metric, not the obvious one
- a deliberate trade-off (an extra tap) was justified with data
- designing for the scary edge case improved the everyday path too
Example 2 — E-commerce PDP redesign (Marlo)
Best for studying: decision hierarchy and prioritization Type: e-commerce redesign · Read the full teardown →
Marlo is a fictional home and lifestyle store. The product detail page had high bounce and low add-to-cart because it buried the four things shoppers decide on: photos, variants, delivery, and reviews.
Weak version:
“I made the product page cleaner and more modern.”
Strong version:
“I rebuilt the page around one hierarchy — see it, choose it, trust it, buy it — because research showed conversion was a confidence problem, not a button-color problem.”
What this proves:
- the designer turned scattered findings into a single organizing principle
- visual changes followed from a decision model, not taste
- mobile constraints (a sticky buy action) were treated as part of the thinking
Example 3 — Event website redesign (Frame)
Best for studying: connecting a funnel problem to specific design moves Type: website redesign · Read the full teardown →
Frame is a fictional design festival. The old site got traffic but converted poorly to tickets: the schedule was a downloadable PDF, the lineup felt thin, and mobile checkout dropped at payment.
Weak version:
“I redesigned the festival website to improve the experience.”
Strong version:
“I treated the website as the box office, not a brochure. Each fix mapped to a funnel blocker: an interactive schedule replaced the PDF, a speaker-forward lineup added credibility, and a two-step mobile checkout cut payment drop-off.”
What this proves:
- every design move traced back to a measured funnel problem
- the designer framed the project around a clear point of view
- scope stayed tight across three connected pages
Example 4 — 0-to-1 pet-care app (Nuzzle)
Best for studying: product thinking and honest results without metrics Type: 0-to-1 / new product · Read the full teardown →
Nuzzle is a fictional, self-initiated concept that guides first-time pet owners through the overwhelming first 90 days. There was no shipped product, so there were no production numbers — and the case study does not pretend otherwise.
Weak version:
“The app increased user confidence and engagement.”
Strong version:
“This is a concept, so I have no production metrics. I validated direction with a prototype test on six new owners: comprehension was clear and self-rated confidence rose. I’m careful not to claim numbers it doesn’t have.”
What this proves:
- the designer is honest about the evidence that exists
- restraint and tone were treated as design decisions, not copy
- a 0-to-1 project can be credible without inventing impact
Example 5 — B2B logistics dashboard (Freightline)
Best for studying: systems thinking and enterprise constraints Type: B2B / enterprise · Read the full teardown →
Freightline is a fictional logistics operations platform. Its legacy dashboard showed everything with equal weight, so ops managers found out a shipment was late when the customer called.
Weak version:
“I redesigned the dashboard to be cleaner and easier to use.”
Strong version:
“The core decision wasn’t a screen — it was a system: one shared language for risk (OK / At-risk / Breach) applied consistently across the product, plus an exception-first layout that surfaces what needs action now.”
What this proves:
- the designer solved at the system level, not the screen level
- they understood that a “simple” status change touches several teams
- results are framed honestly as a limited pilot, not a platform-wide win
What junior UX case study examples usually get wrong
Junior portfolios often fail for the same reason: they show activities instead of decisions.
A list of activities is easy to write — interviews, personas, wireframes, usability testing, UI. But a hiring reviewer needs to know what those activities revealed.
Weak version:
“I created three personas to understand the users.”
Strong version:
“The personas mattered less than the task patterns. Two user groups had different motivations but failed at the same decision point, so I focused the case study on that shared breakdown.”
The second version shows prioritization. That is what separates strong UX case study examples from polished ones.
A simple review framework for every example
When you study any UX case study example, score it against four questions.
- Is the problem specific? “Users needed a better experience” is weak. “Users understood the product but couldn’t tell which option fit their situation” is strong.
- Is the designer’s role clear? Separate what you owned, what you collaborated on, and what someone else handled.
- Are decisions explained? Show the alternative you considered and why you chose what you did.
- Is the outcome honest? If there are no production metrics, say so — and explain what you evaluated instead.
Use examples, but do not copy their surface
A good example helps you structure your own case study. A bad use of examples makes your portfolio sound generic. Do not copy section titles, visual rhythm, or — worst of all — metrics from someone else’s project. Copy the underlying logic instead: What was the problem? What was your role? What did you try first? What changed your mind? What did you decide? What evidence supports it? What evidence is missing?
For a full walkthrough, use the UX case study guide. If you are starting without a client project, read how to write a UX case study with no experience. Before publishing, run through the UX case study checklist.