A hotel booking site's thirty writers across product teams produce messages ranging from stiff to jokey; how would you write tone guidelines that keep them aligned?
answer
- drift comes from a missing shared reference
- voice once, with 'not' limits
- a tone map by context
- real do/don't pairs with reasons
- review the high-stakes messages
basics
~20 sDefine the voice once as a few attributes with limits, then publish a tone map: per context - error, warning, success, onboarding, destructive action - the reader's state, the tone and a do/don't pair. Back it with review and audits.
solid answer
~40 sDrift means each writer is guessing, so the fix is a shared reference plus a habit of using it. First, the voice: three to five attributes, each with a limit - *warm, not gushing*; *clear, not curt*. Second, a **tone map**: one row per context the product actually has - onboarding, search with no results, booking confirmed, payment failed, sold out, cancellation - with the reader's likely state, where the tone dials sit, and a real **do/don't pair** with the reason. Third, a bank of approved real messages writers can copy from. Then make it stick: a content reviewer for high-stakes messages such as payments and cancellations, a short onboarding session for new writers, and a periodic audit that samples messages against the map and feeds fixes back into it.
go deeper
Know that tone guidelines give examples of the right and wrong tone for common contexts, and look them up before writing an error or warning.
Explain the parts of a tone guideline - voice attributes with limits, a tone map by context and do/don't pairs with reasons - and why pairs teach faster than adjectives.
Show how you would diagnose drift across many writers, build the tone map from real messages, and make it stick through review, an examples bank and audits.
Weigh central content review against team autonomy and speed, deciding which messages justify a review gate and which rely on guidelines alone.
## Why writers drift When thirty people write interface text for one product, each fills gaps with their own instinct. One team, used to legal copy, writes stiffly; another, influenced by the marketing site, adds jokes everywhere. Nobody is wrong by their own standard - there is no shared standard. Drift also compounds: new writers copy whatever message sits nearest, so one jokey error becomes the template for ten more. **Tone guidelines** give every writer the same reference and turn 'does this sound right?' into a question with an answer. ## The voice foundation Start with what never changes: - **Three to five voice attributes**, each with a limit: *warm, not gushing*; *clear, not curt*; *knowledgeable, not showing off*. - **A one-paragraph description** of who the product sounds like - for a hotel booking site, perhaps a well-travelled friend who is good at logistics. - **What the voice never does**: blame the reader, use jargon, joke about money or safety. The voice is the fixed range; everything else in the guideline is about where tone sits inside it. ## The tone map The core of the guideline is a table of the contexts the product really has: | Context | Reader's state | Tone | Do | Don't | |---|---|---|---|---| | Onboarding | Curious | Encouraging, light | Tell us where you're headed. | Welcome, adventurer!!! | | No search results | Mildly frustrated | Helpful, matter-of-fact | No rooms match. Try other dates. | Bummer! Nothing here. | | Booking confirmed | Relieved | Brief, warm | You're booked for 12-14 May. | WOOHOO! Pack your bags!!! | | Payment failed | Anxious | Calm, plain | Your payment didn't go through. | Oops! Card gremlins! | | Cancelling non-refundable | Deciding | Serious, neutral | You won't get back the 420 euros paid. | Sure you want to waste this? | Each row should also carry the **reason** - 'the guest is worried about losing the room, so reassure with a fact and point to the next step' - because the reason is what lets a writer handle a context the table does not list. ## Writing good do/don't pairs Pairs teach faster than adjectives, but only if they are built well: 1. **Use real messages from the product**, not invented ones, so writers recognise the situation. 2. **Make the 'don't' a plausible mistake**, the kind someone actually shipped, not a straw man. 3. **Change only the tone between the two**, so the lesson is clear; if the facts differ too, readers learn the wrong thing. 4. **Attach a one-line reason** tied to the reader's state. 5. **Cover the hard contexts first** - failures, warnings, destructive actions - where drift does the most harm. ## Making the guidelines stick A document nobody opens aligns nobody. Useful habits: - **An examples bank** of approved real messages, searchable by context, so writers start from something good. - **Review for high-stakes messages**: payments, cancellations, account problems and anything legal go past a content lead before shipping. - **Onboarding** for every new writer, including engineers and designers who write copy. - **Lightweight checks**: some teams add a content linter or a review checklist that flags words such as 'Oops' in error strings or stacked exclamation marks. - **Copy in design review**: interface text is reviewed alongside layout, not pasted in at the end, so tone problems are caught while the screen can still change. - **A named owner** who updates the map when the product gains a new context. ## Measuring alignment - **Periodic audits**: sample messages from each team, score them against the map, and share the worst and best examples. - **Support signals**: tickets and complaints that quote interface text often reveal tone failures. - **Research reactions**: in usability sessions, note where participants respond to wording rather than to the task. Feed every finding back into the map as a new row or a better pair. Tone guidelines are a living reference, not a one-off launch. Share audit results openly across teams. A visible record of rewritten messages - before, after and why - teaches more than the rulebook, and when a rewrite measurably lowers retries or support contacts, it shows teams that tone affects outcomes, not only taste.
- Engineers write many of the error messages; how do you get them to follow tone guidelines?Make the right thing the easy thing. Give them an examples bank they can copy from, short templates for common failures, and a lightweight check such as a review checklist or linter that flags jokes and stacked exclamation marks in error strings. Route payment and cancellation messages through a content reviewer. Engineers rarely resist guidance; they resist guidance they cannot find at the moment they write.
- How do you handle a context the tone map does not cover?Go back to the reason column. Ask how the reader is likely feeling and what they could lose, find the nearest row with a similar state, and set the tone dials the same way. Then add the new context to the map with a do/don't pair, so the next writer does not have to reason it out again.
saying these in an interview costs you the question
- A list of brand adjectives is enough for writers to get tone right.
- Do/don't examples can be invented, since the principle is what matters.
- Once published, tone guidelines need no review or updating.
- Each product team should write its own tone guidelines for its area.
- Only professional writers need tone guidance, not engineers or designers.