Why Most Case Studies Read Like Project Logs (and Fail)

  • Here's the honest reason most case studies get ignored.
  • The designer wrote about what they did not what they decided.
  • There's a meaningful difference. A project log says: "First I did research.
  • Then I made wireframes. Then I built the UI in Figma. Then I presented it to the client."

A case study says : "The research revealed a drop-off problem at step 3 of the onboarding flow. I had two options: simplify the form or add progressive disclosure. I chose progressive disclosure because the data showed users weren't abandoning out of impatience they were abandoning because the
form felt high-stakes before they understood the product's value."

One of those sentences makes a recruiter lean in. The other makes them scroll past.

The failure mode is chronological narration. Most designers write a case study the same way they experienced the project start to finish, step by step. That's natural. It's also wrong. Recruiters don't need to experience your project in real time. They need to understand your thinking
in the fastest possible way.

Structure is the fix. And the structure has seven parts.

The Structure That Works

In short: Problem → Goal → Role → Decisions → Screens → Outcome → Learnings. Every section earns its place. Every section can be cut if it doesn't add signal.

1. Problem

What was broken? Who was affected? Why did it matter?
One sharp paragraph. Not a company history. Not a brief summary of the client's business. The problem. Specific and real.

2. Goal

What were you trying to achieve?
One measurable or directional goal. "Improve the onboarding flow" is not a goal. "Reduce drop-off at step 3 by making the value proposition
visible before the commitment ask" is a goal.

3. Role

What did you specifically do?
This matters more when you worked in a team. Hiring managers need to know what you are responsible for — not what the team produced. One sentence is enough: "I led the UX research and information architecture. A visual designer handled the final UI."

4. Decisions

This is the most important section and the most underdeveloped in most portfolios.

Don't list everything you did. List the 3 decisions that shaped the outcome, and for each one:

  • What were your options?
  • What did you choose?
  • Why?
  • What did you give up?

That last question the trade-off is where design maturity lives.

5. Screens

Show the work. Clean Figma prototype link. Before and after where relevant. Annotated screens for complex interactions. 4–6 screens is enough for most case studies. More than 10 is almost always too many.

6. Outcome

What happened? What did you test? What would you measure?
Shipped metrics if you have them. Usability test findings if you don't. A stated hypothesis if you have neither. (More on this below.)

7. Learnings

What would you do differently?
One honest paragraph. This is what separates a junior designer who thinks from one who just executes.

How to Write a Problem Statement That Doesn't Sound Generic

The most common problem statement in junior portfolios:

"I redesigned the app to improve the user experience and make it more intuitive."

That sentence says nothing. Every redesign is supposed to improve the
user experience. "More intuitive" means whatever the reader wants it to mean.

A strong problem statement has three components:

  1. A specific user behaviour or failure point
  2. The consequence of that failure (for the user or the business)
  3. Why solving it mattered at this moment

Here's the formula :

"[User type] couldn't [specific task] because [specific barrier],
which resulted in [measurable or observable consequence].
[Why this was the right time to fix it]."

Applied :

Weak: "The dashboard was confusing and users didn't know what to do."

Strong : "New users on the SaaS platform's dashboard couldn't identify their next action within the first session because the interface surfaced all features simultaneously with no hierarchy. Onboarding completion dropped to 34% in the first week. The team had tried tooltips and hadn't moved the metric."

The second version gives a hiring manager something to evaluate your solution against. The first gives them nothing.

Showing Process Without Boring the Reader: The 3-Artifact Rule

Here's the truth about process documentation in a portfolio case study :
nobody wants to read about your entire process. They want to see that you had a process.

The 3-Artifact Rule : 

Show exactly three types of process artifacts.
No more is needed to prove rigour. Fewer leaves you looking like you jumped straight to Figma.

Artifact 1 : A Research Output
One user insight, a pattern from interviews, a heuristic evaluation
screenshot, or an affinity map. Just one. It proves you started with
understanding, not assumption.

Artifact 2 : An Early-Stage Wireframe
A rough wireframe especially one that shows a discarded idea is
worth more than a polished screen. It proves you explored before you
executed. A phone photo of a paper sketch counts.

Artifact 3 : An Iteration Comparison
Before and after on a specific component or flow, with one sentence explaining what changed and why. This proves you responded to feedback or testing the most important skill in any product team.

That's it. Three artifacts. Research → Early exploration → Iteration.
It tells the full story of how a designer thinks without becoming a
documentary.


Writing About Outcomes When You Have No Metrics

This question comes up in every ProdXVerse cohort. Almost always from someone who built a strong self-initiated project and then felt stuck trying to write an outcome section that didn't feel like a lie.

The answer is : you have more outcome material than you think.

Three approaches that work, in order of strength:

Approach 1 : Usability Test Findings

Run a 5-person moderated test on your Figma prototype. It takes one afternoon. Record what users did and said.

"4 out of 5 users completed the onboarding flow without prompting.
User 2 paused at the pricing step which led me to add a value
comparison component before the payment screen in V2."

That's a real, credible, specific outcome. No live product required.

Approach 2 : Stated Hypothesis

"If deployed, the primary metric I'd track is task completion rate at step 3, targeting an improvement from the current 34% to above 60%. Secondary: time-to-first-value under 4 minutes. The usability test results suggest both are achievable."

An intelligent hypothesis signals the same thinking as a real metric because it proves you know what matters. Hiring managers know juniors don't have shipped data. They're testing whether you know what to measure, not whether you measured it.

Approach 3: Heuristic Comparison

"Evaluated against Nielsen's 10 usability heuristics, the original
flow scored poorly on 'recognition over recall' (users had to remember steps from a previous screen) and 'error prevention' (no confirmation before a destructive action). Both are addressed in the redesign.
Here's the annotated comparison."

Never write: "The redesign would significantly improve user
satisfaction and increase conversions."

That's a wish, not an outcome. Specific is credible. Vague is invisible.

The Headline Formula

Every case study needs a headline. Most case study headlines look like this:

  • "Redesigning the Onboarding Flow"
  • "UX Case Study FinTech App"
  • "Project 2 Dashboard Redesign"

None of those make a recruiter want to open the case study. They're
project titles, not case study headlines.

The formula that works:

"I designed [specific thing] for [specific user type] that [specific outcome or goal]."

Examples :

  • "I redesigned the onboarding flow for a B2B SaaS accounting tool
    to reduce drop-off at the payment step — from 58% to a testable prototype
    that 4 out of 5 users completed without help."
  • "I designed a zero-to-one mobile dashboard for SME logistics operators
    who couldn't track deliveries without calling their drivers."
  • "I redesigned the empty state experience for a project management tool
    where 61% of new users churned in week one without ever creating their
    first project."

Each of those tells you: who it's for, what problem existed, and what the designer did about it. That's three reasons to keep reading before the recruiter has seen a single screen.

Before/After Case Study Rewrite: A Real Example

This is a condensed version of an actual case study rewrite done inside a ProdXVerse cohort. The designer had strong visual skills and a weak
narrative. Here's what changed.

❌ BEFORE (What they originally wrote)

Title: UX Case Study — Food Delivery App

"For this project, I was tasked with redesigning a food delivery app. I started with user research by interviewing some users. Then I created wireframes to map out the flow. After a few iterations, I moved into high-fidelity designs in Figma. The final design is cleaner and more modern, with a better user experience. I learned a lot about the design process during this project."

What's wrong :

  • No specific problem stated
  • "Some users" how many? What did they say?
  • "Cleaner and more modern" means nothing
  • "Better user experience" not an outcome, it's a hope
  • Zero decisions documented
  • Zero trade-offs mentioned
  • "I learned a lot" tells the reader nothing

✅ AFTER (Restructured version)

Title: I redesigned the reorder flow for a food delivery app where
62% of returning users abandoned their cart before checkout

Problem: Returning users on the app had a higher cart abandonment rate than new users counterintuitive, and traced through session recordings to the reorder flow. Regular users couldn't quickly access previous orders without navigating through 4 screens.

Goal : Reduce cart abandonment for returning users by surfacing
recent orders in one tap from the home screen.

Key decision : Two options a dedicated "Reorder" tab (high
discoverability, high nav weight) or a contextual "Order again" module on the home screen (lower discoverability, lower friction for power users). I chose the contextual module because the research showed 80% of returning users ordered from the same 2–3 restaurants. The module surfaces those by default. A tab would have served edge cases at the expense of the
majority use case.

Outcome : Usability test with 6 users all 6 completed a reorder
in under 2 taps. 0 users navigated to the search bar first (the old
failure pattern). If shipped, I'd track returning user cart completion
rate in the first 30 days.

Learning : I initially designed a search-first flow before the
research revealed it was the wrong problem. The pattern that looked like a search failure was actually a navigation failure. Talking to users earlier would have saved one full round of wireframes.

The same project. Completely different signal.

How Long Should a Case Study Be?

The answer : 600–900 words plus visuals. Almost every case study that's too long is too long for the same reason it documents everything instead of curating the meaningful parts.

The right length per section :

  • Problem statement: 2–3 sentences
  • Goal: 1–2 sentences
  • Role: 1 sentence
  • Decisions (3 total): 3–4 sentences each
  • Screens: 4–6 images with captions
  • Outcome: 3–5 sentences
  • Learnings: 1 paragraph (4–6 sentences max)

What to cut ruthlessly :

  • Company background (the recruiter doesn't need a business overview)
  • Every wireframe iteration (show the most meaningful one)
  • Methodological descriptions ("I used affinity mapping to...") without
    the actual output
  • Anything you included because it made the process look thorough rather
    than because it advances the story

A 2,500-word case study that covers every step is worse than a 750-word case study that explains three great decisions. This is the hardest lesson for thorough, process-oriented designers — but the data from recruiter behaviour is clear. Shorter, sharper, and decision-focused wins every time.

FAQ

Q: What is the ideal structure for a UI/UX case study?

A: The structure that consistently generates callbacks is: Problem → Goal → Role → Key Decisions → Screens → Outcome → Learnings. The most important section is Decisions — specifically, what options you had, what you chose, and what you traded away. That's where design thinking becomes visible to a hiring manager. Most case studies skip this and jump from research directly to final screens.

Q: How long should a UX portfolio case study be?

A: 600–900 words plus 4–6 supporting visuals is the target range. Most case studies are too long, not too short. Recruiters at product companies and SaaS startups report scanning portfolio case studies rather than reading them linearly. A shorter, sharper case study with clear section headers and annotated screens will hold attention longer than a comprehensive project report.

Q: How do I write outcomes for a UX case study if I've never shipped a product?

A: Three approaches work: usability test findings from a 5-person test on your prototype, a stated measurement hypothesis (what you would track and what improvement you'd target), or a heuristic comparison showing before-and-after against Nielsen's principles. Never write vague outcome sentences like "the design would improve user satisfaction." Specific, testable, and honest always outperforms optimistic and vague.

Q: What makes a good case study headline?

A: The formula that works: "I designed [specific thing] for [specific user type] that [specific outcome or goal]." Strong headlines name the user, the problem, and the result before the recruiter reads a single word of the case study. Avoid project-title-style headlines like "Dashboard Redesign" or "Case Study 2" — they give the reader no reason to click.

Q: How many case studies should a junior UI/UX portfolio have?

A: Three is the target. One is too thin to show range. Five usually
means five shallow projects. Three well-structured case studies
covering different problem types a SaaS redesign, an end-to-end product concept, and a design system or component-focused project gives a hiring manager enough signal to make a decision. Every case study should have a documented process, a specific problem statement, and at least one clearly explained design decision.