In Partnership With

Hey and welcome back to a new week!

In this issue:

• The Hardest Part Of A Portfolio Explained: Case studies are hard to crack. I’m running you through a process that will help.

• The Open Doors x Framer Student Challenge: If you are a student don’t miss out on this. Make sure to read below 👀 

• Megan’s Portfolio: Absolute MUST SEE portfolio. This one is unique.

Thank you for reading!

💪 THE OPEN DOORS x FRAMER STUDENT CHALLENGE

Design one interaction. Win prizes. Get recognized.

We’re launching the Open Doors × Framer Student Challenge for students worldwide who want to build something small, sharp, and interactive in Framer.

Your challenge: design and build one standout interaction.

No full portfolio. No huge landing page. One interaction, one submission, one month.

The theme goes live on June 1st, and submissions will stay open throughout June. The top 3 entries will win prizes from Framer + a year of Framer Pro each!

There’s also a free kickoff workshop on June 4th, where I’ll walk through how to build interactions in Framer and how to approach your submission.

You can pre-sign up now to get notified when the theme drops, RSVP for the workshop, and read the full rules on the challenge page.

P.S. Framer is totally free for students, so you can build and host your submission without needing a paid plan. The same goes of course for your portfolio! Make sure to sign up here.

How to Write a Strong Case Study for Your Portfolio in 2026 🧠

Case studies are probably the hardest part of a portfolio.

Your portfolio can look good overall. The visual level can be there. The homepage can be clean, the intro can be sharp, the project cards can be strong. But once someone clicks into the actual work, the case study is where things either hold up or fall apart.

And when they fall apart, it is usually not because the project itself was weak. It is because the work was presented weakly. That means visuals, text, structure, and ultimately storytelling. Because that’s what a case study is. Not a process dump. Not a list of deliverables. Not a giant archive of everything you did. A story.

So let’s break down what actually makes a good case study and how I’d go about building one.

What makes a good case study

The biggest rule of thumb is simple: less is more.

And I do not only mean text. This also means fewer screens, fewer artifacts, fewer diagrams, fewer giant boards, fewer deliverables, less stuff overall. Because overload is still overload, even when it comes in image form.

You do not win a case study by showing everything. You win it through curation.

A good case study tells a story. A lot of case studies still feel like this: context, research, competitors, ideation, solution, outcome. That may look structured, but it often reads like a filing system, not like something anyone wants to go through.

A strong case study tells a story built on three pillars:

1. What was the problem? Why did this project exist in the first place? What was actually broken, difficult, blocked, or worth solving?

2. What did you do about it? What was your approach, what did you focus on, and what solution did you shape?

3. What happened because of it? What did the solution do? How well did it solve the problem? What changed, what shipped, what was learned?

That’s the spine. Everything else is support.

One thing I see a lot is that designers struggle to define the problem clearly. Not because there wasn’t one, but because many projects don’t begin with someone saying, “Here is the exact meaningful problem.” Very often the starting point is much messier. You get told to design something, improve something, rethink something. Then you have to reverse engineer what the actual problem is. By the time you sit down to write the case study, that part can feel fuzzy or artificial. Still, if the problem isn’t clear, the rest of the story usually gets weaker too.

The easiest analogy here is this: imagine you’re flying someone over a landscape in a small plane. The project is the landscape. You are the storyteller. The other person is your reader. You give them binoculars. If you make them zoom in on every single tree, they’re going to lose interest very quickly. What you actually do is let them enjoy the overall view, and only make them zoom in on the important landmarks.

That’s how case studies work too. You only really zoom in on the moments that matter: a major shift, a sharp insight, an important collaboration moment, a key decision, a challenge that changed your direction, or an outcome that reveals whether the work landed. Everything else should stay lighter. A good case study is not detailed everywhere. It is detailed in the right places.

And remember: you are not writing a neutral documentary about the project. You are telling the story of how you were involved in solving the problem. Other people matter when they shaped your work or the outcome, but the center of gravity is still your role and your thinking.

Good visuals matter as much as good writing. Too few visuals is a problem. Too many visuals is also a problem. If there are too few, the case study becomes all telling and not enough showing. If there are too many, people switch off. And yes, the polish matters too. Sloppy screenshots, pixelated mockups, giant unreadable boards, rushed-looking presentation, all of that hurts the case study. There are too many tools available now for that to be excusable.

How I’d actually build a case study

This is not a perfect A-to-B system, because what you start with depends heavily on the project. A fictional case study is different from an internship project. A shipped product is different from a redesign concept. But the overall approach can still be fairly consistent.

1. Lay everything out

Start with all the material you have. Not polished yet. Not final. Just all the things that might matter. That can include screens, artifacts, notes, photos, screen recordings, prototype clips, interesting facts, collaboration moments, learnings, and outcome snippets.

Personally, I think tools like FigJam, Notion, or Obsidian are great for this. But honestly, it doesn’t matter much. Use whatever lets you see everything clearly.

At this stage, lightly pre-curate. Do not dump every screen you ever made. Start by picking highlight screens, essential screens, things you’re proud of, visuals that best represent the work, and anything interactive you may want to capture as a video. You are not done curating yet. You are only starting.

2. Group everything into the three pillars

Now split what you have into the three big buckets:

• the beginning / problem

• the middle / approach / solution

• the end / outcome / conclusion

You’ll probably notice something quickly: the middle usually has too much, and the start and end often have much less. That’s normal.

Do not only group visuals. Write down the key facts too, but not full descriptions yet. Just the highlights. Then start cutting. Ask what can be removed while the story still makes sense. Which visuals are essential? Which pieces are repetitive? Keep trimming until each of the three buckets feels manageable.

3. Subgroup the story

Especially in the middle section, start creating smaller groups. For example: market context, product problem, key insight, project shift, solution decision, collaboration moment, final solution, outcome, learning.

This will vary massively from project to project. Do not force symmetry where it doesn’t exist. If one section stays very light, that’s okay. Outcomes are often light when the project didn’t ship or when you don’t have access to much data. Then maybe that part is more about handoff or learning. That’s fine.

4. Write the headings first

This is where the case study actually starts becoming real, and this is where most people make it much weaker than it needs to be.

Do not start by writing headings like Problem, Research, High-Fidelity Designs, or Outcome. That gives away almost nothing.

Instead, make the headings carry the weight. Case studies are not read carefully. They are scanned quickly. So shift the information load from the body text into the headings.

For example, instead of Research, write something like: Users hated doing X, but our product gave them no alternative

That heading already tells me something meaningful. Even if I barely read the body text underneath, I now understand why that section matters. That’s the goal.

A good heading should already give me 80 to 90 percent of what matters. The body text only supports it. And yes, that means headings can be longer. In a case study, that is often a strength.

A useful filter here: if you catch yourself giving a section only a descriptive label like High-Fidelity Designs, stop and ask whether the section should exist at all. If you can’t make the heading meaningful, that may be a sign that the section doesn’t actually carry enough value on its own. Put it aside for now.

5. Backfill with visuals, one section at a time

Once you have the headings stacked in order, start pairing each one with supporting material.

Ideally, each section gets one visual. That’s a great default rule. In some cases you’ll need more, sure. But if a section needs four screens to explain itself, that is usually a sign that you should rethink how you are showing it.

Very often, the better move is to turn those four screens into one screen recording, one prototype clip, or one mockup with motion. That reduces visual load and usually makes the case study much more engaging.

You do not have to fully execute the polished version yet. You can even leave yourself notes like “turn this into a video later.” The point is to build the structure properly first.

6. Replace dead artifacts with better storytelling

This is also the point where you should be ruthless about weak artifacts.

Avoid things like giant sticky-note boards, huge unreadable diagrams, whiteboard screenshots, or any screenshot where the content is too small to read. No one is going to study that stuff.

And even when those artifacts were part of the process, that doesn’t mean they deserve space in the case study. Stakeholders don’t care that you made a giant research board. They care what came out of it.

So show the outcome of the process, not the process artifact itself. If your research led to a sharp insight, show the insight clearly. If you can visualize it in a small custom interaction, a clean graphic, a simple summary, or anything more digestible than a screenshot of a giant board, do that instead.

The case study should feel alive, not archived.

7. Add body text only where it is truly needed

Only now would I start adding text underneath the headings. And even then, keep it light. Usually one sentence, maybe two, three max.

That’s enough.

And if the heading and the visual already do the job, you may not need any body text there at all. That’s okay. No one is going to be upset that they had to read less.

8. Polish the visuals and make them feel cohesive

Once the skeleton works, then you move into execution.

This is where you create the screen recordings, build the cleaner mockups, redo rough visuals if needed, and make sure everything looks sharp and intentional. If you can, I’d usually recommend keeping a reasonably consistent presentation style across your portfolio. It lowers the risk of things looking off. Sometimes people try to mimic the product’s brand style too hard inside the case study presentation and don’t quite pull it off.

Simpler is often safer.

9. Bring it into the portfolio carefully

When the case study is ready, don’t just dump it into the page.

Especially if you use a tool like Framer, think about how the text and visuals appear. Very subtle transitions can help a lot. Things fading in softly, revealing at the right pace, or small hover states that add a tiny extra signal can all improve the feel of the page.

Nothing too loud. Nothing random. Just enough to support the reading flow.

A strong case study feels lighter than the work behind it

That’s maybe the best way to put it.

The project itself may have been messy, complicated, long, full of side paths, artifacts, conversations, and deliverables. The case study should not feel like that.

It should feel clear, deliberate, curated, easy to enter, easy to scan, and strong enough that even a fast reader walks away with the actual story.

That’s the job.

Not to show everything. Not to prove how much work happened. Not to document the whole timeline. To tell the story well.

🤖 UNLOCK TECH WITH THIS NEWSLETTER

Why Readers Are Obsessed With These 12 Free AI Prompts

Want an A+ when it comes to AI? Subscribe to The Current written by Kim Komando and get a free AI Prompt Hack Pack filled with powerful prompts you can enter into ChatGPT to save you hours (and money) every week.

Get The Free AI Guide Here

👀 Portfolio Showcase

Today: Megan Yap

Megan Yap’s portfolio feels like stepping into someone else’s world for a while.

It’s whimsical, deeply personal, playful in a way most portfolios are too afraid to be, and somehow still incredibly polished. That combination is rare. A lot of portfolios that try to stand out through personality or interaction end up feeling like collections of gimmicks. Megan’s doesn’t. Everything feels intentional, cohesive, and unusually well crafted.

More importantly, the portfolio leaves an impression that goes beyond aesthetics. You come away with a very strong sense of who Megan is as a designer and what kind of energy she would bring into a team. That’s difficult to achieve, especially at a student level.

And honestly, it’s hard to compare this portfolio to many others. It feels like its own thing.

Let’s see what it makes it so unique and good.

That’s it for this week—thanks so much for the support! ♥️

Do you want your own portfolio reviewed in-depth with a 30-minute advice-packed video review? Or do you require mentoring to figure out a proper strategy for your job search?

I got you!

• Book an in-depth portfolio or resume review with me

• Book a mentoring session with me

• Book a quick 15 min chat to ask a question and see if we vibe

Keep kicking doors open and see you next week!
- Florian