UX Designer interview scorecard template
A structured scorecard for interviewing a UX Designer: six weighted competencies, what a 1 and a 5 actually look like, and questions that surface evidence instead of opinions. Print it, or copy it into your ATS.
The UX Designer scorecard
| Competency | Weight | Score 1 — what it looks like | Score 5 — what it looks like |
|---|---|---|---|
| Research and problem framing Whether the work starts from a defined user problem with evidence behind it, rather than from a visual direction or a stakeholder request taken at face value. | 18% | Presents finished screens and explains the visual choices; asked what problem the redesign solved, describes the old interface as outdated or inconsistent. | Opens a case with the observed behaviour that triggered the work, how many users were watched or interviewed, and what the team believed beforehand that turned out wrong. |
| Interaction design and flow craft Whether complete flows are designed, including empty, loading, error and permission states, rather than only the path where everything goes right. | 20% | Portfolio shows the happy path in a single viewport; error handling, empty states and permission variants were left for engineering to decide during the build. | Walks through a flow showing failure and empty states as designed artifacts, and explains a specific edge case that changed the structure of the main path. |
| Visual craft and design system discipline Whether the candidate produces consistent, legible interfaces and works inside a system, extending it deliberately instead of inventing one-off components. | 15% | Each screen introduces new spacing, type sizes and button variants; explains the inconsistency as separate projects rather than as a decision with a maintenance cost. | Names a component they added to the system, the cases it had to cover, and what they deprecated or merged so the library did not grow two ways of doing the same thing. |
| Usability testing and iteration on evidence Whether work is put in front of real users before handoff, and whether the candidate can show a design that changed because of what those sessions revealed. | 17% | Validation consisted of design reviews and stakeholder feedback; the tested version and the shipped version are identical, and no session finding is recalled. | Describes a specific test, how many participants and which task they failed, then shows the before and after with the reason the second version worked. |
| Collaboration with engineering Whether designs are made inside real technical constraints and the candidate stays involved through implementation instead of handing off a file and moving on. | 15% | Describes handoff as delivering a link and a spec; gaps between the design and the shipped screen are attributed to engineering not following the file. | Recounts a constraint an engineer raised, the alternative designed in response, and a build review where drift from the design was caught and fixed before release. |
| Accessibility and inclusive design Whether accessibility is built into the design work by default rather than treated as a remediation pass, and whether it can be discussed concretely. | 15% | Treats accessibility as a checklist run before launch, or as a responsibility belonging to engineering; cannot recall a design decision that changed for accessibility reasons. | Cites a specific decision made for keyboard, contrast or screen-reader users, such as reworking a custom control into a native pattern after testing it. |
Weights sum to 100. Agree them before the first interview, not after — adjusting weights once you have scores is how a panel rationalises a favourite.
Questions that surface evidence
Each one asks for something that already happened, in enough detail to verify. Hypotheticals reward rehearsal, not track record.
- Show me a flow you designed and walk me through its empty, error and loading states. Which of those did you discover late, and what changed in the main flow because of it?
- Tell me about a design you changed after a usability session. What did the participant do that you did not expect, and how many people did you watch before deciding?
- Describe a time an engineer told you a design was not feasible. What was the constraint, what did you design instead, and how close was the shipped screen to your file?
- Walk me through a project where research changed the brief. What did stakeholders ask for originally, what did you find, and how did you get the scope changed?
- Pick a component you added to a design system. What existing patterns did you check first, and what did you remove or merge so the library stayed consistent?
Red flags
- Portfolio shows only polished final screens, with no iterations, rejected directions or evidence of what was tested.
- Cannot say which parts of a team case study they personally designed.
- Justifies choices by trends or personal taste rather than by user behaviour or a stated constraint.
- Describes accessibility as something added at the end, or as outside the design role.
How to use this scorecard
- Agree the weights with the panel before anyone interviews, and write them down.
- Every interviewer scores every competency independently, adding a note that quotes what the candidate actually said.
- Compare scores before discussing them. Discussing first anchors the panel on whoever speaks loudest.
Build a custom scorecard → · Boolean string to source a UX Designer →
Frequently asked questions
What should a UX designer interview scorecard include?
Weighted competencies covering research, flow craft, visual and system discipline, usability testing, accessibility and collaboration with engineering, each with anchors for what a weak and a strong answer look like. Weight them for the role: a designer joining a team with a mature design system needs different strengths than one building the first version of it.
How do you evaluate a UX portfolio without being swayed by visual polish?
Ask for the states that are not in the portfolio: errors, empty screens, permissions. Then ask what was tested, what failed, and what the second version changed. Polish is easy to show and hard to attribute; decisions with reasons behind them are neither.
Should a UX designer be given a take-home design exercise?
A short, paid, tightly scoped exercise helps when a portfolio is team-based and individual contribution is unclear. Keep it to a few hours and review it against the same anchors used in the interviews. Scoring the exercise and the interview on one rubric, with specific evidence cited per competency, keeps the two from being compared on feel.
When the stakes are a real hire, use evidence
These tools are quick heuristics. Verdict reads the CV against your job description and scores six dimensions with verbatim quotes as evidence — a hiring document you can defend.