All articles

How to judge a product designer's portfolio when you're not a designer

Alla Kuchynskaya Alla Kuchynskaya · Senior Product Designer

· 8 min read

Short answer: Ignore how polished the screens are and look for judgment. A strong product designer's portfolio shows the problem, the constraints, the decisions made and the options rejected, the states beyond the happy path, and a measurable outcome with an honest description of their role. Then test the same things in a 30-minute conversation and a reference call.

I have looked at this from several sides: reviewing designers' work when I led a design team at BrainRocket and being hired by founders myself for 12+ years. The founders who hire well are rarely the ones with the best eye for visuals. They are the ones who ask "why" until they hear a real answer.

Why pretty screens tell you so little in 2026

A few years ago, a beautiful Dribbble shot proved at least one thing: the person could draw a good interface. Today a founder can produce one with a prompt in Lovable or v0 over a weekend. I see these weekend MVPs all the time. They are beautiful, and they are identical.

So screens became cheap, and what is left is judgment. Same prompt, same tool, same result: one founder ends up with a product and the other doesn't. The difference is the ability to look at 20 generated options and explain why one works and 19 don't. When I take part in interviews, I care much more about what a designer rejects and why than about which tools they know.

There is a second reason. A demo has to work once, while its author is in the room. A product has to work when nobody is: an empty account, a 40-character name, the connection dropping mid-payment. Polished hero screens show the first. Your users will live in the second.

What should I look for in a product designer portfolio? A scorecard

Use this table while you read. You don't need design vocabulary for any of it.

Signal What good looks like Red flag
Problem One clear sentence about what was broken and for whom Starts with moodboards and colour palettes
Role "I did X, the PM did Y, engineers did Z" "We" everywhere, impossible to tell what they did
Constraints Deadline, team size, tech limits, legacy users named Work happens in a vacuum with unlimited time
Decisions Shows 2–3 options and why one won Only the final version, no alternatives
What was cut Says what was left out and why Every feature anyone asked for made it in
States Empty, error, loading, first-time vs returning user Only the ideal screen with perfect data
Interface text Buttons say what happens next "Submit", "Something went wrong"
Outcome A metric, with honest attribution ("contributed to") "Users loved it", or a big number with no context
Shipped Live product, store link, real users Only concepts and redesigns of famous apps
Reflection What they would do differently Everything went perfectly
Fit Has solved problems close to yours (stage, domain, platform) Great work, but in a world unlike yours

Nielsen Norman Group surveyed 204 UX hiring professionals and heard the same things: reviewers want process over polish, evidence of real value for users and the business, and, my favourite, what isn't in the design and why.

How to read a product design case study

A good case study answers six questions in order. If one is missing, ask about it on the call.

  1. What was the problem? Specific, with a user and a cost. Not "improve the UX".
  2. What were the constraints? Time, team, tech, existing users. Constraints are where decisions come from.
  3. What did they decide, and what did they reject? This is the core. Look for trade-offs.
  4. What happens outside the happy path? Errors, empty states, slow network, permissions denied.
  5. What changed? A metric, a before/after, or at least a qualitative result from real users.
  6. What would they do differently? Senior designers always have an answer.

As a light example of the structure, here is how I describe one of my own projects. At Findmykids, a family safety app with 55M+ downloads, the parent-child connection setup was complex and people dropped off there. I turned it into a simpler step-by-step flow with clear visual feedback at each stage, as part of a wider onboarding redesign that contributed to +18% retention. Notice the word "contributed". Retention is a team result. A designer who claims a metric entirely for themselves is either working alone or rounding up, and it is worth asking which.

A 30-minute interview script for founders

You don't need a design panel. You need half an hour and these questions.

Minutes 0–5. Context.

  • "Which project in your portfolio are you proudest of, and why that one?"

Minutes 5–15. One case, in depth.

  • "What was the problem, in one sentence?"
  • "What did you decide not to build?"
  • "Show me a state that isn't the ideal screen: empty, error, loading."
  • "How did you know it worked?"

Minutes 15–22. Judgment.

  • "Tell me about an idea you killed, maybe your own."
  • "When did you disagree with a founder or PM, and how did it end?"
  • "If AI tools can generate ten versions of a screen, what is your job?"

Minutes 22–27. Your product.

  • Share your current app or prototype. "What would you ask me before changing anything?"

Minutes 27–30. Working together.

  • Timezone overlap, availability, how they hand off work, whether they can build a working prototype themselves.

Good signs: they ask you questions back, they talk about users and decisions before visuals, they say "I don't know" when they don't. Red flags: they start redesigning your screens in the first five minutes, can't name anything they cut, blame every problem on developers or "the client", or describe outcomes only in adjectives.

Paid test task or reviewing real work?

Reviewing real, shipped work tells you more than any test, because it includes the constraints and compromises a test never has. Start there.

If you still want a test, make it small, paid and close to your real problem: for example, "here is our onboarding, give us your first observations and three questions." Time-box it to a few hours. Judge the questions they ask and the decisions they propose, not the polish. Avoid unpaid "design our app" assignments. Many strong senior designers decline them, so you end up selecting for people with the most free time.

How to check a product designer's references

Talk to a founder or PM who worked with them, not only a fellow designer. Ask:

  • "What was this person's role in the result we see in the portfolio?"
  • "Tell me about a time they pushed back. Were they right?"
  • "How did they work with developers?"
  • "What did they need from you to do their best work?"
  • "Would you hire them again for the same kind of project?"

Listen to the pause before the last answer. It is usually the most honest part of the call.

FAQ

What are red flags when hiring a product designer?

Only polished final screens with no problem or constraints, "we" with no clear personal role, no states beyond the ideal screen, outcomes described only as "users loved it", and redesigning your product in the first minutes of the call before asking a single question about users.

How do I choose a UX designer for my startup if I'm not a designer?

Use the scorecard above while reading portfolios, then run a 30-minute call focused on one case study and on what they rejected. Pick the person whose decisions you can follow and whose past problems look like yours, not the person with the shiniest screens.

What interview questions should I ask a product designer?

Ask about a decision, not a deliverable: what they decided not to build, an idea they killed, how they knew something worked, a state outside the happy path, and what they would ask you before changing your product. Good answers mention users, constraints and trade-offs.

Is a paid test task better than looking at a portfolio?

Reviewing real shipped work is usually more informative. If you add a test, keep it short, paid and based on your actual product, and judge the questions and reasoning rather than visual polish.


Alla Kuchynskaya is a Senior Product Designer and AI Product Designer & Builder with 12+ years in startups, strongest in onboarding, activation and retention. She worked on Flo's chat and tracking screens early on at R-Style Lab and on VOCHI, later acquired by Pinterest. Based in Bali (GMT+8), she works part-time, full-time or per project. Portfolio: alla.studio, Telegram: @aladesigner.

About the author

Alla Kuchynskaya · Senior Product Designer

alla.studio · LinkedIn · Telegram · Resume