How to Show Your Design Process in a Portfolio (Without Losing the Reader)
Learn what process work to capture, how to present it, and how to avoid the mistake that makes most portfolio case studies a chore to read.
Most portfolio advice sounds the same: show your process, not just the final work. And it's true. But nobody tells you what that actually looks like.
Show too little process and you look like a decorator who applied a template. Show too much and your case study becomes a 47-slide Figma dump nobody finishes reading.
This guide is about finding the middle — the version of your process that's useful to the people reading it.
Why "Show Your Process" Is Real Advice
When someone asks to see your process, they're asking a specific question: Can I trust this person to do this again?
Final work proves you got somewhere. Process proves you know how to get there.
A client hiring you for a new project can't tell from your last polished homepage whether it was luck or skill. Your process is the evidence. A hiring manager wants to know you can think, communicate, and handle ambiguity — not just produce deliverables.
That's the lens to use when deciding what to include.
What "Process" Actually Means (It's Not Every Figma Frame)
Process isn't documentation. It's a story with a point.
Bad process work: screenshots of every iteration in chronological order. Good process work: selected moments that show why you made a decision.
The difference is narrative. Process that works answers these questions:
- What was the problem you were solving?
- What constraints were you working within?
- What did you try, and why?
- Why did this solution win over the alternatives?
You don't need to show every version of every screen. You need to show the moment that changed your thinking.
What to Capture During a Project
The hard truth: you can't reconstruct process work well after the fact. The best case studies come from people who capture evidence as they go.
What to document while you're still in the work:
Early explorations. Save sketches, even rough ones. A photo of a whiteboard sketch beside the final UI is worth a thousand words. It shows you think before you touch a computer.
The rejected direction. This is the most underused material in any portfolio. If you explored a direction and killed it, note why. "We considered a card-based layout but abandoned it because it buried the most common user action three taps deep." That single sentence proves you can evaluate decisions, not just execute them.
Research artifacts. User interview notes, competitive analysis, data that informed direction. You don't need to show everything — a snippet is enough. "We interviewed 12 users and three kept using the same phrase: 'I feel like I have to figure it out.'" This is evidence of rigor.
Annotations on wireframes. Instead of posting a bare wireframe, add callout notes explaining the choices. Why is this CTA placed here? Why is this section hidden on mobile? Annotations turn deliverables into arguments.
Before and after. If you improved something, show the starting point. "Before" is context. Without it, there's no story.
How to Structure a Process Section
Every project is different, but this order works for most:
Context (1–2 sentences)
Who is this for, and what was the problem? Keep it tight. "A fintech startup needed to onboard small business owners who had never used accounting software before."
My Role
Be specific. "I owned visual design and worked alongside a researcher who ran user interviews." This matters because reviewers calibrate their expectations to your actual contribution, not the full team's.
Discovery
What did you learn before designing? Research methods, key insights. One insight with evidence beats five vague claims. If you have a quote from a user interview or a data point, use it here.
Exploration
This is where you show the messy middle. Two or three explorations with your reasoning. What did you try? What didn't work and why? This is where most designers leave value on the table.
Solution
The final work — in context. Now that the reader understands the problem and the journey, they actually care what you built.
Outcome
What happened after launch? Metrics if you have them: "Onboarding completion went from 34% to 61%." If you don't have hard data, qualitative results work: "The sales team stopped fielding questions about the setup flow." Absence of results is fine; absence of any reflection is not.
A good case study using this structure takes five to seven minutes to read, not twenty. The portfolio case study template breaks down the full format in detail if you want a section-by-section guide.
The Biggest Mistake: Too Much Volume
Designers confuse thoroughness with quality more than almost any other profession.
Forty wireframe variations don't prove you're rigorous. They prove you didn't edit.
If you can't cut half of your process work and still tell the same story, it's not edited yet. Every image and section should earn its place by advancing the narrative. If a screenshot doesn't explain a decision or show a pivot, it's clutter.
This is hard to do on work you're proud of. Do it anyway.
Five Things That Make Process Work Actually Readable
Captions on everything. Never show an image without explaining what it is and why you're showing it. "Early exploration of a single-screen onboarding flow — discarded because users felt overwhelmed by the number of choices upfront." One sentence. Makes a significant difference.
Annotated screenshots instead of bare wireframes. Add callouts. Circle the element that matters. This takes ten minutes in Figma or Sketch and saves the reader from guessing what they're looking at.
Narrative connectors between sections. Write one bridging sentence between major sections. "After those interviews, it became clear we'd been solving the wrong problem." This makes a case study feel like a story, not a checklist.
Honest failure. If something didn't work, say so. "The first version tested poorly — users didn't understand what the primary action was." Reviewers trust this. It signals you're coachable and grounded in the actual work.
Real constraints. Mention what you were working around. "The client had a legacy system we couldn't redesign, so we built around it." Constraints explain decisions that might otherwise look wrong and make the project feel like real work rather than a spec exercise.
Process Work for Non-UX Creatives
Process isn't only for product and UX designers. Photographers, brand designers, illustrators, and architects all have process — it just looks different.
Photographers: Show the brief, the moodboard, the contact sheet, and the final selects. Show how you arrived at the image, not just the image itself.
Brand designers: Early logo concepts, the typography exploration, rejected directions alongside the winner. Explain the strategy behind the decisions. Dribbble and Behance are both full of brand designers who do this well — browse top-featured brand work and study how they pace the narrative.
Illustrators: Rough sketches, color studies, client revision rounds if you have them. Show the conversation as much as the work.
The principle is the same across disciplines: evidence of thinking, not just talent.
How Many Projects Actually Need Full Process Work
Not all of them. Three to five in-depth case studies outperform eight surface-level ones every time.
For projects where you can't show depth — confidential client work, quick turnarounds, work covered by NDA — a brief description with final images is fine. See how to handle NDA work in your portfolio for options that don't require showing anything you shouldn't.
Reserve the full process treatment for your two or three strongest, most strategically relevant pieces. These are the ones doing the heavy lifting. Make them the standard, not the exception.
For thoughts on how to sequence these and what to prioritize on each page, how to organize your portfolio projects covers the ordering logic in detail.
If you're building or rebuilding a portfolio and want a clean, fast way to present case studies without fighting with a page builder, mnml.page is built for this — structured blocks for project pages, fast load times, and a layout that puts the work first.
Tools & Resources
-
Figma — The standard for presenting process work. The annotations, frames, and prototyping features are underused in portfolio contexts — add callout frames and section labels to your designs before screenshotting them for case studies.
-
Nielsen Norman Group — UX Portfolio Case Studies — The definitive resource on what hiring managers actually look for in UX case studies. Worth reading before you build or revise any process section.
-
UX Collective on Medium — Hundreds of designer-written breakdowns of real projects, including process documentation. Useful for calibrating what good process narrative looks like across different specializations.
-
Behance — Browse top-featured work in your discipline and pay attention to how the best portfolios pace process documentation. The density and depth of top work sets a useful reference point for your own.
-
mnml.page — A minimal portfolio builder built for designers and creatives. Fast by default, with a block structure that makes project pages and case studies straightforward to assemble without writing code.
Ready to build your site?
Create a beautiful portfolio or personal website in minutes. No code, no complexity.
Start for free