Strings Intelligence | 5 min read

The Right Words

The best digital products have ridiculously memorable personalities. Gmail’s “Oops! Something went wrong” to Slack’s “What a day! What cannot be accomplished on such a splendid day?” and Postmates’ “Anything, anywhere, anytime. We get it.”

The content strategy underlying these product personalities is deliberate – something their product content teams built up to over years of copy iteration and on top of robust content strategy frameworks. From the beginning, these teams cared about words.

The field of UX has given birth to hundreds of great tools aimed at helping teams build better products. Design and wireframing apps, prototyping and usability feedback tools, session recording and heat mapping programs, event tracking and user analytics — all are helping managers build richer user experiences. But the UX industry largely overlooks words, making the inevitable handoff –one handoff, sometimes two, between product and design to engineering — perilous for product teams that care about content. The words are the experience.

Text lives in code

The reason it’s harder to manage application content — whether native or web-based — is because for product teams, there’s no content management system for product content. Text lives in software files, alongside source code. That means that the text users see across interface, pop-ups, help text, notifications, and onboarding flows are coming from dozens of different files. Even on a single screen, text is often getting pulled from multiple locations.

These software files live in teams’ GitHub or BitBucket repositories, with engineering responsibility is divided by service or technology, not by screen or user journey. Any product manager who has tried to change “BACK” to “Back” across a whole UX or even harder, tried to lighten up an overall tone or inject some personality into product text, has faced this reality.

Code is managed via sprints…

For most product teams, it’s the development sprint that drives the copy that’s required for a product. As well-intentioned as teams are at the beginning of a sprint, not all states of a product are anticipated, nor is it fun (or easy) to mock up error states. The result is that a significant portion of the words a user ends up interacting with is written by engineers. These happen to be the words that a user sees when things don’t go as expected in the app, which is even worse.

Writing product copy a sprint at a time ends up being like shipping a book one chapter at a time — a book without a story arc, as most products evolve organically. In contrast, a strategic approach to product content would include pre-shipping checks for:

  • Tone of voice
  • Terminology
  • Brand guidelines
  • Emotional response
  • Table stakes: grammar, spelling, punctuation
  • Consistency of product content across all platforms (ie, mobile and web)
  • A strategic approach would also include periodic audits and holistic iterations – a content sprint.

…text should be managed by strategy

Iteration, collaboration and revision are all necessary for solid product content, and there are ways for product teams to work around the development-driven sprint cycle to establish a good strategy:

Easy 💪:

  • Do: Actualize your style guidelines and educate your whole product and engineering team on them. What is your nomenclature? What are the capitalization rules? Do we use emoji? All emoji but the 💩 one? Provide clear examples. We do this, we do not do that. Provide guidelines on what happens in smaller spaces and in non-English languages.
  • Try not to: Write down hundreds of rules, PDF them, and ask engineers to remember them. Make your rules simple, easy to remember, and repeat, repeat, repeat. Don’t try to write all the copy yourself. Your product has hundreds of error messages: engineers will have to write most of them. Tools like Qordoba can help alert you when one of them has deviated from your guidelines, but you will need their front-line support.

Medium 💪💪:

  • Do: Use keys to denote text in source code. An absolute must if you are going to add other languages or try alternate UX experiences. A key is a representation of text in source code – the text itself lives in something like a resource file. The combination of the key and the text is called a string value pair.

  • Try not to:  Ask engineers to add keys for strings without developing some guidelines for them on how to name those keys. Your engineers’ key naming strategy is closely tied to product content strategy.  If it’s an error message, get that into the key. If it’s a pop-up, indicate that, too. The same interface will have different keys across various platforms — ie, across your iOS, Android and React app, for example — so it’s important to have enough information to which keys.

  • Bad keys invite namespace collision, so <helptext> would be bad where <help001> would be better.
  • Bad keys invite ambiguity, so <name> would be bad where <namefull> or <namefirst> or <namelast> would be better.
  • Bad keys provide no clue to the engineer, so <c3ea88d0-3cff-4654-b280-3886b7d4ac6c> would be bad where <Qid-5A0B3CB3-Vsa-Helptxt> would be better.

Writing product copy a sprint at a time ends up being like shipping a book one chapter at a time — a book without a story arc, as most products evolve organically.

Harder 💪💪💪:

Do: Think about whether segmenting your audience would result in a better user experience. Once all of your product content is tied to keys and exists in a resource file, it becomes possible to experiment with what the strings say. Many teams will add additional languages this way, but we’ve seen forward-leaning product teams create separate product content experiences for different audiences within their main language. One product team in the hospitality industry uses strings to personalize the product UX by sub-brand, and another product team in the consumer mobile space personalizes by age — millennial-speak for the under-20 set and plain English for the rest of us.

Try not to: Overthink product personalization. Data shows that tone matters and emotional resonance matters. If you have two personas, go ahead and do the rewrite. If you have 20 personas, think about personalizing the experience by brand or use case instead.

Do you copy?

Great product copy is heading the way of great design: table stakes for what users consider good UX. A product experience so seamless it’s invisible — that’s the goal for most product teams. The right words make that happen.

Related articles