One deep case study beats six shallow projects

Most junior design portfolios look the same: six or seven projects, each a grid of attractive screens, each with a one-line description. "A redesign of a food delivery app." Then the next one.

Hiring managers skim those in about eight seconds and move on. Not because the screens are bad — often they are good — but because the portfolio answers a question nobody asked. They do not need to know that you can make something look nice. Figma makes things look nice. They need to know how you think.

What they are actually reading for

When someone reviews a junior portfolio they are trying to answer three questions, quickly:

1. Did this person understand the problem, or did they just restyle the existing thing?
2. Did any decision come from evidence, or is it all taste?
3. What happened when something did not work?

A grid of screens answers none of these. One project, written up properly, answers all three.

The structure that works

Here is the shape we teach on the UI/UX track, and it is deliberately unglamorous:

The problem, in one paragraph, from the user's side. Not "the app had an outdated interface" — that is a symptom and it is about the app. Something like "people abandoned the booking flow at the payment step, and support tickets suggested they did not trust it." Now there is something to solve.

What you did to find out. Five interviews is enough. Say who you spoke to, what you asked, and what surprised you. The surprise is the most valuable sentence in the entire case study, because it proves you learned something rather than confirming what you already believed.

The structure before the visuals. Show the flow, the information architecture, the states you had to handle. Include the empty state, the loading state and the error state. Almost no junior portfolio does this, and it is the clearest possible signal that you have thought about the real thing rather than the happy path.

The wireframes, including the one you abandoned. Show a direction that did not work and say why you dropped it. This feels like admitting failure. It reads as judgement.

Then the final screens. By now the reader is interested, and the visuals land differently because they understand what each decision is for.

What testing changed. Put the prototype in front of five people. Something will break. Say what, and show the fix. This section is the difference between a student project and a piece of professional work.

What you would do next. One honest paragraph. Nobody finishes a real project; saying so is a mark of experience, not incompleteness.

"But I need to show range"

This is the usual objection, and it is worth taking seriously.

Range matters at mid-level, when you are being hired for breadth. At junior level you are being hired on evidence that you can think, take feedback and finish. One project shows that. Six do not show it six times over — they show it zero times, because none of them went deep enough to demonstrate anything.

If you want a second piece, make it a design system rather than another app redesign. It shows a completely different muscle: consistency, naming, thinking about other people using your work. Two artefacts of different kinds beat six of the same kind.

The writing is the work

The thing that stops most designers producing a good case study is not design skill. It is that writing about your own decisions is uncomfortable. You have to commit to a reason, and a written reason can be wrong in a way a beautiful screen cannot.

Do it anyway. It is the same skill you will use every week of your career to defend a decision to a product manager who wants the button to be bigger. Being able to say "we tested that and here is what happened" instead of "it felt right" is most of what separates a designer whose work ships from one whose work gets overruled.

That is why our two-month track spends its final fortnight on the write-up rather than starting something new. It looks like less output. It produces a stronger portfolio.