How to Write Portfolio Case Studies That Actually Get You Hired, Part 2: Showing Your Thinking

Part 2: how to write case studies that show your thinking, not just final screens. A template you can use.

This is where most portfolios fall apart. Writing portfolio case studies as a designer is the skill that separates a gallery of screens from a body of work that actually gets you hired.

You can have beautiful final screens, a gorgeous portfolio site, and a compelling About page, but if your case studies don’t show how you think, you’re leaving the most important part on the table. This is Part 2 of the portfolio series. If you haven’t read Part 1 on what to include and why it matters, start there.

Why Case Studies Matter More in the Age of AI

Here’s the uncomfortable truth: AI can now generate polished UI screens in seconds. Beautiful mockups, complete design systems, pixel-perfect components, the visual output is getting harder to distinguish from human-made work.

What AI can’t do is explain why it made the decisions it made. It can’t walk you through the research that informed a color palette choice. It can’t explain the user insight that led to restructuring a navigation flow. It can’t tell you about the three directions it explored and why it killed two of them.

Your case studies are proof that a thinking human is behind the work. Your reasoning, your process, your decision-making process, that’s what can’t be generated. That’s what gets you hired. Strong portfolio case studies for designers show the reasoning, not just the result.

Portfolio Case Studies: The Template That Works

After a lot of iteration across my own projects, this is the structure I use. Not every section applies to every project, adapt it to what’s relevant.

1. The Hook

One sentence or question that captures what makes this project interesting. Not ”I designed an app for X.” More like ”How do you make financial tracking feel empowering instead of stressful?” This is the first thing someone reads. Make it count.

2. Overview

Two to three sentences covering what the project is, who it’s for, and what the goal was. Quick context so the reader knows what they’re looking at before diving into details.

3. The Challenge

What made this project hard or interesting? What constraints existed? What tension needed resolving? This is where the reader starts to understand the problem space, and it’s what makes them care about your solution.

4. Research and Discovery

What did you learn before designing anything? This might include user insights, competitive analysis, industry conventions you studied, or conversations with stakeholders. Show that your design decisions were informed, not arbitrary.

For career switchers: if your research was informal (you observed users, you studied competitor apps on your own, you drew from your technical background to understand constraints), that still counts. Frame it honestly.

5. Design Process

This is the meat of the case study. Not every step, just the interesting decisions. Where did the project pivot? What did you try that didn’t work? What feedback changed your direction?

A powerful approach: show the separation between visual direction and structural design. Explain that you explored the look and feel as a distinct phase from the user flows and information architecture. This demonstrates a mature design process and shows you understand that UI and UX are different disciplines that require different thinking, even though they come together in the final product.

Include artifacts from the process: mood boards, wireframes, early explorations, direction options you presented. These are more interesting than final screens because they show your thinking in action.

6. Key Design Decisions

Pick two or three specific choices and explain the why behind each one. This is where your expertise is most visible.

Good examples of design decisions worth explaining:

• Why you chose a specific color palette and what psychological response it creates for the target audience
• Why you structured the navigation a particular way based on user behavior patterns
• Why you broke from industry conventions in one area but followed them in another
• How a technical constraint (something you understood from your dev background, perhaps) influenced a design choice
• Why you reduced the number of steps in a flow and what that meant for conversion

Every decision you explain is proof that you think intentionally, not just aesthetically.

7. Final Designs

The polished screens and the visual outcome. Present these well, high-quality mockups, consistent framing, enough context to understand what you’re looking at. But resist the urge to make this section the longest. The thinking that preceded these screens is more valuable than the screens themselves.

8. Results and Reflection

For real projects: measurable outcomes, client feedback, what you’d do differently. For concept projects: what you learned, what you’d test with real users, what assumptions you’d want to validate.

As as UX writers on Medium explain, honest reflection shows maturity. ”If I did this again, I’d spend more time on the onboarding flow” is more impressive than pretending everything was perfect.

How Long Should a Case Study Be?

Long enough to show your thinking. Short enough that someone actually reads it. That’s not a cop-out, it genuinely depends on the project complexity.

A few practical guidelines:

• Aim for 5, 10 minutes of reading time. Much shorter and you’re probably not showing enough thinking. Much longer and you’re losing readers.
• Use visual hierarchy aggressively. Section headers, pull quotes, image breaks. Nobody reads a case study linearly, they scan, stop at interesting parts, and dive deeper selectively.
• A floating table of contents helps. For longer case studies, letting readers jump to sections reduces the intimidation of a long page.
• Not every section needs the same depth. Go deep on the parts that were most interesting or challenging. Summarize the straightforward parts.

The Brain Dump Method

Writing case studies can feel overwhelming, especially when you’re staring at a blank page. Here’s the method that works for me:

Step 1: Brain dump everything. Open a document and write down every single thing you remember about the project. Don’t organize, don’t filter, just get it all out. Decisions, challenges, feedback, pivots, things that worked, things that failed.

Step 2: Sort into sections. Take the brain dump and start dropping things into the template sections. You’ll quickly see which sections are rich with material and which are thin.

Step 3: Write the narrative. Now turn the sorted notes into actual prose. Focus on the ”why” behind everything. For each fact or decision, ask yourself: why did this happen? Why did I choose this? What was the alternative?

Step 4: Gather the visuals. Once the written content is solid, figure out what images, mockups, wireframes, and process artifacts to include. The writing should drive the visuals, not the other way around.

This method works because it separates the remembering from the writing from the presenting. Each one is a different cognitive task, and trying to do all three at once is why case study writing feels so draining.

For Career Switchers: Framing Technical Work as Design

If you came from development or another technical field, your case studies need to bridge the language gap. You made design decisions, you just might have described them in technical terms.

Some translations:

• ”I built a responsive dashboard” → ”I designed and implemented an information-dense interface that prioritizes the most critical data points while remaining scannable across device sizes”
• ”I refactored the navigation” → ”I restructured the information architecture to reduce the number of steps users needed to reach core features”
• ”I created the component library” → ”I established a design system that ensures visual consistency and reduces cognitive load across the product”

You’re not exaggerating, you’re describing the same work through a design lens. The decisions were always design decisions. You’re just naming them accurately now.

Coming Up Next

In Part 3, we’ll cover the final stretch, taking everything from Figma to a live portfolio site. Platform choices, responsive considerations, and the honest truth about shipping imperfect work.