When copy components work — and when they fail

Jürgen Zimmermann
Jul 1 · 5 min read

Over the years I half convinced my employer (an African mega bank) that UX copy is an important Thing that deserves active inclusion in the design process. Now that we UX writers are stricken with the curse of legitimacy, I’ve started working on how best we can automate the job of delivering UX copy.

We reuse design components. Why not do it with UX copy?

Reusing design components isn’t a new idea. A UI designer typically designs a button only once before dumping it into a template or a design system where it snugly waits until it’s summoned for future re-use. Similarly, UX designers build flows based on established patterns and previous work. Nobody designs in a vacuum anymore. We don’t need to.

I’ve started standardising various copy components like CTAs, labels, empty states and messaging. These bits of copy already have a history. We know where to use them, and how. They’re just there, like an old cat curled up in a corner. No need to worry about those words; they can look after themselves.

Some UX copy is like an old cat. No need to worry about it…

Should you bother listing words as components in the first place? I think so, yes. In my mind there are three reasons why it’s worth the effort:

Reason 1: Fresh copy costs brain cells, so please recycle

UX writers rarely have the time or mental capacity to deliberate upon the precise wording of, say, an address field label. We should already know what the label will say. That standard label should live in a copy component list — and the list should live in your design system (more on that below).

Here’s an example. Is the place where you live your ‘home address’, ‘physical address’ or ‘residential address’? All are correct, but you should test them, choose one — and try to stick to it. There’s no need to debate their relative merits several times over.

Reason 2: Words are part of your design patterns

Strong design works in patterns. Words should work in patterns too. Some examples:

  • A success message should contain the word ‘success’ or ‘successful’, along with a tick and green font / background, e.g.
  • An error message should include a red UI element and typically consists of two parts: a problem statement and a resolution, e.g.
  • A modal interrupts a journey and should always be phrased as a question, while the header’s verb should be repeated in the expected call to action:

When UI and copy components are consistently used together users will quickly learn your patterns and get stuff done faster. Hooray!

Reason 3: Copy components belong in a design system

A kinda-sorta third reason is that copy components can Make the World a Better Place if you integrate them into your design system.

Consider this reality-inspired chat between a writer and a designer:

> Designer: ‘OMG we need a button here!’
> Writer: ‘Use the button component. Here it is.’
> Designer: ‘Good. But what will the button actually say?’
> Writer: ‘Look at the CTA copy components. One of them should work.’
> Designer: ‘Yeah? OK neat, thanks!’

The conversation above is the UX copy equivalent of a rogue comet narrowly missing our planet. Without predefined and reusable copy components, teams that don’t enjoy the paradise of dedicated copy support will make up the words as they go along. Given that I’m the lone content strategist in this menagerie, that’s a problem. Feral teams give me nightmares, hives and nosebleeds. At the same time.

This is me, dreaming about feral teams writing their own copy…

My recommendation? Use all your powers to give your offsite / unsupported teams every conceivable resource and tool they’ll need to help themselves. You can never guarantee that their copy will be wonderful, but at least you’re helping establish some kind of baseline. Unremarkable functional copy is always better than utterly fucked copy.

Where copy components fail

Copy components used in simple, often-repeated tasks should work just fine. Let’s say you’re buying data via an app. People do this a lot. There’s no real emotional angle, no massive risk involved. If we were then to design a feature for buying airtime — a very similar task — then we should reuse over 90% of the copy we used for buying data. Sure, we’ll test it, and if a piece of reused copy doesn’t work we’ll change it. We’re not savages.

By contrast, trying to automate copy based on conversations that are intended to elicit an emotional response isn’t going to work, at least not consistently. You certainly can build wordlists that lean towards some type of persona and / or their emotional states — but this kind of copy will probably* never write itself.

For example, let’s say you previously wrote copy for a site that sells surfboards. Far out. Your next project is a site that sells coffins. Try using the same copy components you established on surfsup.com in coffinup.com. It won’t work because your users and the journeys they’re going through are too different. Consider your users’ feelings and priorities:

Surfer:
>
Likes surfing, obviously
> Into positive thinking & foam
> Dislikes wave hogs
> CTA = HIT THE TUBE

Coffin buyer:
> Bereaved, probably
> Grudge purchase
> Intrigued by cremation options
> CTA = LAY TO REST

Your clever copy components that focus on Bodhi’s interests won’t work on less enlightened people — so don’t bother.

You get the picture. Clearly your surfercentric copy components won’t work on coffin browsers — so get off your automated arse and write some genuinely unique, ‘punchy’, wordsmithy-crafted empathetic copy, m’kay?

The punchline: You can automate copy that deals with common design elements, simple tasks and well-understood patterns. However, automated copy won’t work well for unique and complex journeys that require a strong emotional element.

* I say ‘probably’ because robots.