You’ve probably known for a while that you should have a writer on your product team. Or maybe you have one already. Content designer and UX writer Jane Ruffino talks about some of the challenges and opportunities that come up when you have someone in charge of the words.
Digital products are full of words: instructions, form fields, buttons, error messages, headers, empty states. And yet, until a few years ago, few product teams had a dedicated writer. Many teams are learning to reach out to their communications departments, marketing teams, and in-house content strategists for help choosing the right words to guide users. Things like the headless CMS and the voice interface mean that for many product teams, words increasingly need to come before pixels or code. It’s exciting to consider all you could do if you had a writer on your team, but where do they actually fit, and what do they do that you’re not already doing?
The answer is yes. Words are visual. Words and phrases need to be the right length, they need to look right, and they need to sound right. But it’s more than that. Everyone in the team is responsible for the story, but a writer helps do that through language, and is usually happy to be the language champion in the room, as a full-time designer. The output of a writer might be words, but a writer’s work also includes user and subject matter research, workshops, ideation, interviews, analysis, documentation, testing, and creating taxonomies and categories. The skill sets of journalism, content strategy, copywriting, digital marketing, and other writing-related fields usually include a lot of skills designers use. Just like a designer doesn’t push pixels all day and a developer does more than write code, a writer does more than write. Still, it can create friction when someone without a formal design background joins your team and starts speaking a different professional language. One of the challenges a writer on a product team might encounter is that designers have often learned about writing from other designers. And a lot of even data-driven learnings about writing in digital products come from a time before product teams regularly had writers. In other words, many designers’ understandings about writing often come from designers talking about words written by other designers, and these beliefs have become canon in UX. For example, “show, don’t tell” is a suggestion about using illustrative, clear language, not about using images rather than words. And the thing we hear the most – that “users don’t read” – isn’t necessarily the case. A UX writer can help you create words that users don’t even realise they’re reading, using some of the same processes you already use. And they’ll be better equipped to explain why those words might be working, from a language perspective. Another challenge is the assumption that a writer can create those perfect words right off the bat. Sometimes that does happen, but writers need time to design, test and iterate, too. When users respond negatively to words, they’re responding to the whole experience. Sometimes a language tweak will do the trick, and other times it’s a deeper UX problem that you need to solve together. That’s why it’s important to accept that a UX writer is a designer who works in a different medium.
Words help us navigate, investigate, and relate to the things and people around us. We see, hear, touch, think, and speak, constantly. In words. All of us are always putting words into the world. This is why it’s hard to know where, when, and how to work with a UX writer. Most people can see where the work of a writer could start: a snappier button there, a clearer error message here. But once we see how much of our work is around words, it starts to feel like it could get out of hand. Where does the writer’s responsibility stop? The bad news is, there’s no single answer for this; every team is different. It’s going to change your process, and it won’t always be smooth. But there’s also good news: this is a problem you’re already dealing with. Visual design is also part of everything, but you’re probably already working with visual designers. Nearly everything is an interaction, and a digital product is made out of code. Even when a UX designer has every skill in the UX toolbox (which is rare), they don’t take over everything. You’ve already built your process around a team of specialists who have competences that touch every part of the project. This time, you’re taking a task that’s not really been anybody’s individual job, and giving it to someone who not only cares about doing it, but wants to do it. One additional challenge is this: product teams used to handle more of the navigational copy, while copywriters and content strategists handled longer-form content. So sometimes there’s sometimes an insistence that there’s a strong distinction between ‘microcopy’ (or navigational copy) and ‘content.’ But that line isn’t always so easy to find. There’s no simple answer to this, but it helps to solve the problem in front of you, and try not to get too hung up on universal definitions that can’t exist. Where your UX writer’s responsibilities stop will depend on your team and your project, but let’s talk about their main focus.
Most companies have a brand voice and tone guide, but very few have style guides for interface content. Your UX writer is as responsible as everyone else for the story, but their key focus is to set and maintain standards around the how, the what, and the where of words, and the style guide is the cornerstone of this. If there is a brand content guide at all, it might be pretty basic: values statements, a few examples, and some pretty pictures. There’s no obvious connection between a company saying they’re “forward-looking” or “inclusive” and your decision to write “next” or “continue” on a button. It’s one thing to accept that we need to talk with our users in a human-to-human way, and another to create concrete ways to do that so it’s consistent with what users need, in a voice that still reflects the brand. Your UX writer can take those fluffy brand values and find relevant connections, creating a set of rules and standards around things like error messages and form fields, when (or how, or if) to use humor, how to use different types of punctuation, and create a glossary. The style guide will probably be a living document, and it will require research, analysis, content audits, and possibly some workshops. It’s helpful where there will be a handover, when your product needs to be translated, or if it will connect with other elements of a company’s offering or ecosystem. And during the process, it’s useful when a developer or designer needs to write some dummy copy and doesn’t want to use lorem ipsum (please, please stop using lorem ipsum!). It helps you know why a decision was made, and helps you all know when to stop rewriting content based on personal opinions (because that can get you stuck in an infinite loop). In an ideal world, your design system will include both visual standards and your interface copy style guide (like Shopify does), but for now, having guidelines for interface copy at all is a great start. But as always, what you’re able to do together has everything to do with how you collaborate.
There are many types of writers who can work well on a product team, even if they haven’t had “UX writer” as their title before, and how you change your process should be partly based around their skills and needs. If your UX writer comes from UX or has a formal design background, great, get them involved with wireframing and let them run with tools and processes they already know. If they come from a content background, they’ll probably be happy to help with research, interviewing, documentation, and analysis. They’re used to learning new tools, too. But when a UX writer joins a team that’s never had a writer before, it’s extra-important for everyone to come up with a process together that incorporates their unique contribution, rather than just slotting them into what the team has always been doing. It’s a huge opportunity to have someone on the team who can really focus on the language, so make sure you make room for it. There will be challenges, especially when a writer comes from an environment that doesn’t iterate much, or is strictly waterfall, like print journalism. All writers are already iterative, we just aren’t used to publishing every draft. So it’s valuable to work together to create a definition of done that includes content, and that allows them to do a thorough, ‘good enough’ job. A writer who’s worked with tight deadlines will already know how and when to let go of the words and hit ‘publish’. A helpful way to draw a line under ‘done’ for a sprint or mid-project deliverable is to decide that once something is correct, aligned with the style guide, and makes sense in a flow, any future change should be defined as an improvement. A typo, a comprehension blocker, or something just glaringly ‘wrong’ (out of tune with the style guide, off-brand, or could create a problem for the company), can be considered a bug and prioritized like any other bug. For the non-writers on the team, it can be hard to grasp how long things take to write: you might spend half a day talking about copy on a button, but perhaps a long piece of text you thought would take all day ended up done in an hour. Just be prepared for it to mess up your time estimates (sorry) until you all figure out what you’re doing. It’s also valuable to talk early about what needs to be said in a flow, before design is done. Then again as it’s being done. Then again when you inevitably redesign it because what works in a modal might not work on a confirmation screen. Work with your writer to make sure copy is in the right place, the right format, and has enough space – including any breathing room needed around it. It’s often helpful to draw parallels with visual design, but one place that diverges is that sometimes words just need the space they need. While we all want to keep things as short as possible, sometimes removing words harms clarity. If you build a whole flow and then add the words at the end, you’ll end up with crammed screens, unclear phrasings, or – worst of all – solving a whole bunch of content problems by creating modals nobody wants.
There are plenty of challenges for a team that wants to add a writer to their work, but once you start, you’ll see the payoff pretty quickly and you’ll never know how you survived without one. Sadly, some of the toughest obstacles come from outside the team, where budget holders, senior managers, clients, and anyone else who worries about the cost of design (even if they see its value) can ask hard questions about why a team suddenly needs a whole new type of designer. Digital products have always had words, so why do you suddenly need a specialist? Can’t we just have our marketing people do it? We’ll get a freelancer for a day or two at the end. There’s no easy way to win these battles, and, like visual design, a lot of great content is good because it doesn’t announce itself, which means they might not even notice the improvements. What I can say is that the first time you ask to have a writer on your team, there’s an almost no-percent chance you’ll get one full-time, so take what you can get, then make a strategy to expand it. If they say they’ll let someone join for a week at the end, take it. Show some “before” and “after” screens so they can see how much better things are. Talk about how much more you could do if you had more of this person’s involvement. If they give you a bit of time with someone from marketing, that’s fantastic. Show how that person’s ability to understand the brand helped you figure out how to connect the product to the ecosystem, and point at how much deeper that could go. Finally, once you get your writer, don’t get hung up on exactly what a writer’s job title has been. Many companies, even with big design teams, have one or two writers who cover a huge amount of ground. Your UX writer might also be a content strategist, a copywriter, a technical writer, or any number of things, and you should make the most of it: versatility can only be to your advantage. It won’t be immediate, but eventually, you’ll have a full-time UX writer on your product team, and a whole new set of challenges to meet together, as product designers.
We love to write about what we do, what we learn along the way and what we play with.