Things I’ve learned as the first UX writer in a scaling SaaS company
In October 2019, I swapped my all-rounder content hat for a very specific role I’d long been eager to get stuck into. I joined TravelPerk as the first UX writer.
During the last 7 or so months, I’ve lost count of the amount of JIRA tickets, Notion mentions, and Figma comment threads I’ve participated in. I’ve attended kick-offs, workshops, focus groups, and customer research calls. Here are my takeaways about what I’ve learned in this role so far.
Building a style guide was a necessary evil
“Is it email, or e-mail?”
“Should the date be 11 Dec, or Dec 11?”
“Do we write cancelation or cancellation?”
In dedicating time to putting together a style guide in those first few weeks at TravelPerk, I’m already certain I’ve saved myself hours in the long run.
While some dispute the need for this kind of guide, my job would have quickly become very repetitive and much more difficult without one.
Picture the situation: 8 designers, 12 product managers, and 60+ engineers. While I don’t speak to all of them on a daily basis, the style guide holds the answers to a number of common language questions. Not having to go through me for FAQs saves everybody time and ultimately reduces the number of requests I get coming in because everyone can self-serve.
Having not had anybody dedicated to this function full-time before, our style guide sets the ground rules in terms of grammar, glossary, and general voice and tone guidelines. That said, it’s very much a living document—I’ve probably updated it at least 20 times since I shared it with the team at the end of October.
Documentation is the key to consistency
While attempting to create our style guide, it soon became clear why we needed a UX writer in the first place. There were inconsistencies absolutely everywhere I looked.
In the product design team, we have this joke that to touch any legacy designs, you need to be comfortable with opening a huge can of worms. And if that’s the case, then touching legacy copy means being comfortable with opening the biggest can of worms ever to exist.
It sounds like I’m exaggerating, I know. But hear me out.
Take this feature we have called “approval processes” as an example. These are workflows that companies can set up to let their travelers book trips within policy, and have somebody (such as their manager) approve the details before payment goes through.
When we were updating this part of the product, we realized that the term “approval process” wasn’t always used. Variations like “approval setting”, “approval flow”, and “approval workflow” had not only snuck into the product on the frontend, but the backend was also a total mismatch. Developers building the product didn’t even know which was the right wording to use.
By identifying this issue during the redesign, we were able to settle on one term (approval process) and document it in our internal product knowledge center, never to be confused again (I hope 🙏).
Designers have my back
At TravelPerk, we move really fast. Our engineers deploy 50–60 times a day. That means our designers work on a problem, test their designs, iterate on them, push them to production, and iterate again. It’s non-stop. So I feel lucky that they loop me into that process as early as possible—usually during the ideation stage. We’ll bounce ideas off one another and often engage in pair writing activities until we get a result we’re happy with for the first iteration.
But it doesn’t end there. The design team advocates for what I do because words and design go hand in hand. That means they tag me in Slack channels I’m not even part of, in pull requests on Github, and in a number of other places—just to make sure the words are right.
Establishing this kind of relationship from the outset has been monumental in championing thoughtful UI words. And I feel very fortunate to have had a seat at the table since day one. (We’re hiring, by the way!)
Figma is a gamechanger for UX writers and collaboration
Back when I joined TravelPerk, we were 5 people on the design team, using a combination of Sketch and Abstract to manage our design workflow. Fast forward 3 months and the team had doubled to 10, with 8 designers, 1 UX writer, and 1 researcher. Each designer is responsible for a squad, while research and writing are more transversal roles—working across all squads in the organization.
Scaling the team so quickly was no mean feat, especially when it came to the tools we were using. So, in early 2020, we made the decision to switch to Figma to facilitate the growth of our team and promote collaboration and consistency in our designs.
A few years back, John Saito wrote, “write in mocks, not docs”. While I could, of course, have been writing UI copy in Sketch files from the beginning, the nature of committing to Abstract seemed to make the process a lot more laborious for everyone involved. But since we started using Figma, any copy I write is instantly available on my colleagues’ computers—even more important at the time of writing, as we’re currently 100% remote due to the coronavirus pandemic.
Figma has given me tons more flexibility to try out variations, in real-time with other designers, before committing to a “final version”. (Though it’s never really final—am I right, writers?). What’s more, it’s extremely easy to get the hang of, even if you don’t come from a design background (🙋🏼♀️).
Research speaks volumes
It’s no use getting attached to the words you write as a UX writer. Unlike marketing copywriting, where words can whisk customers away to sell them a product they never knew they needed, product copywriting has to be clear, concise, and useful. If it’s not those things, you’re doing a disservice to your users. Flowery expressions and over-the-top statements aren’t welcome here—and you better believe that will show up in your research sessions.
You don’t need me to tell you that carrying out research is hugely important for any design team. But for content designers, in particular, it can give you a real insight into your customers’ minds, the vocabulary they use, and the words you should be using in your product, too.
To give you an example, in the Payments squad, we want to make some changes to align our customer data model to reflect that of the SaaS market. So, rather than guess what our customers prefer, we decided to survey them with one simple, multiple-choice question.
“I am 99% confident that customers will choose legal entity,” said Alexander Rickett, Product Manager for Payments.
The outcome of the research? “Company” won with over 30% of the vote. And legal entity? It didn’t even come second—it came third.
While this isn’t all I’ve learned as the first UX writer at TravelPerk, it’s a pretty good snapshot into my day-to-day. I’d also add that there is no query too small. So if you’ve got a UX writer on your team, know that we want to be in discussions about labels and button copy. Error messages and empty states? We write those too. The more involved we are with the many different touchpoints for great copy opportunities, the more aligned and harmonious our product will sound, and the better experience our users will have!
👀 Looking for a new challenge? 🤔 We’re hiring designers and engineers, join us! 👈
