Portfolio Development
A case study is not a diary of every design activity. It is a clear account of the problem, the evidence, the decisions you owned, and what happened next.
Many case studies are process archives. They show sticky notes, wireframes, prototypes, and polished screens in chronological order. The reader can see that work happened, but not what the designer noticed, decided, or changed.
A useful case study answers five questions without making the reader hunt for them:
Describe the situation for the people using the product, not just the task on your project brief.
Separate your contribution from the work of the team, client, researcher, writer, or engineer.
Show the observation, constraint, data, or feedback that changed a decision.
Explain the alternatives and tradeoffs behind the important choices.
State what shipped, what was tested, what was learned, and what remains unknown.
If someone can describe your process but cannot describe one decision you made, the case study is documenting activity instead of demonstrating judgment.
This emphasis is consistent with the Nielsen Norman Group UX Careers report, where hiring participants repeatedly asked for clear thought process, logical reasoning, and evidence behind design decisions.
These sections are a framework, not a required page template. A small project may need a paragraph for one section. A complex project may need several. Keep the order clear, then give the most space to the decisions that best represent your work.
Give the reader the whole project in one useful sentence.
Include
What changed, who it was for, and why the project mattered.
Leave out
A vague title like “Mobile app redesign.”
Make your ownership and constraints clear before the story starts.
Include
Your role, team, timeline, project status, and the parts you personally owned.
Leave out
Using “we” for everything or implying you did the entire project alone.
Explain the real tension, not merely the assignment you received.
Include
The user need, business need, known constraints, and what was still uncertain.
Leave out
Treating a stakeholder request as proof that the problem existed.
Show what changed your understanding of the problem.
Include
The strongest observations, data, feedback, or existing product evidence.
Leave out
Listing every research activity without explaining what it taught you.
Connect the evidence to the choices visible in the final work.
Include
Two or three consequential decisions, alternatives considered, and tradeoffs accepted.
Leave out
A gallery of polished screens with no explanation of why they look or work that way.
Say what happened and how certain you are about it.
Include
Shipped status, measured results, observed behavior, feedback, adoption, or the honest lack of follow-up data.
Leave out
Invented percentages, unattributed praise, or claiming a design caused a business result you cannot isolate.
Show what you understand now that you could not know at the start.
Include
What you would repeat, change, test next, or handle differently with more time.
Leave out
A generic “I learned communication is important” ending.
Start with the story in plain text before designing the page. If the outline is unclear, more mockups will not fix it.
The Case Study Builder turns this outline into a guided draft with a live preview. You can write section by section and move the result into your own portfolio.
A case study needs an honest ending, not necessarily a dramatic number. Use the strongest evidence you have and name its limits.
A documented product, business, or accessibility measure changed after launch. Explain the source, timeframe, and your confidence in the connection.
A usability session, support pattern, or product event showed people behaving differently. Say what was observed and in what context.
Customers, teammates, or stakeholders gave relevant feedback. Attribute it accurately and do not turn one comment into a universal result.
The work shipped, was adopted by a team, became a reusable pattern, or resolved a decision. That is a real outcome when stated plainly.
The project ended before launch or follow-up data was unavailable. Say so, then explain what you would measure next.
Remove participant names, faces, contact information, private research notes, and sensitive client or product data unless you have informed permission to share them. An NDA is not the only privacy boundary that applies to portfolio work.
For more examples, use the guide to writing case studies without metrics. It covers evidence you can use without pretending a prototype produced a business result.
“I made wireframes” tells the reader what file you produced. It does not tell them what you understood or why the work improved.
The examples below are illustrative. They are not customer projects or measured results.
“I conducted interviews and created personas.”
“Then I made wireframes and a high-fidelity prototype.”
“Finally, I ran usability tests and iterated.”
“Interviews showed that people understood the labels but did not trust what would happen after clicking.”
“I compared a confirmation step with an inline explanation. We chose the inline version because it answered the concern before asking for commitment.”
“Testing showed less hesitation, but we did not measure the effect after launch.”
Evidence → interpretation → decision → tradeoff → observed effect
You do not need this sequence for every screen. Choose the two or three decisions that best reveal how you work.
Scannable does not mean shallow. It means the hierarchy carries the story even before someone reads every paragraph.
Role, team, timeline, status, and scope should not be buried halfway down the page.
“Why we removed account creation” is more useful than “Design process.”
Give the reader orientation, then explain how the important decisions developed.
Say what the reader should notice and why the artifact matters to the story.
Break long process dumps into decisions. Remove repeated setup and generic methodology explanations.
Make sure type, diagrams, captions, contrast, and controls remain readable and usable on a smaller screen.
A case study is ready enough when the story is understandable, the important claims are supported, and the remaining gaps are named honestly.
The opening explains what changed, for whom, and why it mattered.
My role and the team’s role are easy to distinguish.
The project status is accurate: concept, tested prototype, shipped work, or something else.
The problem is supported by evidence rather than repeated from a brief.
At least two important decisions connect evidence to the final design.
Tradeoffs and constraints are visible instead of edited out of the story.
Every number, quote, and outcome can be traced to a real source.
Illustrative or fictional examples are labeled clearly.
Research participants and sensitive project information are protected or shared with informed permission.
The outcome section names what was and was not measured.
The reflection is specific to this project.
Images have useful captions and readable mobile crops.
A reader can understand the main story from the headings and summary alone.
Send the page or screenshots for a free First Read. We’ll give you a readiness verdict and the first thing to tighten. When available, we’ll also call out one strength and a ready-enough standard.
Use the smallest tool that helps you finish the story. The portfolio platform matters less than the clarity and truth of the work inside it.
Write
Work through the seven sections with prompts and a live preview.
Find evidence
Use honest evidence when revenue, conversion, or launch data is unavailable.
Check the portfolio
Review the case study in the context of the whole portfolio.
Read the research
Nielsen Norman Group’s career research includes portfolio questions, hiring perspectives, and the study’s limitations.
Layout reference: Figma’s portfolio page lesson makes the useful point that the exact case study layout depends on the story. That is the right way to use this structure too.
QuestionsAnswers
A few practical details before you keep going
Written by
Nikki KippleProduct Designer & Design Educator
Designer, educator, founder of The Crit. I've spent years teaching interaction design and reviewing hundreds of student portfolios. Good feedback shouldn't require being enrolled in my class — so I built a tool that gives it to everyone. Connect on LinkedIn →
Upload a case study URL or screenshots. Your free First Read will give you a readiness verdict and the first priority to address. When available, it will also call out one strength and a ready-enough standard.
