What is a portfolio actually for?
A design portfolio has a surprisingly simple job: it should help the person looking at it decide whether they want to take the next step.
If you are looking for a job, that next step might be an interview. If you are a small design team trying to win a project, it might be a conversation with a prospective client.
That distinction matters because a portfolio is not an archive of your career. You do not need to show everything you have ever designed. You need to show enough of the right work to give the right person confidence that you can solve the problems they care about.
A portfolio should not answer “How much work have you done?” It should answer “Why should I believe you can solve my problem?”
Once you look at a portfolio this way, several common portfolio habits start to make less sense.
1. Curate rather than catalogue
One of the easiest mistakes is to show too much.
Some portfolios become a wall of screenshots. Project after project is added in the hope that the person looking will eventually find something they like. This approach is particularly common when companies are competing largely on price: show enough work and perhaps the prospect will find something that looks familiar.
But quantity does not necessarily create confidence. In fact, showing ten poorly explained projects can tell me less than showing two or three projects that explain how a difficult problem was solved.
You don't need to prove that you can do everything. You need to make your particular capability obvious.
Think about your portfolio as a selection, not a storage system. Ask yourself what you want to be hired to do and choose projects that provide evidence for that position.
That may mean leaving good work out.
2. Show your strength without trying to sell to everyone
Every designer has a speciality, a strong suit, or a particular kind of problem at which they are especially good. A portfolio should make that strength visible.
This doesn't mean pretending you have no other capabilities. It means understanding that the portfolio has a specific audience.
Imagine a product designed for everyone. It would be difficult to make meaningful decisions because every possible user has a different need. The same thing happens with portfolios.
If you try to create a portfolio that appeals equally to a startup founder, an enterprise product leader, a branding client, a hiring manager and an agency looking for visual design, you can easily end up with a collection that doesn't have a clear position at all.
Show enough range to demonstrate that you can adapt. But don't allow that range to obscure what you are particularly good at.
If you have relevant work outside your primary speciality, you don't necessarily need to put it on the front page. Keep it available for the situations where it matters.
The principle is simple: curate for the position you want to occupy, not the complete history of what you have done.
3. Start with the problem, not the screens
A beautiful interface tells me that someone can make a beautiful interface.
It doesn't necessarily tell me whether they can solve a problem.
For every significant project, give the reader enough context to understand what was happening before the design existed. What was the challenge? What was the business asking for? What did users need? What constraints existed? What were you actually being asked to change?
This is particularly important for experienced designers. The more senior the role, the less useful a collection of polished screens becomes as evidence of capability.
The interesting part is usually what happened before the screen.
A strong case study should allow the reader to understand the relationship between the problem and the solution. Without that relationship, the final design becomes an isolated artefact that could have been produced for almost any reason.
4. Don't show me the map. Show me that you travelled the road.
This is where many portfolio case studies go wrong.
Open almost any collection of design portfolios and you will find the expected ingredients: personas, user journeys, wireframes, usability testing, visual design, design systems and polished final screens.
There is nothing wrong with any of these things. The problem is when they are simply presented one after another, disconnected from the decisions that shaped the product.
In a real project, these supporting artefacts are evolutionary. One thing leads to another.
An observation creates an insight. The insight changes the way the problem is understood. That changes a design decision. The decision creates another question. New information changes the solution. A stakeholder introduces a constraint. The design adapts again.
These artefacts are the atoms from which the eventual product is made.
That is very different from creating the final product first and then producing a persona, journey map and other artefacts afterwards because they are expected in a portfolio.
Don't show me the map. Show me that you travelled the road.
A strong case study doesn't need every artefact. It needs the important connections between them.
Instead of saying, “We created personas,” explain what you learned that changed the design.
Instead of saying, “We created a journey map,” explain what the journey revealed that wasn't obvious before.
Instead of showing three versions of a screen, explain what changed and why.
The difference is subtle but fundamental. One approach documents activities. The other demonstrates thinking.
5. Show evidence that the work met reality
There is a particular quality to products that have been through stakeholder review.
Real products have evolving requirements. Something gets added. Something gets removed. A stakeholder asks for a change. Engineering introduces a constraint. The business changes its priorities. Content changes. A decision that seemed obvious at the beginning turns out not to work.
The resulting product is different because it has a history.
This is one reason mock projects can be easy to recognise. Sometimes the content is Lorem Ipsum. Sometimes the same two or three entries appear repeatedly in a data grid. In a food application, the “best selling” item and the “chef's special” might conveniently be the same item.
These details matter because real products have to deal with real content.
You don't need to deliberately make your portfolio look messy to make it believable. Please don't.
The point is not to manufacture imperfections. The point is to show the decisions, constraints and changes that genuinely shaped the work.
There is a useful analogy from storytelling: the stronger the antagonist, the stronger the protagonist.
In design, a demanding client, difficult constraint or competing requirement creates a harder problem for the designer to solve. When you can show how you navigated that problem, the work becomes stronger evidence of your capability.
The value of a design is not only in what was created, but in what it had to survive to get there.
A mock project can still demonstrate vision and an understanding of constraints. It may be enough to earn an interview, particularly for someone early in their career. But a real project can provide another kind of evidence: evidence that the designer has already had to negotiate with reality.
6. Make your decisions visible
A case study should not read like a requirements document written after the product was created.
That happens when the designer lists everything they did but doesn't explain why any of it mattered.
The better structure is causal:
- What did we discover?
- What did that change?
- What decision did we make?
- What happened as a result?
This doesn't mean documenting every decision. Most projects contain hundreds of them and most are not interesting to an external reader.
Select the decisions that demonstrate judgment.
Show where the problem became clearer. Show where an assumption changed. Show where two requirements conflicted. Show why one direction was chosen over another.
That is much more useful than demonstrating that you know the names of the standard UX activities.
7. Be clear about your contribution
Design is usually a team sport. Products are rarely created by one person working alone.
That makes it particularly important for a portfolio to explain what the designer actually contributed.
If you worked on a large product with researchers, designers, product managers, engineers and business stakeholders, don't imply that you personally did everything simply because the final product appears in your portfolio.
Tell the reader where you were responsible, where you influenced decisions and where you collaborated.
For a senior designer or design leader, this becomes even more important. Your value may not be visible in the final interface at all. It may be in framing the problem, aligning stakeholders, creating a design direction, resolving competing requirements or helping a team make better decisions.
The portfolio should make that contribution visible.
8. Explain what changed
Every project should have a result.
That result doesn't always have to be a dramatic business metric. Sometimes the most meaningful outcome is a clearer product, a simpler workflow, a better customer experience, a more coherent system or a decision that allowed the organisation to move forward.
But don't stop at “the product launched.”
Explain what became different because the work happened.
The result completes the story. It connects the work you did to the reason the work mattered in the first place.
How many projects should you show?
There is no magic number, but there is a paradox of choice: more options do not necessarily make a decision easier. When a portfolio presents twenty projects, the viewer has to spend more effort figuring out which ones matter, comparing similar examples and deciding where to focus. A carefully selected gallery does the opposite. By showing only the projects that add something meaningful to the story, you reduce the cognitive load and make it easier for the viewer to see your strengths.
The right number is the smallest number of projects that gives the viewer enough evidence to understand your capability, range and relevance.
For one designer, that might be three projects. For another, it might be five. A small design team may need more because several people or capabilities need to be represented.
But there is an important test:
If I remove one project, does the portfolio lose evidence of something important?
If the answer is no, perhaps the project doesn't need to be there.
Four strong projects that each demonstrate something different can be far more persuasive than ten projects that repeat the same story.
The goal isn't to make the portfolio feel substantial. The goal is to make the decision feel easy.
The portfolio should not try to close the entire decision
There is one final distinction worth making, particularly for people hiring designers.
A portfolio is not an interview.
When a hiring manager reviews a portfolio, they are often asking a narrower question: “Have I seen enough evidence to justify talking to this person?”
That means a portfolio doesn't have to answer every question about a candidate. A mock project can still be valuable. An early-career designer can demonstrate potential without having twenty years of client experience.
Likewise, a prospective client doesn't need to see every project your team has ever completed.
They need enough relevant evidence to decide whether a conversation is worthwhile.
That is why a good portfolio can be surprisingly short.
A strong portfolio is an argument
Ultimately, the best portfolios make an argument without announcing that they are making one.
They say: Here is the kind of problem we understand. Here is how we approached it. Here is how our thinking evolved. Here are the decisions we made. Here is what the work had to contend with. And here is what changed.
Everything on the page should contribute to that argument.
The screenshots are evidence. The artefacts are evidence. The process is evidence. The result is evidence.
None of them are the portfolio by themselves.
The portfolio is the story that connects them.
And perhaps that is the simplest test of all: after looking at your work, can the person on the other side confidently answer the question, “Could this designer solve my problem?”
If they can, you have probably shown enough.
