UX writer at Miro

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

Walk me through how you decide what to write for a call-to-action button. What makes one CTA stronger than another, and how do you test your instincts?

Sample answer outline

Strong answers cover specificity over vagueness ("Save your report" beats "Submit"), verb-first construction, alignment with the user's mental model of what happens next, and the role of A/B testing or usability studies to validate copy choices. Candidates should mention how context (risk level, reversibility) shapes tone.

Expect these follow-ups

• Give me a before-and-after example from your own work where changing a CTA meaningfully improved conversion or user confidence.
• How do you handle a stakeholder who insists on "Learn More" everywhere?

As asked

Describe the components of a good error message. If a user's payment fails, what does your ideal error message say, and why?

Sample answer outline

A strong answer identifies: what went wrong (plain language, not system jargon), why it happened if known, what the user can do next, and reassurance where appropriate. Candidates should address tone, avoiding blame, avoiding technical codes in consumer-facing text, and the difference between validation errors and system errors.

Expect these follow-ups

• How would your error message change if the payment failed due to a known bank outage versus an incorrect card number?
• What do you do when engineering can only expose a generic 500 error?

As asked

A lot of teams confuse voice and tone. How do you explain the difference to a new designer you are onboarding, and how does that distinction change your day-to-day writing decisions?

Sample answer outline

Voice is consistent and represents brand personality, tone shifts with context and user emotional state. A strong answer gives a concrete analogy (same person speaks differently to a nervous customer versus a celebrating one), then explains how this maps to product surfaces like error states, onboarding, and success screens.

Expect these follow-ups

• Give me an example of a moment in a product where the tone should be noticeably different from the general brand voice.
• How do you document this distinction so it is usable for a non-writer on the team?

As asked

You are writing copy for a five-screen onboarding flow for a new productivity app. How do you think about what each screen needs to say, how to pace information, and what to defer?

Sample answer outline

Strong answers show understanding of progressive disclosure, the cost of cognitive overload in onboarding, deferring non-essential setup to contextual moments, and keeping copy anchored to user value rather than feature explanation. Candidates should mention working with UX researchers on drop-off data to iterate.

Expect these follow-ups

• How do you decide what is essential to show in onboarding versus what can wait until first use?
• How do you write for users who skip onboarding entirely?

As asked

What is the difference between a field label and placeholder text, and when should you use each? What is the most common mistake you see teams make with placeholder text?

Sample answer outline

Candidates should explain that labels are persistent and essential, placeholder text disappears on focus and fails accessibility standards when used as the sole label, and the most common mistake is using placeholder text instead of a label. Strong answers mention contrast, screen-reader support, and the pattern of persistent labels with optional helper text below.

Expect these follow-ups

• How do you handle a design that has no space for a label above a field?
• What do you put in placeholder text when you do use it alongside a label?