This article is written as a working review tool rather than a universal formula. Apply the parts that match the product, evidence and constraints in front of you.
Look for decisions, not only polished screens
A strong portfolio should explain what made the product difficult, what the designer owned and why a particular flow or hierarchy changed.
Beautiful screenshots are useful evidence of craft, but senior product work also needs evidence of judgment.
Ask about states and constraints
SaaS and Web3 products are full of permissions, waiting, failures, signing, review and operational exceptions. Ask how the designer handles the parts that do not fit the happy path.
The answer reveals whether the work is screen decoration or product behavior.
Evaluate collaboration with engineering
Look for responsive rules, state coverage, design-system thinking and examples of implementation QA. A designer does not need to be a front-end engineer, but understanding how decisions survive the build reduces expensive ambiguity.
Ask what typically changes after engineering sees the design.
Check whether the domain language is earned
A portfolio can mention SaaS, fintech or Web3 without demonstrating the trust, workflow or technical constraints that make those products different. Read the case study closely enough to see whether the domain changed the design decisions.
Specificity is more convincing than a long tool list.
Use the first conversation to test product thinking
Bring a real problem, not a hypothetical design exercise. See how the designer asks about users, evidence, business constraints, engineering limits and the decision the interface needs to improve.
The quality of those questions often predicts the quality of the collaboration.