UX writer 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 localisation, 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 new project management app shows an empty dashboard after signup. Write the empty state strategy, not just the headline.

Sample answer outline

The empty state should orient the user, explain why the space is empty, and provide one primary next action. The copy should reflect the user's stage: a first-time user needs setup guidance, while an established user with no tasks may need reassurance or a filter reset. Avoid generic cheerleading and avoid presenting three equal calls to action. Pair the message with an affordance such as creating the first project, importing tasks, or using a template. Senior candidates connect the copy to activation metrics and onboarding research rather than treating it as decoration.

Expect these follow-ups

• What would you change for an enterprise admin setting up a team?
• How do you decide whether to use a template gallery or one primary button?
• What metric would tell you the empty state is working?

As asked

You are writing product copy for a settings flow that will ship in 12 languages. What do you do differently from day one?

Sample answer outline

Write concise but complete strings that do not depend on English word order, humour, or visual position. Avoid concatenated fragments because many languages need different grammar, gender, pluralisation, or sentence order. Provide translators with context: screenshots, character limits, tone notes, and variable meanings. Work with design to allow text expansion and with engineering to support ICU-style plural and select rules. Candidates often mention translation late; senior UX writers design the content model and review workflow so localisation is not a last-minute string export.

Expect these follow-ups

• How do you handle a button label that grows by 40 percent in German?
• What context should a translator receive for an error message?
• How would you review machine-translated UX copy?

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?