Don't open with "We were hired to redesign X." Nobody cares that you got hired. Open with what was actually going wrong.

Fictional example: The following Cronizen example, including the client name, scenario, quote, and metrics, is fictional and is intended only to demonstrate how a case study opening can be written. Replace it with verified information from an approved project before publishing.

Weak opening: "Cronizen partnered with us to redesign their ad dashboard."

Stronger opening: "Cronizen's clients were abandoning their dashboard within the first two minutes. Support tickets were piling up, and the sales team had started apologizing for the product before demos even began."

The stronger version works because it immediately establishes the problem and why it mattered. But in a real case study, every detail should come from evidence, research, or an approved client source.

To find this opening, ask:

• What was a normal Tuesday like for this team before you showed up?
• What were they frustrated about that they hadn't said out loud yet?
• What number captures the scale of the problem? ("1 in 3 sign-ups never made it past screen two" beats "users were confused.")

Every good story has someone the reader roots for—usually the client's team, their users, or both. "The ops team" is vague. "A five-person ops team manually reconciling data every Friday night" is a person you can picture.

A few ways to make the stakes real:

• Use a real quote, woven into the setup rather than bolted on as a testimonial at the end.
• Name what they stood to lose, trust, time, a competitive edge, a renewal.
• Credit your own team briefly, who was involved, and what they brought to it.

Don't create a dramatic quote or situation simply because it makes the story stronger. If the client didn't say it, don't put it in quotation marks. If the situation didn't happen, don't present it as part of the project.

NN/G's piece on UX stories makes a similar point: a compelling story needs a clear main character the audience can empathize with, along with that character's goal and motivation.

This is the part most case studies rush through, and it's the part readers actually trust the most. Most projects have a messier middle than the final screenshots suggest.

Common places tension shows up:

• A design direction that tested badly with real users.
• A deadline that got cut in half mid-project.
• A disagreement between the client's instinct and your research.
• A technical constraint that forced a simpler path than planned.

But the tension needs to be real.

Don't manufacture obstacles, invent numbers, or exaggerate disagreements to make a case study feel more dramatic. If a project went smoothly, that's okay. You can still explain the decisions, trade-offs, constraints, and insights that shaped the work.

Naming this friction makes the outcome feel earned instead of lucky. Two or three honest sentences are usually enough; you're not writing a confession, and readers can tell manufactured drama from a real obstacle.

Circle back to where you started. Pair each number with the moment it fixes, rather than listing metrics on their own:

• Instead of: "Increased engagement by 40%"
• Try: "Average session time went from under two minutes to over eight minutes; clients were finally exploring the data instead of bouncing off it."

A few rules of thumb for this section:

• Show before-and-after side by side where you can (a split screenshot, a simple chart).
• Stick to three well-chosen metrics rather than ten that need explaining.
• Tie every number back to the problem from step one.

Harvard Business School's guide on data storytelling makes the same point about curating the data for the story, rather than passing along every number you have.

A strong case study doesn't end when the metrics go up. The most meaningful change is often harder to quantify.

Maybe the support team stopped answering the same questions every day. Maybe designers stopped patching the same usability issues. Maybe the client finally felt confident enough to show the product to larger customers.

These details give the results some human weight, but they should still be based on what actually happened.

Instead of:

"Support tickets decreased by 32%."

Try:

"With the new workflow in place, the support team stopped spending Monday mornings explaining the same three tasks to new users. Support tickets for those issues dropped by 32%."

The number matters, but the change behind the number is what makes it memorable.

And if multiple factors contributed to the improvement, say so. Being transparent about what you can and can't attribute to your work makes the case study more trustworthy.

You don't need to turn every case study into a 3,000-word narrative. A strong story can follow a simple structure:

• The Problem: What was happening, and why did it matter?
• The Stakes: Who was affected, and what did they stand to lose?
• The Tension: What made solving the problem difficult?
• The Turning Point: What insight changed your approach?
• The Solution: What did you actually change, and why?
• The Results: What improved, and how did those improvements solve the original problem?
• The Lesson: What should the reader take away from the experience?

Think of these as seven beats rather than seven mandatory sections—some can be combined, while others may deserve more space. The goal isn't to make every project sound dramatic, but to help the reader understand why the work mattered, how you approached the problem, and what changed because of it.

The case study is proof of how you think

Your portfolio doesn't need another gallery of polished screens. A screenshot can show what you designed, but a case study should explain why you designed it that way. That's the difference between simply documenting a project and telling its story. By the end, readers should understand the problem you faced, the decisions you made, the challenges you overcame, and the thinking behind your solution—because that's what potential clients, hiring managers, and stakeholders are really evaluating.

Not just:

"Can you make something look good?"

But:

"Can you walk into a messy problem, make sense of it, make smart decisions, and create an outcome that matters?"

That's the story your case study should tell.

A great case study is more than a collection of screenshots and statistics. It's a story about a problem, the people affected by it, the challenges along the way, and the change your work created.

Show the problem. Build the tension. Reveal the insight. Prove the impact.

But don't manufacture the story. Get permission to share client information, anonymize confidential details when necessary, use only verified quotes and numbers, explain how impact was measured, and be honest about the other factors that may have contributed to the outcome.

When you tell the story behind the work, not just the work itself, you create case studies that people remember, trust, and want to talk about.