Hey and welcome back to a new week!

Last week, I wrote about learning what good design looks like. This week, I want to zoom out: which projects should actually go into your portfolio, and what should each one prove?

Real work, side projects, fictional concepts, and even work that never shipped can all have a place. The trick is choosing a mix that shows your strengths and points toward the work you want to do next.

In this issue:

💬 GOOD PROMPTING IS STILL A BIG UNLOCK

What’s the key to maintaining brand integrity at scale? A lot goes into it, but the teams that get it right have one thing in common: they know how to talk to AI models.

As teams speed up and the required creative volume balloons, communication matters more than ever— both with LLMs, and with the people around you. Creative teams need to focus on ideas, concepts, craft, while technology augments their manual execution demands.

Join our discussion on this evolution with Ari Murray, Chief Digital Officer at Salt and Stone, and get 5 tips for expert LLM prompting with ready to run prompts.

Register and get prompting

If you're building a design portfolio as a junior (or even beyond), you probably have some combination of one or multiple university projects, an internship, a fictional redesign, a side project, and a few things you made that never went anywhere.

The difficult part is deciding which of those deserves a place. Do you need a real company behind every project? Does everything need to have shipped? What if your strongest work is something you built yourself with AI?

I wrote about choosing the right case studies last December. The principle still holds: choose work that points toward the roles you want. But I would look more carefully now at what each project actually proves.

I don't think every project needs to be a perfect business success story. A strong portfolio can combine work that shows commercial understanding, work that demonstrates craft, and something you built that makes your capabilities immediately visible. The important thing is knowing which evidence you have, and which you don't.

A meaningful project from an internship, a job, freelance work, or volunteering can absolutely be your flagship case study. That hasn't changed.

You worked with a real organisation. Someone needed something to improve. There were constraints, other people, and consequences to the decisions. That gives your design a context a fictional brief usually struggles to provide.

The company doesn't need to be famous, either. Improving a booking flow for a small business or an internal tool for a nonprofit can tell me plenty. What matters is whether the work is good and whether you understand why it existed.

This can also come from a job where your title wasn't designer. Maybe you worked in operations and helped redesign a tool your team used. Maybe you worked in marketing and improved a real purchase journey. Explain your actual role and contribution. You don't need to rewrite your employment history to make the design work count.

When you turn that experience into a case study, I would want a few things to come through clearly:

You don't need pages of process to answer those questions. A few well-chosen visuals and a clear explanation can do much more than a complete record of every workshop.

Bring the business into the story where it belongs. If the goal was to reduce onboarding drop-off, explain how your decisions supported that goal. If the team needed fewer manual support requests, show which part of the experience you changed to address them.

And if there are results, use them. Give enough context to understand the number: what was measured, over what period, and whether this was a team outcome. “Conversion increased” means much less without that context, and you shouldn't claim your design alone caused a change you can't isolate.

Internships end. Freelance work gets handed over. You leave a role before a feature launches. Then, months later, you sit down to write the case study and realise you don't know what happened.

Before accepting that as the end of the story, contact your former manager, PM, or client. Ask whether the work shipped, whether the original goal was reached, and whether there is anything they can share for your portfolio.

Keep the request specific. “Did the new flow reduce the support requests we were trying to address?” is easier to answer than “Do you have any metrics?” Also ask what you're allowed to make public. Access to a number isn't automatically permission to publish it.

Sometimes you'll get useful data. Sometimes you'll learn that the design changed before release. Sometimes nobody measured it. All of those answers help you describe the project more accurately.

If there are no numbers, say what you do know. A workflow was adopted by a team. A test exposed a problem you fixed. You delivered the design, but left before implementation. Those are different outcomes, and they should sound different in your case study.

I've covered connecting design decisions to business impact before. The useful habit is explaining the connection. It isn't finding an impressive percentage to fill an empty results section.

Here's the type of project I would be much more cautious about starting now: invent a product, design it in Figma, assemble a familiar sequence of research, personas, wireframes, and screens, then present it as your big case study.

I think this format is losing value. It already had a difficult job because the problem, business context, and results were often hypothetical. Now it also sits beside work that people can actually try.

A fictional project can still demonstrate excellent design. A thoughtful study project can be stronger than weak professional work. But if you control the brief, the timeline, and the tools, there is a fair question waiting: why didn't you make the central idea functional?

That question matters more when you're applying to teams where AI-assisted prototyping is part of everyday work. I wouldn't pretend every employer expects the same workflow. Still, if you want to show that you can work with modern tools, a static concept leaves a useful opportunity on the table.

You don't need to build the whole imaginary company. Pick the part that makes the project interesting: a comparison tool, a booking interaction, a dense filtering workflow, or whatever the key design decision depends on.

Build enough that someone can interact with it. That lets you show behaviour, work with more realistic content, and discover problems that a carefully staged screenshot can hide. It also gives you a concrete way to demonstrate how AI helped you prototype.

I already covered turning a Figma design into a live prototype, so I won't repeat the workflow here. The point is to make the strongest part of your idea easier to assess.

A coded prototype doesn't give you business impact by itself. If nobody uses it, you still don't have adoption or commercial results. But you do have more tangible evidence of how the design works.

Figma remains useful for exploring and designing. I'm questioning the decision to stop there when a working version could make your project substantially stronger.

Something you built predominantly with AI can absolutely belong in your portfolio. It might be a small tool you use yourself, a focused interaction experiment, or a micro-product made around a problem you noticed.

It doesn't need to pretend to be an internship case study. Its value may be that I can see your initiative, your ability to build, and your judgment in the result.

For a useful tool, tell me what problem it solves and show it doing that. For a craft experiment, show the interaction and explain the decisions that make it work. If the evidence is strong, a short project page or playground entry may be enough. Don't stretch it into an elaborate research story that never happened.

But using AI isn't a quality standard. A generic first output with your name attached still looks generic. You need to refine the hierarchy, typography, behaviour, copy, and details until the thing feels considered.

That's exactly what last week's article on learning what good design looks like was about. The tools can make a lot for you. You still need to recognise what's weak and know how to improve it.

Explain what you did, too. If AI helped implement it, say so. Then show where you directed, edited, tested, or changed the work. What did the first version get wrong? What did you improve? Those answers are much more interesting than a list of tools.

The useful combination might be one substantial real-world project and one sharp side project. The first shows how you work inside an organisation; the second shows what you can initiate and execute yourself. You don't need to make both tell the same story.

Now for the other side of this: you did meaningful work for a real organisation, but the project stopped, changed direction, or never reached users. Should you leave it out?

Not automatically. I've written about this before, and I still think people discard good material for the wrong reasons.

A project that was cancelled because funding disappeared isn't suddenly fictional. You still worked through a real problem with real constraints. The design decisions, collaboration, and quality of the work can remain valuable evidence.

Make the status clear early. Say that it didn't ship, briefly explain why where appropriate, and focus on what you contributed. Then distinguish what you designed, what you tested, and what remained unverified.

You can explain the intended business benefit without presenting it as an achieved result. You can show a useful test finding without pretending it proves the product would succeed commercially. That honesty makes the work easier to trust.

It still needs enough substance to deserve the space. A cancelled project with strong design and meaningful decisions can be excellent material. A few unfinished screens don't become convincing just because there was a real client.

If you did a substantial take-home assignment and didn't get the job, the work may still be worth using. Rejection doesn't tell you everything about its quality.

Where you're permitted to share it, you can develop it further and include it as a clearly labelled hiring exercise. Explain the original scope, what you submitted, and what you explored afterward. Don't present it as paid client work or imply that the company adopted it.

Check the task terms and any confidentiality or ownership restrictions first. No signed NDA doesn't automatically mean everything is free to publish. If permission is unclear, ask before sharing. Removing the company name can help anonymise a permitted example, but it doesn't make confidential material safe to disclose; replace internal data, assets, and details as needed.

This is a reason to use strong work you already have, not a reason to spend another week on an unpaid task. My recent take-home guide still applies: keep the original assignment appropriately scoped.

You don't need one of every project type. And you don't need a portfolio where every story ends with a business metric going up.

You need a selection that helps someone understand what you can do. A strong real-world project can show business understanding and collaboration. A functional side project can show initiative, craft, and a modern workflow. An unshipped project can show good decisions under real constraints.

Now look at those projects together. Is there a pattern in the work you do well and actually want more of? Maybe you're drawn to complex B2B workflows, consumer mobile products, or the intersection of software and hardware. Your internship might have helped you discover that, too: which problems did you enjoy, and which would you happily leave behind?

That's where positioning yourself for the right roles comes in. If a direction is emerging, choose and order your projects so they support it. They don't all need to be in the same industry or use the same tools. What matters is that someone can see a connection between the work you're showing and the work you want to do next.

And if your projects are all over the place, that's okay. You may simply not have had enough experience to find that pattern yet. Don't force a specialism onto unrelated work. Instead, try a small weekend side project in a direction you're curious about. Keep it narrow enough to explore one meaningful problem or interaction. It can help you discover whether you enjoy that kind of work, and, if the result is strong, give you something relevant to show. That can be useful even when you already have a direction and want to test it further.

Look at what you already have before inventing another brief. Ask what each piece proves, whether the quality is there, and how it relates to the roles you want. If two projects make the same point, keep the stronger one. If an older concept has a genuinely interesting idea, consider building that part instead of rewriting its case study again.

The standard isn't a perfect success story. It's work you can show clearly, discuss honestly, and stand behind when someone starts asking questions.

📈 CLAUDE (& GPT) CAN DO SO MUCH MORE FOR YOU

Observing and copying how I see others work with AI has been a serious unlock for me early on. Mindstream put some of the most useful things together in a guide here. Don't miss this.

The professionals pulling ahead aren't working more. They're using Claude.

Our free guide will show you how to:

Transform your workflow with AI and stay ahead of the curve with this comprehensive guide to using Claude at work.

Get The Free Guide

Edna Ho is a design student at UC Berkeley whose portfolio reaches beyond digital interfaces into engineering and physical product design.

That range gives the work another dimension. She can work within an expressive consumer brand, explain specialized software, and design experiences that involve something you hold or use away from a screen.

Her portfolio keeps digital product design at the center while making room for those overlaps. Let’s look at what makes that combination work, and where she could give visitors more opportunities to explore it.

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 portfolio review? Look no more. I do offer these as an async service you can book directly with me here.

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