UX / UI Designer Assessment

Why UX and UI Designers are hard to hire well

The case study format has quietly become the whole hiring process, and it is a genre with conventions. Ambiguous problem, sticky notes, a persona, three wireframes, a polished final screen, and a percentage at the end. The percentage is almost never attributable, because the redesign shipped alongside a pricing change, a new onboarding email, and a marketing push. Everyone in the room knows this and nobody says it, so the ritual continues and teams keep selecting for whoever tells the story most fluently.

The job title is also doing too much work. UX and UI have been welded together in job adverts for a decade, and the two halves demand genuinely different aptitudes. One is a research and structure problem: what is this person trying to do, what is in their way, what is the shortest honest path. The other is a craft problem: type, spacing, contrast, states, motion, and the discipline to make eighty screens feel like one product. Plenty of excellent candidates are strong at one and adequate at the other, and a hiring process that never separates them will keep being surprised in month three.

Then there is the constraint nobody screens for, which is that the interfaces designers actually get to make are shaped less by users than by what engineering can build this quarter and what the loudest stakeholder believes. The measurable difference between designers is not who produces the best screen in a vacuum. It is who produces the best screen that gets built, which requires knowing what to concede, what to defend, and how to tell the difference at speed. A portfolio shows you the artefact. It cannot show you the negotiation that produced it.

What separates the best from the rest

Strong designers design the whole state machine, not the happy path. Empty, loading, partial, error, offline, permission denied, first run, thousandth run. This is the bulk of the actual interface and it is where products feel cheap or feel considered. Ask a weaker candidate for the error states and you get an apology and a promise to add them later, which in practice means an engineer invents them under deadline and the product ships with three different tones of voice for failure.

They also read research honestly, including when it is inconvenient. A usability session that contradicts your own design is unpleasant, and the tempting move is to explain it away: the participant was unrepresentative, the prototype was rough, the task wording was leading. Sometimes that is even true. The distinguishing behaviour is that the good designer separates the finding from the interpretation, brings the evidence rather than the conclusion, and proposes the smallest change that would test the hypothesis. Designers who cannot do this produce work that is either untested or unfalsifiable, and both are expensive.

The third difference is handover. A design is not finished when it looks right, it is finished when someone else can build it without guessing: named components, defined spacing, stated behaviour at each breakpoint, contrast that meets the standard, focus order that makes sense to a keyboard. Designers who work this way are described by engineers as easy to work with, which sounds like a personality trait and is actually a craft one. The cost of the alternative is paid in Slack messages every day for the length of the project.

Why interviews alone fall short

Portfolio reviews test narration under friendly conditions. The candidate picked the projects, controls the order, and has told the story before. Interviewers, wanting to be fair, ask open questions, which hands even more of the frame to the candidate. What you learn is how someone explains design, and explaining design well is a real and useful skill that is not the same as making the decisions. The correlation between the two is positive and much weaker than the process assumes.

The whiteboard exercise, the usual counterweight, tests performance under an artificial pressure that resembles nothing in the job. Nobody designs a flow in forty minutes while three strangers watch and take notes. It reliably disadvantages candidates who think slowly and carefully, which is a description of many of the best designers, and it rewards verbal fluency for a second time in the same process. Teams often run both and believe they have triangulated, when they have measured one trait twice.

Situational assessment gets at the part neither format reaches: the routine, consequential judgement calls. Which of six pieces of stakeholder feedback is a usability problem. Whether to spend the remaining sprint on accessibility or on the animation everyone liked. What to do when the research sample is small and the deadline is real. These decisions happen weekly, they compound, and every candidate faces exactly the same version of them, which is the only way to get a comparison rather than four unrelated impressions.

Common hiring mistakes in UX and UI recruitment

• Treating the case study as evidence - it is a rehearsed narrative with the failures edited out, and the metric at the end is rarely attributable
• Never separating UX from UI - the advert asks for both, the role usually needs one badly, and the process tests neither in isolation
• Testing verbal fluency twice - a portfolio walkthrough and a whiteboard exercise measure much the same trait and feel like two data points
• Skipping the unhappy states - error, empty, and loading screens are most of the real interface and almost none of the portfolio
• Ignoring accessibility until legal asks - contrast, focus order, and keyboard paths are cheap in design and expensive in retrofit
• Hiring for craft into a role that needs influence - if design has no seat in prioritisation, the strongest visual candidate will leave within a year
• Assessing handover by asking about it - everyone says their specifications are clear, and the engineers who inherited them are the only reliable witnesses

The work this role is assessed against

• Facilitate workshops covering ideation, prioritisation, and story mapping
• Produce wireframes, prototypes, and UI specifications for developer handover
• Plan and conduct usability tests, and synthesise findings into actionable insights
• Audit and improve accessibility against WCAG and responsive behaviour across breakpoints
• Partner with analytics to define UX metrics and evaluate A/B or multivariate tests

Tools and outputs this role works with

Figma, Sketch, Adobe Illustrator, Adobe Photoshop, Adobe XD, FigJam, Miro, Whimsical, Zeplin, Storybook, Jira, Confluence, Notion, Google Analytics, Amplitude, Mixpanel, Hotjar, FullStory, UserTesting, Maze, Lookback, Optimal Workshop, Axe DevTools, Stark, Lighthouse, Framer, ProtoPie, and Principle.