Review the evidence signals before interviewing. Then use the anchored descriptions—not instinct alone—to choose the score that best matches each answer.
01
Evaluation factor
Portfolio
35% weight
Check for shipped systems: Figma library structure, token architecture (light/dark, density), component counts, Storybook parity, and adoption metrics across squads and products.
Evidence to listen for
Work exists and can be looked at, not just described
States what they made versus what the team or a template made
Shows range rather than one repeated style
Can walk through a piece from brief to final
Five-point scoring guide
1
Poor
No portfolio, or work that is unattributable or clearly templated.
2
Needs Improvement
Thin portfolio; unclear what they personally made.
3
Satisfactory
Real work with adequate range; contribution mostly clear.
4
Very Good
Strong varied portfolio with clear personal ownership.
5
Excellent
Shows a named system they built or inherited, with token layers, versioned releases, and adoption figures across multiple product teams.
02
Evaluation factor
Craft and rationale
25% weight
Test depth on component API design, variant and slot patterns, WCAG 2.2 contrast and focus states, and how tokens map from Figma variables to CSS or Tailwind output.
Evidence to listen for
Explains why a layout, type choice, or colour decision serves the brief
Knows typography and hierarchy as craft, not decoration
Works to a brand system without either breaking it or hiding behind it
Names the tools they are genuinely fast in
Five-point scoring guide
1
Poor
Cannot explain any decision; work is arbitrary.
2
Needs Improvement
Talks in taste terms only; no link between choice and brief.
3
Satisfactory
Sound craft with some ability to justify decisions.
4
Very Good
Articulate about why each choice serves the brief.
5
Excellent
Explains naming conventions, deprecation paths, and accessibility decisions per component, with reasons tied to engineering constraints rather than taste.
03
Evaluation factor
Feedback and iteration
25% weight
Probe their contribution model: how requests enter the backlog, RFC or proposal reviews, breaking change communication, and what they killed after low usage data.
Evidence to listen for
Takes critique without treating it as an attack
Distinguishes a subjective preference from a real problem, and says so politely
Iterates fast rather than defending version one
Delivers files correctly and on time
Five-point scoring guide
1
Poor
Defensive about critique; will not revise.
2
Needs Improvement
Accepts feedback passively; iterations do not improve the work.
3
Satisfactory
Revises willingly; struggles to push back on weak feedback.
4
Very Good
Iterates quickly and can argue for the work when the feedback is wrong.
5
Excellent
Describes a real intake and review process, cites a component deprecated or reworked on evidence, and handled dissent from product designers.
04
Evaluation factor
Working with the brief
15% weight
Assess how they align with roadmaps: pairing with front-end engineers on Storybook and CI visual regression, running office hours, and documenting usage guidance for non-designers.
Evidence to listen for
Asks about audience and goal before opening the design tool
Works with marketing, product, or clients rather than in isolation
Flags an impossible brief early
Hands over files and assets others can actually use
Five-point scoring guide
1
Poor
Designs in isolation; ignores the brief's purpose.
2
Needs Improvement
Starts designing before understanding the goal.
3
Satisfactory
Asks the right questions when prompted.
4
Very Good
Interrogates the brief up front and hands over cleanly.
5
Excellent
Treats the system as a product with users, publishing changelogs and docs, and negotiates scope with engineering and product leads directly.
Put this rubric to work
Score every candidate against the same standard
Add these weighted factors to Hirevire and let AI evaluate recorded answers against your rubric.
