Writing for scale: how to build a taxonomy that future-proofs your product copy.
Imagine this: you’ve been tasked with writing the copy for a major new feature. The release plan is staggered, and you need to design for what’s up ahead.
You do some digging, and realise that everyone in your organisation describes each aspect of the feature in different ways. There’s jargon and tech speak everywhere. And 3, even 4, different names for the same thing.
At best, this is making it tricky for product teams to talk to each other. And at worst, technical gobbledygook is seeping out into the real world, confusing and alienating your beta testers.
Full disclosure: this was me when I started work on TransferWise’s multi-user access beta programme. We had to get our words under control.
What we needed was a language system — a taxonomy. Something to define what we say and how we say it.
How to design a taxonomy in 10 steps
Step 1: Do some digging
First up, ask questions. Lots. To explain a new feature, you need to understand exactly how it works. I always immerse myself in the details and soak up all the information I can.
Now’s a good time to befriend your product designers, researchers, product managers and developers too. You’re going to need their help throughout this process. (If in doubt, chocolate coated bribes normally do the trick.)
Step 2. Listen up — customers say it best
If you’re building this, you already know customers need it. They might not know it yet, but they need it.
It’s probably cropped up in things like user interviews, feedback surveys, feature wish lists, net promoter score comments, popular search terms, and customer contacts.
Time to get your spade back out because this stuff’s a writer’s gold mine. The more you reflect the language that people naturally use, the more human your product sounds.
I’m like a car park attendant looking for a promotion — I note down everything.
You should too.
Keep a list of the exact words and phrases you hear from customers. Copy them down verbatim, and watch the patterns emerge.
Step 3. Know your own lexicon
Wait? What’s a lexicon? Some fancy new Shoreditch restaurant…? A Pokémon..? No. It’s even cooler…
It’s your product’s vocabulary — aka a fancy name for the words in your product.
Whenever you introduce a new feature, you need to work out how it fits with what you already have.
Start with an audit of your existing terminology. Look at how you describe the main parts of your product. Do you have a family of features this needs to fit in with? Are there any language conventions already in place? How are you labelling calls to action?
I always check the words in design, too. When you see a name, button or label in context, you’ll also see what it’s in close proximity to. And you can avoid choosing words that sound confusingly similar.
Step 4. Suss out the competition
The words you choose depend on when you’re building: is it a well-established feature, or something that’s first-to-market?
If it’s well-established, and everyone else calls it the same thing, you probably should too. Unless there’s a really good reason not to.
That’s because if you change an established naming convention, you’re asking users to unlearn all the mental models they’ve already been taught elsewhere — making your product both less convenient, and less accessible to them.
But if, on the other hand, you find that your competitors are all using different names, or you’re doing something that nobody else has ever done, go with what you think works. Take inspiration, sure. But you make the rules now.
Step 5. Work your magic
I’m not here to tell you how to write. But I can tell you how I do it: Brainstorm, draft, then refine.
I start by filling the nearest whiteboard with all the ideas. Even the rubbish ones. They can lead you to interesting places.
A few tips to keep in mind:
- Never lose sight of your audience — users come first.
- Think about how you’re positioning the feature — what associations are your words conjuring? Are there different angles you could explore?
- Plan for the future — how this will fit with upcoming features on your product roadmap? Good copy scales with your product.
- Keep the words short — a good rule of thumb is to always leave 30% more character space for translations.
- Choose simple words that are accessible to everyone — and if you’ve got a global audience, check they translate well too.
- Sprinkle in your own creativity — this bit goes without saying!
Step 6. Test, iterate, repeat
If you haven’t user tested it, don’t ship it.
Show it to customers, then listen, listen, listen. Soak it all up, like an insight sponge.
Step 7. Bring your product team along for the ride
It’s worth investing time in this bit. Your success depends on your product team — you need their support when it comes to rolling this out.
Help them understand what problem the taxonomy solves, but most importantly why. And give them the opportunity to challenge your ideas. You may be the expert, but they’ll often have context you don’t.
For me, the best way to do this was to get everyone in one room. I like to present previous ideations in a slide deck, too — so people can ask questions about the alternatives I toyed with, throw in new ideas, and come to conclusions on their own.
Step 8. Take it to a crit
If you’re part of a writing team, get feedback from your peers. I took my work to a crit and came away with some great advice.
Just make sure you frame the kind of feedback you need to keep the conversation focussed — and be crystal clear about what stage in the design process you’re at.
(What’s a crit? That’s just tech talk for critique. We haven’t got time for full words… We’re too busy solving customer problems.)
Step 9. Create a single source of truth. And make it shareable!
When you release your taxonomy into the wild, you don’t want version control issues tripping it up. So have one source of truth.
I documented our taxonomy on a Confluence page. The link’s pinned to our product team’s slack channel, so anyone from the team can see it and share it if questions come up.
Step 10. Tell everyone (and their dog)
Congratulations! You’re now the proud creator of a brand new taxonomy. You’ve agonised over every word, and you’re pleased as punch. You imagine this is how Michelangelo felt when he put the final brush stroke on the roof of the Sistine Chapel.
But… if your product team doesn’t know how to use it, it’s useless.
You’re not here to create art. You’re solving a problem.
So you need to put as much effort into the roll-out as you do in creating your taxonomy. This takes stamina, but it’s worth it in the end.
By now, your immediate team should know about the taxonomy. You’ll need them to be your advocates. If they’re confident enough to articulate your choices when you’re not in the room, you’re winning.
Next up, spend time with people in Customer Support. They’ll use your terminology every day on the phone, so it’s important that they understand it. I ran one-on-one sessions with team leaders, and had them update their internal knowledge base and brief their teams.
And don’t forget internal tooling. Make sure the words in the backend match the frontend — it’ll make life 10x easier for your support teams. And you can be 10x more confident that none of the old gobbledegook will seep out to customers.
After that, announce it to the wider team. Pick a big bang moment to get the most traction. We paired it with a feature launch update, and a global call with the whole company.
And after that, just tell anyone who’ll listen. Be that broken record. Keep talking until it’s part of the company’s vocabulary.
When people start using it organically, you know your work is done.
