To evaluate a UX design portfolio, read it for the thinking, not the pictures: a strong case study says what problem the designer was solving, what they learned from users, which options they rejected and why, and what happened after the design shipped. Polished screens are the easiest part of a portfolio to produce and the least informative. Founders and engineering leads who are not designers can judge the thinking well, because it is written in plain language about problems they already understand. This guide covers what to look for, the red flags, and the questions to ask in an interview.
Read the case studies, not the gallery
A portfolio usually has two kinds of content: a gallery of finished screens, and case studies that tell the story of a project. The gallery tells you the designer can make things look good. The case studies tell you whether they can work out what to make, which is the job.
A good case study answers five questions:
- What was the problem? Stated as a problem for users or the business, not as "redesign the dashboard."
- What did they learn, and how? Interviews, usability tests, analytics, support tickets. Some evidence that decisions came from somewhere.
- What did they try and reject? Early sketches, alternatives, and the reason each was dropped. A case study that shows only the final design hides the decisions.
- What constraints did they work within? Deadlines, engineering effort, an existing design system. Real projects have constraints, and good designers say how they handled them.
- What happened afterwards? A metric that moved, a support load that fell, or at least what the team learned. "It shipped" is the minimum.
What to look for
- Their own role, stated plainly. Product design is collaborative. Look for "I ran the interviews and designed the flow; another designer built the components," not a vague "we."
- Work like yours. A designer who has worked on a complex B2B workflow will read your admin screens differently from one who has designed marketing sites. Neither is better; one fits.
- Handoff to engineers. Specs, states, edge cases, a design system. Screens your developers cannot build from are a drawing, not a design.
- Writing. Clear case studies usually mean clear specs and clear interface text.
Red flags
- Only finished screens. No problem, no process, no outcome.
- Concept redesigns of famous apps. They show visual skill, but nobody constrained them, nobody tested them, and nobody had to build them.
- Every project "increased conversion" with no number or context.
- No mention of users at all.
- Process theater. The same five-step diagram in every case study, with nothing specific to the project inside it.
Questions to ask in the interview
Walk through one case study together and ask:
- What would you do differently now?
- What did the engineers push back on, and how did that change the design?
- Which decision in this project are you least sure about?
- How did you know the design worked?
- What did you hand off, and what happened to it after you handed it over?
The answers tell you more than the portfolio can. A designer who can explain a trade-off they lost, without blaming anyone, has worked on real products.
A first deliverable is the best test
A portfolio shows past work in its best light. The surest way to judge a designer is to see how they work on your product. A useful first deliverable is narrow: one user flow taken from research notes to a tested prototype, with the specs your developers need to build it. Write it into the engagement as the first piece of work. You learn more from that than from any portfolio review, and the work is yours as it is created.
If nobody on your team can review design work
This is common in small companies, and it changes the level you need. A mid-level designer does good work when someone senior sets direction and reviews it. If nobody on your team will, choose a senior designer, who has owned this kind of work alone before.
Frequently asked questions
What is the difference between a UX designer and a UI designer?
UX design is how the product works: the flows, structure and behavior. UI design is how it looks: layout, type, color and components. Product designers usually do both, which is what most small teams need.
How many case studies should a design portfolio have?
Quality matters more than count. Two or three detailed case studies say more than a dozen thumbnails.
Should I give a designer a take-home design test?
An unpaid test asks for free work and puts off experienced designers. A narrow first deliverable on your real product, once the engagement has started, tests the same thing and gives you something useful.
Do designers work in our design files?
They should. Give them access to the tools and accounts the work needs, so the work lives where your team can see it.
Where to go from here
sourceBOLD engages mid-level and senior UX/UI and product designers across the Americas, month to month, as their contractor of record. We review every candidate's portfolio before you see them, and the designs they create for you are yours (MSA §3). Design shows typical starting prices, and how we vet candidates covers what happens before you meet anyone.