Hey and welcome back to a new week!

🏖 Reminder: next week there will be no newsletter as I will be sipping drinks and play with my kids on some beach in Greece. The week after I will be back but likely won’t have a portfolio showcase for you. After that we are back to normal.

In this issue:

💝 MY FAVORITE AI NEWSLETTER WITH AN AMAZING FREEBIE

The 8-hour workday is becoming a 4-hour workday for people who know how to use AI.

Everyone else is still catching up.

This AI work playbook shows you exactly how to cut your work hours in half using AI.

Sign up for Superhuman AI and get:

Claim your AI playbook

Most junior portfolio projects are incredibly well behaved.

Every account has data. Every search returns results. Every upload succeeds. Nobody enters the wrong information, loses their connection, denies a permission, or waits longer than expected.

The user taps the right button, follows the perfect path, and reaches the polished final screen.

Real products do not work like that.

Sooner or later, something is empty, delayed, incomplete, unavailable, or simply wrong. Sometimes the user makes a mistake. Sometimes the product does. Often it is nobody’s fault at all.

What happens next is part of the design.

When we start a project, we naturally focus on the main journey. How does someone sign up, create something, complete a task, or reach the outcome we care about?

That is the happy path, and it matters. But it is only one version of the experience.

Around it are all the less glamorous states that make a product feel complete:

You do not need to design every theoretical edge case. Some will not be relevant to your project, and turning a case study into an inventory of 40 error states will not make it stronger.

But you should be able to look at your main flow and ask: Where could this become confusing, slow, empty, or unsuccessful?

That question alone will make your work more believable.

This is especially relevant for early-career designers because many portfolio projects are prototypes rather than live products.

If you are working in Figma, your prototype might not actually call an API, lose its connection, or receive an error from a server. You may simply have one screen connected to the next.

That does not stop you from defining what should happen.

You can create an empty version of a dashboard, a loading variant of a component, or a short branch where an upload fails and the user retries. The prototype does not need a real backend for you to demonstrate that you considered the situation.

The same applies when you build your own project with an AI coding tool. The process may now move much faster from an idea to something interactive, but empty, loading, and error states have not disappeared. If anything, you may encounter them more directly because your prototype is actually trying to save data, call a service, or generate an output.

AI products also introduce less predictable situations. A response might take longer than expected, be incomplete, misunderstand the request, or produce something the user wants to correct. Apple’s current guidance for generative AI experiences makes a useful distinction: an exciting AI feature can be quick to prototype, while making it robust across real-world situations is much harder. Microsoft similarly recommends designing agentic products around correction, recovery, and user control.

Whether you are laying out frames in Figma or vibe coding something functional, the job is the same: decide what the product should communicate and what the user can do next.

Empty and loading states can be some of the best places to show attention to detail.

They are often visually simple, which gives you space for a thoughtful illustration, a small animation, strong writing, or a useful interaction. A good first-use state can teach someone what the product is for. A good loading state can make waiting feel more understandable. A no-results state can help someone adjust their search instead of leaving them at a dead end.

This is an opportunity to add personality that might feel distracting in the main product flow.

But the personality needs to fit the moment.

A playful empty inbox is one thing. A playful message after someone’s payment fails, work disappears, or account becomes inaccessible is another. When something has genuinely gone wrong, users usually need clarity more than entertainment.

The GOV.UK Design System’s error guidance is a strong reference here: explain what went wrong, tell the user how to fix it, preserve the information they already entered, and avoid vague messages such as “An error occurred.”

Good recovery design answers three questions:

An attractive red banner that says “Something went wrong” only answers part of the first question.

Designing for failure does not mean waiting until the end and adding error messages everywhere.

Often the better solution is to prevent the problem:

Still, prevention will never cover everything. Connections drop. Services go down. Files are corrupted. People change their minds. AI produces uncertain outputs. Products encounter situations you did not predict.

A mature experience does both: it reduces avoidable errors and helps people recover from the ones that remain.

Please do not add an “Error States” section containing a giant grid of every warning, toast, banner, and empty screen you designed.

That usually adds volume rather than evidence.

Instead, bake these states into the work you already show.

If you present a feature through a screen recording, include one short moment where something is empty, loading, or unsuccessful. Show what the interface communicates and how the user moves forward. This is one more reason I recommend using video to show your work: a short sequence can communicate the trigger, feedback, and recovery far better than three static screens.

You could show:

One well-chosen sequence is enough to show awareness.

If the project is not functional, prototype the state deliberately in Figma. If it is vibe coded, you can trigger a real failure or create a safe simulated state for the recording. Be honest about what is real. You are demonstrating your design decision, not pretending you built production infrastructure.

In the case study, one sentence of context is often enough:

“I also designed the failed-upload flow so users kept their previous inputs, understood the file requirement, and could retry without starting over.”

That tells me much more than another page of polished mockups.

I used to work with a small handoff checklist because loading, empty, and error states were consistently the things I forgot.

You do not need a huge system. Before finishing a feature, quickly ask:

Not every question will apply every time. The point is to build the habit.

Eventually, you will start noticing these moments without a checklist. You will ask about them during handoff. You will catch them while testing a build. And when an engineer asks, “What should happen if this fails?”, you will already have an answer.

Thinking about loading, empty, and error states is arguably a basic expectation of product design.

But many portfolios still leave them out completely.

That makes them a simple opportunity for early-career designers. You do not need access to a famous company, years of product data, or a fully shipped client project. You need to look beyond the ideal journey and care about what the user experiences when reality gets involved.

Use these states to show craft where playfulness is appropriate. Use them to show restraint and clarity where something has gone wrong. Most importantly, make it possible for the user to understand what happened and continue.

The polished happy path shows me what you want the product to be.

What happens when it breaks shows me whether you have really thought it through.

🫰 I LOVE A GOOD SIDE HUSTLE

AI isn't just changing business—it's creating entirely new income opportunities. The Hustle's guide features 200+ ways to make money with AI, from beginner-friendly gigs to advanced ventures. Each comes with realistic income projections and resource requirements. Join 1.5M professionals getting daily insights on emerging tech and business opportunities.

Get the guide

Sydney Nguyen is still studying Experience Design at San José State University, with some time left before she graduates.

That matters because her portfolio often feels further along than you would expect at this stage.

She has spent a few years exploring design, but she has not yet built the kind of conventional professional track record many students rely on. There is no major product design internship sitting at the center of the portfolio.

Yet the work feels credible.

Part of that comes from the portfolio itself. Sydney leans fully into a whimsical, hand-drawn direction. There are illustrations, sparkles following the cursor, playful borders, travel photos, hackathon memories, and a cat making an early appearance.

Some designers worry this kind of presentation will feel unprofessional. I don’t think that concern should stop you when the direction fits you and the roles you are pursuing.

Design sits close enough to art and visual expression that stripping all personality from a portfolio often does more harm than leaving some in. Sydney’s direction will not suit every enterprise team or corporate consultancy, but it can resonate strongly with startups, consumer products, expressive brands, and teams that value personality.

More importantly, the playfulness does not hide weak work.

Sydney has multiple functional products behind the projects she presents. Some came from hackathons. Others she built herself using current coding tools. You can open them, use them, and see that they extend beyond a Figma prototype.

That alone makes this portfolio a useful picture of how the expectations around early-career work are changing.

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