Not Everything Is a Case Study

I’ve been on both sides of the hiring table. I’ve put together many case studies to land new roles, and I’ve reviewed thousands of portfolios trying to fill one. I’ve learned a few things because of that.

Most case studies are built to be thorough. They walk through every phase, every decision, every outcome. That depth makes sense. We do a lot of work and want to show it. But I think it also optimizes for the wrong moment.

The first person to see your case study is usually a hiring manager or recruiter with a stack of applications. They’re not settling in with coffee to study your process. They’re scanning. Fast. Trying to figure out if you’re worth a conversation.

I’ve been that person. You develop a rhythm. Open portfolio, scroll, get a vibe, move on. It’s not ideal, but it happens. When you have 140 applicants in front of you and a meeting in twenty minutes, you gotta do what you gotta do.

Three ways to show your work

Not every piece in a portfolio needs to be a full case study. The way I think about it, there are three tiers, and they serve different purposes.

Showcase. All visuals, minimal context. Think Dribbble shots or a gallery page. Great for demonstrating craft, especially for visual or brand work. But for product design hiring, it usually doesn’t give a reviewer enough signal to evaluate how you think.

Project Feature. The middle ground. Enough context and images to understand the project, your role, and your thinking. Optimized for the first read, when someone is scanning fast and deciding whether to keep going. This is what most of this post is about.

Case Study. The deep, thorough walkthrough. This is what you bring to the interview when you have twenty minutes to an hour and someone’s full attention. There’s a lot to say about how to build a great case study, but that’s its own post.

Most designers default to case study format on their portfolio site. I think that’s a mismatch. The viewing context, someone scanning quickly during a first pass, calls for a project feature. The full case study earns its place later, in the room.

The sections of a project feature

The hook

The first two or three sentences do almost all the work. If those don’t resonate, nothing else gets read. The reader needs to understand what they’re looking at immediately, and importantly why they should care.

A good hook answers three questions fast. What was the situation, what did I work on, and what changed. Not in detail. Just enough to create a thread someone wants to pull.

Enough screens to build excitement

Before anyone reads a word, they’re going to scroll through your images. This is the first impression, and it happens in seconds.

There’s not a specific number of images to hit, just enough that someone viewing them gets excited about the work. Too few and it feels shallow. Too many and it can be hard to understand what it is.

I think about types of shots rather than a count. A hero shot of the main thing. A before/after or a key state change. A detail that shows craft. Maybe a mobile view. Each image should make someone want to know the story behind it.

Variety matters too. Years ago I had some branding work in my portfolio and I was showing a bunch of variations of the in-progress logo. I remember realizing that for people not in the weeds of a project, images that are too similar just feel like subtle versions of the same idea without enough context to understand the differences. It’s confusing. Now I try to pick the strongest version and move on.

If you’re working under NDA or with confidential products, this still applies. Anonymized screens, stylized recreations, whatever gets the point across. The goal is showing your craft and thinking, not the exact pixels that shipped.

Be specific about your role

“Led design for the project” doesn’t tell me much. “Sole designer on a four-person team, responsible for research, interaction design, and the component library” does.

Being specific helps a hiring manager understand your actual scope. Are you an IC who owns execution end-to-end? A lead who directed other designers? Someone who partnered closely with engineering on implementation? These are different profiles and they’re looking for specific ones.

Collaboration signal matters here too. Saying you worked with research, or partnered with a PM to define scope, or paired with engineers on feasibility shows you operate on a team. That’s not a footnote. For a lot of roles, it’s a requirement.

One design problem, not a feature list

A lot of case studies treat the format like a feature tour. Screen after screen with descriptions of what each one does. That shows output, not thinking.

What I try to do instead is focus on one core design challenge. The gnarliest constraint, the most interesting tradeoff, the decision that shaped everything else. What options I considered, what I traded off, why I landed where I did. This is where a hiring manager learns the most about how someone actually works. Not from the final screens, but from the decisions behind them.

This doesn’t have to be a massive constraint or a company-defining problem. Small, well-framed problems work. The point is showing your thinking, not the scale of what you touched.

Outcomes, even incomplete ones

I get why people skip this section. The project got deprioritized. The metrics aren’t impressive. You left before launch. It feels safer to just not mention it.

But omitting outcomes is worse than imperfect data. When I’m reviewing a portfolio and there’s no outcomes section, I don’t assume the results were fine. I assume you either didn’t measure or didn’t want to share. Neither is great.

Hard metrics are great when they exist. When they don’t, qualitative results still work. “Engineering shipped it in half the estimated time because the spec was tight.” “Customer support tickets for this flow dropped after launch.” “The team adopted this pattern across three other features.” Even smaller signals count. “Usability test participants completed the flow without help.” “Three teammates adopted the component I built.” The point is demonstrating that you paid attention to what happened after you handed off designs.

I also like including a sentence about what I’d do differently. It shows reflection, and honestly it’s the kind of thing that makes me trust a candidate more.

Captions explain decisions, not screens

Captions that describe what’s visible on screen don’t add anything. “This is the settings page” is wasted space. But “We moved the most-changed settings to the top after watching users dig for them in testing” tells a story.

I try to use every caption as a chance to show thinking. Why, not what.

The project feature is a design artifact

Your presentation choices are being evaluated too. Typography, layout, hierarchy, how you sequence information. The project feature itself is a design artifact, and hiring managers notice.

It doesn’t need to be flashy. But I think it should be intentional. Clear hierarchy. Good pacing. Images that are crisp and well-cropped. I try to put the same care into the presentation that I put into the work itself.

The collection tells a story

When I’m putting together a portfolio, I think about what the collection shows as a whole. Do they demonstrate range? Different problem types, different scales, different industries? Or do they feel like three variations of the same project?

The portfolio-level story matters because a hiring manager isn’t just evaluating individual pieces. They’re building a picture of what kind of designer someone is and where they’d fit.

Where it gets read

One more thing that changed how I format these. I started thinking about where they actually get viewed. On a phone between meetings. In an email forward from a recruiter. On a laptop with twelve other tabs open.

Long, image-heavy pages that need a desktop browser and focused attention are optimizing for a viewing context that rarely happens in the first round. Structure and clarity win over richness at this stage.

The template

After all that reasoning, here’s the checklist I run through when putting a project feature together. Not exact headings to copy, more like questions to answer.

• The hook. What was the situation? What did you do? What changed? Two or three sentences.
• Screens. Enough visuals to build excitement before someone reads a word. Hero shot, before/after, detail shots, mobile views, interactions.
• Context. Company, timeline, team size. One or two sentences.
• Your role. What you specifically did. Be precise about scope and collaboration.
• The design problem. One core challenge. How you thought about it, what you traded off, why you landed where you did.
• Outcomes. Metrics if you have them. Qualitative results if you don’t. Optionally, what you’d do differently.

I don’t follow this exactly every time. Some projects need more, some need less. But it’s a good rubric when you’re staring at a blank page.

When I think back to scanning those 140 applications, the ones I remember aren’t the longest or the most polished. They’re the ones where I understood the work in thirty seconds and wanted to know more. A clear hook, a few strong images, a real design decision. That was enough to stop scrolling.