UX writer design interview questions

As asked

A user's card payment fails at checkout. What should the error message say, and how do you decide what not to say?

Sample answer outline

A good answer is clear, specific where the system knows the cause, and action-oriented without blaming the user. It should distinguish between insufficient funds, expired card, network failure, and unknown decline only if the payment processor safely exposes that reason. Avoid exposing sensitive bank details or implying certainty the product does not have. The message needs a recovery path such as trying another card, checking details, or contacting the bank. Strong UX writers also mention localization, accessibility, and consistency with the product voice.

Expect these follow-ups

• How would you write the same message for a screen reader user?
• What if legal says you cannot disclose the decline reason?
• How do you test whether the copy reduces support tickets?

As asked

Show me how you would rewrite a poor interview question like 'Would this faster checkout make you buy more often?' What are you trying to learn instead?

Sample answer outline

The original question leads the participant and asks them to predict future behaviour, which people are poor at doing. A better line of questioning explores recent behaviour: 'Tell me about the last time you abandoned checkout' and 'What happened next?' Probe for context, alternatives, workarounds, and consequences. The interviewer should avoid selling the solution or naming the desired outcome. Candidates who can rewrite questions on the fly usually understand that research quality depends as much on moderation as on recruitment.

Expect these follow-ups

• How do you probe without making the participant feel judged?
• What do you do when a stakeholder insists on asking solution-validation questions?
• How would you turn interview findings into a survey?

As asked

A shared Button and Dropdown library is used by 30 teams. How do you prevent accessibility regressions as the library evolves?

Sample answer outline

Bake accessibility into component contracts rather than treating it as after-the-fact QA. Use unit tests for keyboard behaviour and ARIA attributes, Storybook accessibility checks for common states, and end-to-end tests for focus movement in realistic flows. Document expected usage and reject APIs that let consumers remove labels or break semantics too easily. Manual screen reader testing is still needed for complex interactions because automated tools catch only part of the problem. Strong candidates also mention release notes and migration guidance because consumers can create regressions even when the library is sound.

Expect these follow-ups

• Which accessibility issues do automated tools usually miss?
• How do you test keyboard behaviour for a composite widget?
• What do you do when a consuming team misuses the component?

As asked

A product team wants one long page that explains the architecture, lists every API field, and walks through setup. How would you restructure it?

Sample answer outline

Split by user intent. Concept docs explain the model and tradeoffs, task docs help users complete a workflow, and reference docs provide exact field-level detail. A strong answer uses navigation, progressive disclosure, examples, and cross-links so readers can move between layers without duplicating content. The candidate should preserve a clear happy path while still exposing edge cases and limits. The usual failure is writing a comprehensive page that is technically complete but unusable because every reader has to scan everything.

Expect these follow-ups

• How do you decide what goes above the fold in a setup guide?
• When is duplication acceptable in docs?
• How do you measure whether the new structure worked?