What do UX writers do all day?

Yael Ben-David
UX Collective
Published in
7 min readMar 24, 2019

--

UX writing wasn’t much of a thing 10 years ago, so it makes sense that even now, not everyone understands what it is. My cocktail party one-liner is, “When you open an app… the words you see on the screen… I write those.” But there aren’t that many words on the screens of most successful apps, so I can understand why it might be hard to imagine how that can be a full-time job.

If you’ve heard that UX writing is important for your organization and think you might want to hire a UX writer, this article is about what you can expect them to do. If you’re thinking about becoming a UX writer, this article should help you get a feel for whether the work we do would make you happy. If you are currently a UX writer, and do something I left out, please let me know — maybe I forgot to include it, or maybe I don’t do it and should!

New Features

This is the number one thing we do with our days. Every 2–3-week sprint (in an agile environment, which I hope is how everyone is working by now), products roll out new features, strategically, with a business goals in mind, and set quantitative goals before releasing each one.

Words are critical for introducing new features to users and helping them use the features, to their benefit and ours (our interests should be intertwined). We write those words. We write them quickly while leveraging tons of input from stakeholders. We work with Product to make sure we understand the goals and context of our words; we work with Design to make sure it fits and is organized in the most effective hierarchy; Dev to make sure we haven’t introduced unjustified technical challenges; Translations to make sure the message is communicated accurately in other languages; etc. The list goes on and on. And we don’t have just one feature to write each sprint.

Product teams are generally made up of one product manager, an analyst, developers, QA engineers, and a designer. Each of these teams does not get its own writer, rather they share a writer with the other product teams. How many teams share a writer? Well, that depends. At one company, I was the only UX writer for 10 product teams. I didn’t eat, sleep, or pee, but it was a year-long adrenaline rush I’ll never forget. At another company I wrote for 3 teams. I had so much free time that at first, I was paralyzed by the vast opportunity to initiate my own projects. But I quickly pulled it together and filled my hours with those projects I’d always wanted to dive into and never had the chance.

To write a new feature:

  1. You get a brief. The PM explains what the thing is that they have conjured up and the team will build, and why.
  2. You ask questions, and
  3. Get to work: do any relevant research, ideate, collaborate, iterate, and iterate again, and again… and again.
  4. Then you deliver.
  5. Dev asks questions as they implement, and you answer them.
  6. And then your baby goes live and you QA it yourself because you care.
  7. You monitor the stats, and
  8. If (when) you identify an opportunity to improve metrics by tweaking a string, you bring it to your PM.

You do all of that, for every feature, for every PM, every sprint.

Optimize

Let’s dive in deeper to steps 7 and 8.

Once my copy goes live, that doesn’t mean I’m done with it. Not at all. I’ve already seen the massive improvement from my first iteration to my last, so I know that whatever I’ve written can always be better. The first thing I do with downtime, in between writing features, is optimize what I’ve already released.

There are fantastic tools out there to help us understand what’s working and what isn’t, and what might work better. We can watch our users interact with our screens by watching Full Story recordings. We can then hypothesize alternative screens that might improve metrics and run them by usertesting.com participants. And of course, we look at the numbers. MixPanel, Google Analytics, and Tableau, are all places to glean insights into how effective our copy is and what and where we might want to make changes.

There is no end to the optimization we can do. There are always KPIs to improve, there are always edge cases that we aren’t serving as well as we could, there is always room for improvement.

Voice & Tone

Voice and tone mapping is a much bigger, less urgent type of task. If you are lucky enough to work at a young company, you may be responsible for creating the V&T. This can take months and involves interviews, workshops, and so much more.

If you work at a company that keeps adding products, the new products may each need their own characterization. If you work at a company going through a rebranding, you may be responsible for updating the V&T. Regardless, you’ll always be responsible for making sure all copy aligns with it.

V&T work requires a lot of time thinking, brainstorming, researching, collecting input from execs and user-facing teams like Support. This work goes at a much slower pace than writing new features and optimizing them, but it has a far bigger impact than any feature, and is ongoing. It’s something you’re (also) always doing.

Alignment

As companies grow, keeping all parts of the product aligned and unified takes up more and more time. To make sure your product provides a seamless user experience, consistency is key.

  1. Align the old to the new. In general, when writing new copy, it is best to maintain consistency with existing copy. But sometimes, the new copy is just a whole lot better. In these cases, it may be worthwhile to align the old with the new. You’ll probably start by doing research to confirm that the improvement is indeed an improvement and then confirming with Product that the dev teams have the bandwidth to accommodate the task. To size the task though, you’ll first need to map out all of the places in the product where the relevant text exists. And then you start aligning.
  2. Align Marketing to Product. Voice is the product’s personality and tone is how you sound in different touch points and scenarios along the user journey. But the user journey does not take place completely within the product — not at all! And when in-product and out-of-product copy sounds like it’s coming from different personas, that is not good UX. Would you want to continue interacting with a service provider with a personality disorder? Would you trust them when there are so many other choices out there? Collaborating with Marketing is the first step in avoiding this dissonance. Get on the same page and sync regularly.
  3. Align Support and Sales to Product. Important steps in the user journey also happen when users interact with the Support and Sales teams. They should be speaking the same language as Product, and to some extent, Marketing. A good way to manage this is to sync as new features roll out. Each time a new feature is released, all user-facing teams will likely need to be updated about the exact functionality, and prepare phone scripts, email templates, FAQs, and more. No one understands the language of the feature more than the person who wrote it, so the UX writer is in the perfect position to keep all user-facing teams aligned.
  4. Scale. As your organization grows, your team will grow, but you will not get more hours in the day (unfortunately it’s true… I checked). You cannot do the other parts of your job while also running quality control on product-wide language/messaging alignment. A few tools that I’ve found helpful are a string database and onboarding documentation. A string database can be as simple as a Google Sheet where you log every string in the product, as it goes live. This will serve as a sort of searchable dictionary that anyone who needs to write, can reference, to avoid saying the same thing different ways. Saying the same thing the same way, makes users comfortable. Of course there are exceptions, but with an organized database, even when writing something new, you can start with a clear picture of what already exists. Onboarding documentation helps get each new team member on the same page from the get-go. This can include lots of links for reference to the V&T, style guide, string database, lists of core stakeholders, and whatever else will help new voices in the product sound just like the old. These two resources can be incredibly valuable, but only if they are kept up to date. And that takes time out of your day. (Personally, I update the string database once a month and onboarding documentation with each new hire.)

Continuing Education

As in every profession, especially in tech where things move fast, continuing education is an important part of a UX writer’s job. This means reading and listening to what thought leaders put out there, attending conferences, webinars, and workshops, actively engaging in the community, seeking out mentors and mentees, and producing original content both to process what you’re learning, and to contribute to the conversation. This takes time, but is invaluable in making sure your product isn’t left in the dust as the industry trends and best practices shift and you end up having one conversation while your user-base has shifted to something completely different.

UX writers do a lot of stuff, especially if we are spread across a lot of teams/products. And what we do is pretty niche. UX writing is different from content writing and from copywriting. Sure, there are some commonalities, but we are in an age of specialists over generalists. Unicorns are passé. To get the best UX writing, use a dedicated UX writer. Not only to avoid a “jack of all trades, master of none” scenario, but also because, from what I’ve seen, UX writers get high off of UX writing in a way that marketing copy won’t ever do for them. And passion makes for great work.

--

--