UI/UX design is the discipline of deciding what software says and how a person moves through it: the screens, the flows, the components and the standards that keep them coherent. Nielsen Norman Group defines the instrument of that coherence precisely: a design system is a set of standards for managing design at scale, reducing redundancy and creating a shared language across channels. The measured state of the field says the work is undersupplied. WebAIM's 2025 audit of the top million home pages found 94.8% with detectable WCAG 2 failures, an average of 51 errors per page, with low-contrast text on 79.1% of pages. The people who fix that are a small population: UX, research or UI design professionals are only 0.3% of survey respondents. Hiring for UI/UX design therefore means finding specialists inside a market that has systematically underbuilt them.
Challenges in UI/UX Design Recruiting
Design systems are code with a spec attached
A design system is where user interface design meets engineering governance, and the hiring market conflates the two halves. NN/g's definition sets the bar: standards, shared language, consistency across channels, which in practice means design tokens, component APIs, versioning and the documentation that keeps them true. The candidate population splits accordingly. Design-side candidates own the visual language and the accessibility semantics; engineering-side candidates own the component code, the theming and the build integration. A strong design system hire sits somewhere on that seam and can describe both, and the brief that says only "design systems experience" attracts whichever half is more abundant and misses the other. The interview probe is a governance story: describe the component you changed, who broke when it shipped, and how adoption recovered. Owners of a real system answer with release notes; visitors answer with Figma.
Accessibility is audited, not designed in
The accessibility gap is the sharpest hiring signal in the discipline, because it is measured annually and almost everyone fails. 94.8% of home pages carry detectable WCAG 2 failures, six error types account for 96% of all detected issues, and the failure rate has improved by barely three points in six years. What that means for hiring: accessibility work is being done downstream, in audits and remediation cycles, not upstream in the component library where it is cheap. The specialist you want is the one who designs the fix into the system: contrast pairs that meet WCAG AA thresholds, focus states with visible indicators, heading structure that survives translation, form labels that exist before the form ships. NN/g's guidance makes the same point from the usability side: disabled buttons confuse users, keyboard access must be testable, and assistive technology users are the constraint that exposes every shortcut. Interview for the upstream instincts, because the audit will always find the downstream ones.
Prototyping against real content instead of lorem ipsum
Prototyping is the cheapest form of design evidence, and most portfolios do it wrong: high-fidelity screens with placeholder text, no empty states, no errors, one breakpoint. A prototype that never met real content never tested anything. The discipline of prototyping is fidelity matching the question: the paper sketch that kills a bad idea in an afternoon, the clickable flow that settles navigation, the coded prototype that measures a real task. Screening questions are fidelity questions: what did this prototype deliberately leave out, what did the test falsify, which direction died because of it. Candidates who answer those questions have done UX design work; candidates who present polished screens have done illustration. The same test applies to design systems work: prototyping a component in isolation proves nothing until the component meets the long German label, the empty table, and the screen reader announcing the wrong order.
User interface design and the states nobody drew
The narrow part of user interface design, the part that separates professionals from decorators, is state coverage. Every interactive element carries five or more states: enabled, disabled, hovered, focused, pressed, plus the error state and the loading state that follow. NN/g's guidance on button states documents exactly this burden, and the accessibility literature adds the failure modes: a disabled button that gives no explanation, a focus indicator that vanishes. Portfolios hide all of it, because portfolios show the happy state by default. Hiring has to ask for the inventory: walk the candidate's last form and enumerate its states, its validation timing, its error recovery. Interaction design depth shows up in the answers: which state they inherited badly, what the touch target did to the layout, how the keyboard user reached the control at all. A useful follow-up is the timing question: when does validation fire, on blur or on submit, and what happens to a user who corrects the error mid-flow. Candidates who have shipped forms answer in specifics; candidates who have styled them answer in adjectives.
Product design that stops at the handoff
Product design is a decision discipline wearing a visual discipline's clothes, and the market is full of the visual half. The split is observable in a portfolio walk: a product designer narrates the problem, the constraint, the rejected direction and the metric that moved; a visual designer narrates the screens. Both are hireable, and the brief must say which one the seat needs. The 0.3% role share in the developer survey understates the spread, because the title absorbs so much: someone owning funnel charts and retention trade-offs, someone owning the component library, someone owning the brand. The hiring failure is hiring the brand owner for the funnel job. The correction is to ask for the constraint story: what did the business refuse to let you change, how did the design absorb it, what shipped anyway. Product design experience is constraint experience, and constraints are the one thing portfolios do not screenshot.
Usability evidence a portfolio review cannot carry
Portfolios prove taste; they do not prove usability, and usability is the discipline's technical core. Verification has to go after the evidence trail: the test that failed, the task success rate before and after, the heuristic review that found the navigation problem, the WCAG AA failure the audit caught and the component change that fixed it. Ask for a design decision the candidate made that was wrong, and how they found out: real usability practice produces falsification stories, because that is what the discipline is for. The cost of skipping the evidence hunt lands late. A weak senior design hire ships a redesign without measurement, normalises a design system nobody adopts, and pushes accessibility into a backlog that blocks the next release. Human-computer interaction is the field's oldest name, and it is also the honest job description: the person you hire will shape the interface every customer meets, which is exactly why the interview should demand the evidence a portfolio cannot show.
References
- Design Systems 101 — Nielsen Norman Group. (accessed 2026-09-28)
- The WebAIM Million: The 2025 report on the accessibility of the top 1,000,000 home pages — WebAIM. (accessed 2026-09-28)
- Accessibility Articles, Videos, Reports, and Training Courses — Nielsen Norman Group. (accessed 2026-09-28)
- Web Content Accessibility Guidelines (WCAG) 2.2 — W3C. (accessed 2026-09-28)
- 2025 Stack Overflow Developer Survey: Developers — Stack Overflow. (accessed 2026-09-28)