Skip to content

From strings to language systems

When no writer sees most of the words before a customer does, content design becomes the work of defining patterns, intent, tone, and constraints that people and models build from. One worked entry, built on a real pattern, shows what that looks like.

My team's most settled content pattern is the confirmation message, and its one rule is to reassure first and then confirm the details. Here is that pattern written as a language system entry, the way I would want it handed to a model or a new teammate. The wording in the two example outputs is illustrative, and the structure of the entry is the point.

  • Pattern: reassure first, then confirm the details of what was done, then name the next step if there is one.
  • Intent: leave the person certain it worked and sure of exactly what changed.
  • Tone range: calm and warm, sized to the moment, so a small action gets one line and a consequential one gets the details.
  • Constraints: name what changed in the same terms the screen used when the person chose it; one next step at most; terms come from the shared glossary.
  • Small action (illustrative): "Done. Your reminder is set for Monday at 9:00 AM."
  • Consequential action (illustrative): "You're all set. Your plan change is saved, and it takes effect on your next billing date. You can undo it from Settings until then."
  • Grading: four yes or no checks: it opens with reassurance, states what changed in the screen's own terms, names the next step only when one exists, and matches its length to the size of the moment.

A model asked to write this message gets the whole entry as its instructions, a writer reviews against the same four checks, and a vague disagreement ("it feels off") becomes one of four specific failures that someone can fix. The entry also scales in a way a list of approved strings cannot: a team that has this one moment worked out can write the entry for a cancellation, a saved draft and a sent invitation by changing the pattern and the tone range and keeping the structure.

Why the words need a system at all

A growing share of the words in a product are generated or templated at runtime, and no writer will see them before a customer does. A Working in Content session describes the move from interface-level copy to language system design, serving end users, internal teams and machines at once. Each field in the entry above answers a question a model would otherwise answer by guessing, and the answers sit in one place where the next person can edit them.

The pattern field fixes the order of the parts and carries examples good enough to copy, because a model and a new teammate both imitate the examples before they follow the description. The intent field matters most when a model writes the words, since without it the model optimizes for fluency and produces something smooth that serves no purpose in particular. The tone range states how far the dial may turn while the voice stays constant, and the constraints field holds the length limits, required and banned terms, reading level, accessibility requirements such as link text that makes sense out of context, and the topics that always get a fixed response. Booking.com's writers used fixed templates for sensitive topics and generated language everywhere else (their account), and a constraints field is where that division gets recorded.

Keep the terms in one place

Product terms need one glossary that the prompts, the templates and the UI strings all read from. When a name is written separately into a prompt, a fixed disclaimer and a set of labels, the copies drift apart and someone ships a screen that uses a term the product retired. A language system wants a single source for terms and patterns, generated or referenced from every place that needs them, with a check that fails when a copy disagrees.

Where it lives

The language system belongs beside the components in the design system, versioned the same way and reviewed through the same contribution model, and its documentation has to be readable by the engineers writing prompts, the designers composing flows and the agents generating text, which is the standard argued in how to write component documentation that people actually read.

Pick one moment where the words are generated or templated today and fill in the same fields for it, with two example outputs and a handful of grading checks, before anyone writes production copy.

Greg Sargent
Greg SargentDirector of Design Systems, Spring Health

I write about design systems, accessibility, and the way AI is changing how we build software.

Published September 29, 2026

Be the first to rate this article.