Dropbox's John Saito on the role of writing in experience design

A short snippet of copy sets the tone for a user’s experience, and it can make or break whether they’re able to achieve success using our products. So to go a bit deeper on the role and impact of words in design, I hosted a podcast with John Saito, UX Writer at Dropbox and previously the very first UX Writer at YouTube.

If you’re a Dropbox user, John’s written much of the language you’ve encountered in the core product and apps. More visibly, he’s best known for his must-read Medium essays, which explore everything from how we can improve push notifications to the principles of his trade.

Our chat covers how to find and document your product’s voice, when a startup should hire a writer, how to localize your content, and much more. If you enjoy the conversation check out more episodes of our podcast. You can subscribe on iTunes or grab the RSS feed in your player of choice. What follows is a lightly edited transcript of our conversation, but if you’re short on time, here are five key takeaways:

• Unlike a marketing page, writers should avoid getting clever or creative with UI copy. The end goal is to write so clearly that end users don’t notice your word choice.
• Every product has a voice, and that voice is going to evolve over time, so it’s crucial to document it. To create your style guide, sit down with every team across your organization and ask, “What do you think our voice is? How do we speak?”
• The UX writing team at Dropbox has three simple voice principles to keep their work in check. They strive to be simple, straightforward and human.
• UX writers need to be closely in sync with engineers, so that there is clear copy in the queue for even the smallest, most rare edge cases.
• If there’s one credo to John’s work, it’s that in the world of UX writing short always beats good.

Adam: John, welcome to the show. To get started, you’re a UX writer Dropbox. So, what exactly does your job entail and where might of our listeners have seen your work on display?

John: A UX writer basically focuses on the product itself. For our product, we have a bunch of different services – the desktop client, Dropbox.com on the web, apps for Android, iOS and Windows phones. We also have apps for things like Xbox and random services like that. A UX writer will work on mostly the UI content for all those different services. Our work could also include things like email notifications or like push notifications that you might get on your phone. Basically, it’s any words you might come across in your user experience.

Defining the role of a UX writer

Adam: At a glance, some people might think you’re a copywriter for inside the product, but it’s a little more complicated than that.

John: Yeah, there’s two different kinds of writing within UX writing. One is the copywriting side, which tends to be a little more punchy or flowery. These are things you might find on the landing page of Dropbox.com, when we’re trying to get you to get excited about our product. The language has to be a little more exciting there. But you can’t always be exciting in the daily interactions. If you’re constantly saying really clever things in the UI, it gets really annoying, and so that’s the second side of UX writing. It’s this transactional, navigational type of copy. The goal is to not have your words be noticed, so it becomes a seamless experience. So as UX writers, we have to juggle between these two different kinds of writing throughout the day.

Adam: It’s interesting you say the idea of your work for it to be so seamless that it’s not to be noticed. A lot of great product designers have said good design is design that you don’t notice. I’ve seen many other people that do work similar to yours call themselves content strategists and content designers. Are these terms interchangeable?

The goal is to not have your words be noticed, so it becomes a seamless experience.

John: I have this discussion with a lot of people, and I hear a lot of different opinions on it. I think the reason there are so many of these different terms is because this discipline is very new. We’re trying to figure out for ourselves, what is this thing that we’re actually doing? Dropbox uses “UX writer”. We were looking at other companies and Google had been using the term UX writer as well. That might have played a big factor into what we’re doing.

The term I’m gravitating towards lately is “product writer.” I’m seeing more and more companies starting to have this role. Slack calls their team product writers, and I like term because it’s analogous to a product designer. A product designer would design products like apps and websites; a product writer would collaborate with a product designer to work on the same things.

Facebook uses the term content strategist, and to my knowledge it’s very similar to what UX writers do. I think content strategist sounds like it’s more important because of the word strategist – it’s this all-encompassing strategy for your whole product,. When it comes down to it, at least for my role, there is some of that, a lot of it is writing. I’m writing the text that people see in the interface. I’ve also seen terms like content designer, and that’s more appropriate for roles where there’s a really heavy design focus. You really aren’t a designer, you just happen to have a lot of content in your product. There’s a lot of different terms for us, and we’re still all figuring it out.

When to onboard a writer

Adam: Back in March 2013, you were actually the very first UX writer hired at YouTube. What was it about the state of YouTube at that time that made it the right time to bring in your skill set?

John: At that time, Google, in general, didn’t have many UX writers. Back then teams were starting to realize it might be nice to have a writer on a design team. Sue Factor was the first UX writer at Google, and she did a lot to define the discipline there. She created a lot of the early documentation about what UX writing is and over time people started noticing that need. Around that time YouTube was in the process of really expanding and realized they had this growing team of designers and maybe they should also have a writer to focus on our language. Because like Dropbox, YouTube actually has tons of different surfaces, from gaming surfaces, to the TV, to the websites and apps, and so on. They wanted to have one writer to oversee the language across all these different services, and I was lucky to be hired as the first writer there. Within a couple of years we slowly grew our team to four or five writers by the time I left.

Adam: YouTube, Google and Dropbox are mammoth companies. Most of our listeners are from earlier stage startups. Are you seeing more startups bring UX writers on board early, and is there a benefit to that?

John: I think so. I have a close friend who works at Gusto, a startup focusing on HR services, and his role is slightly different. He’s a UX writer, but he’s also a marketing writer. At companies like that, the main advantage to having a writer is that it helps your brand. It differentiates your brand from other competitors who may not be focused so much on language.

Startups have this advantage where they can really experiment with their brand. They can take riskier chances, and having a writer is just so powerful – to connect with your audience not just through your visual language, but through your written language as well.

Finding and documenting your product’s voice

Adam: Does a product have a voice? Is that something writers, particularly those brought into a startup early, help shape?

John: A product definitely has a voice, and that voice might evolve slightly over time, but it’s important to know what your voice is and to document it. At Google, YouTube, and Dropbox, we’ve always had a style guide or some guiding principles on what our voice and tone should sound like. The basic principle behind that is your voice tends to be the same throughout your product, but your tone changes depending on the scenario. For example, the tone you would use for an error message might be more empathetic than the tone you would use for your landing page. At Dropbox we have our voice and tone principals and a style guide. Our voice is to be simple, straightforward and human, and we give a lot of examples on how to actually carry that out.

Adam: What was your process for putting a style guide together?

It’s important to know what your voice is and to document it.

John: At YouTube, because I was the first writer there, one of the first things I really wanted to do was put together that style guide. All these people were coming to me with questions like, do we use this term, or do we use this term? Does this actually match how our voice and tone should sound? Within my first few weeks, I was on a mission to put together this style guide, knowing that it would be continually evolving. To do that I talked to everyone from our marketing teams, to our design teams, and so on to figure out and ask, “What do you think YouTube’s voice is?” Those interviews helped put together this rough style guide for YouTube, but it slowly grew over time to include things like how to write for internationalization or different grammar mechanics; things like, do we use the oxford comma or not, do we capitalize certain buttons or not? A lot of that came from engineers asking questions like, “What’s the right style for this?”

At Dropbox I actually joined after the style guide was initially created. I had a manager, Lisa Sanchez, who put together the Dropbox style guide. It’s hard to work on big projects like this if you’re constantly in the weeds working on UI copy every day, so when she had this idea for the style guide, she held a two-day offsite with different writers across Dropbox. They needed to figure out what the style guide should include, what the purpose of the style guide should be, what the audience should be, etc, and they came up with this rough framework. Over time it grew in the same way as YouTube’s, where you feed it with questions that you get. As you start writing you actually realize, oh there are different ways to handle this, what should Dropbox’s way be? Now we have the Dropbox style guide, which I love. I refer to it all the time. We keep it in Dropbox Paper, so it’s a document that we can just update at any point.

In terms of maintenance, we have a team of a few writers across the company who basically meet every month. We talk about changes or updates to the style guide or we discuss, things like, do we capitalize words after a colon or not, or heftier things like how we describe a feature to people. We meet every month and make updates every month. It’s probably viewed hundreds of times a week, or at least I view it what seems like hundreds of times a week. That’s our style guide in a nutshell.

Voice principles in practice

Adam: Our content strategy team has the three guiding principles for what they write. Our product speaks naturally, the way that people speak. The product speaks directly to the user, but never for the user. And the product helps the user getting them through complex ideas. Do you have similar principles at Dropbox?

John: Voice principles is what we call them at Dropbox. They are to be straightforward, helpful and human. Straightforward touches on the fact that we want to be honest and transparent with users. We don’t want to use super vague language, because we feel, especially when it comes to Dropbox, security’s really important, and so we want to be transparent. The second principle is around being helpful. Often times, rather than just telling people, “Hey, there’s an arrow here,” we try to help them with things like, for example, how you get out of that error state. What do you think a user might want to do and how can we help them get there? The third thing is to be human. That touches on the style of talking or writing – just talking to the people like a human, like you’re a friend. A lot of times when I’m reviewing copywriting by somebody else, often when it tends to be a little more technical, I can never imagine myself talking like that with another person.

The Dropbox UX writing team’s mission statement

Just the other day I came across this message that said something like, “Dropbox cannot complete this request.” There was a transient network error. This was a real error message, it might even still exist in our product today. But when I saw this I thought, oh my God, this is totally off brand. It’s rewriting something like that to make the language sound more human.

Adam: Another interesting tool you’ve created is your own thesaurus. Walk me through why you did this and what your process was.

John: I actually got the idea at YouTube, where I did something similar there. I call it a thesaurus, but it’s not technically a thesaurus. It’s more a tool for brainstorming around certain concepts. I found that as I was writing, especially stuff that was more like copywriting that you might find in a landing page, there were certain user benefits I was constantly writing about. At YouTube it was things like maybe music or being able to access your stuff on the go. There’s so many different ways to refer to this – at your fingertips, on the go, access anywhere, everywhere, etc. I realized there are all these similar phrases that I’m constantly using; why don’t I just document them somewhere, so I don’t have to constantly go back into this brainstorming process every single time?

An example from John Saito’s “thesaurus”. Read more here about how he built it.

At Dropbox it’s similar. There’s this bucket for collaboration because that’s a common theme that we use at Dropbox. Things like better together, collaborate, etc. If you look at the thesaurus there aren’t too many of these common themes we might write, but each theme probably has dozens of different ways to talk about it.I find it really helpful as I’m starting to work on something new and I need to feed my brain words that get me in the writing mood.

Adam: Do you share that with your wider team, or is this a personal thing for you?

John: I don’t know how often the whole team uses it, but it has come in handy as a team-wide tool. Recently we were working on this projection where we weren’t sure how to actually position the product. We put together three landing page options, all with different user values, and we used the thesaurus to populate the language for those three landing pages. The goal was to show that to users and see which ones they gravitate towards.

Where UX writing sits in a product team

Adam: How many UX writers do you have at Dropbox right now? How’s the team structured?

John: We have five UX writers now with a sixth one coming on board very soon. We technically sit in the product design team, and at Dropbox there are three pillars or groups within the design team. There’s the product design team, which the writers are part of. There’s a brand design team, which works very closely with marketing, and there’s also the research team. Research is embedded in all these different projects.

Adam: Within product design are you attached to a particular product or do you float around and touch everything that you gets released?

John: Dropbox, like many other growing companies, has gone through a lot of reorgs. It seems like almost every year we might go through some shuffling. Today there are two main groups. One group focuses on the paid features, another group focuses on the everyday users. I work on the side that works on the everyday features and examples of things that I might have worked on are the recently redesigned website and some of the newer features we launched, like a document scanning tool on Android and iOS, a tool for signing your name on PDFs in iOS, things like that.

Adam: You’re a writer that’s at the intersection of engineering and design. How familiar does a UX writer actually need to be with the tools those folks use? Are you expected to make changes directly in the code base?

People may never actually see some of these really obscure messages

John: We’re looking into things like that, but at the moment we’re not. We had similar processes at Google and Dropbox, but I don’t ever actually go into the code and update strings or anything. Sometimes as an engineer will be creating strings in the code, they might loop me in and ask, “Can you take a look at this passage of text,” or, “Can you take a look at these few error messages and let me know if they’re okay?” That’s how I might work directly with engineers.

A lot of times designers will focus on the main flow, and sometimes they do a work on some edge cases and error cases, but the fact is engineers have to create scenarios for all the edge cases. As a writer we will have to write these error messages, so that’s when we partner more closely with engineers. It’s for these really small edge cases. People may never actually see some of these really obscure messages, but we need to have a message just in case something does go wrong.

Short beats good

Adam: You’ve said that you’re a writer that actually hates to read. The fact is a lot of people do hate reading on the web and in many cases you’re writing for the web. How does UX writing make that easier for people? What tools or tips do you have?

John: Scanability comes up a lot. Users or readers on the web don’t technically read word for word. They just glance around and scan copy here and there. To accommodate for that, a key principle in UX writing is to be as brief as possible. That often means being really ruthless. Sometimes you orally want to say a lot of things, but if you say too much, they may not read anything. Sue Factor, the first UX writer at Google who I mentioned earlier, had this wonderful phrase, “Short beats good.” I love that phrase.

One of John’s core UX principles is that short beats good. Read more here about he designs words.

In UX writing, it’s more important to write in just a few words than it is to actually be more accurate. There are opportunities where you can talk more in depth, but it’s not the key navigational elements and it’s not headings. Those you should keep really as short as possible. And if you do need to explain things, there are other ways to do that through things like progressive disclosure where you’re giving information little by little, or maybe some of that information should belong in documentation, an email or something else where there’s more real estate. Short beats good.

Lessons in localization

Adam: You do a lot of localization at Dropbox. Does this philosophy make translation more difficult?

John: It’s actually better. The way localization works, at least for the product at Dropbox is, we write strings that get translated by translators and often as things get translated, especially into European languages, they tend to get longer. Some things could even double or triple in size depending on the words being used. Having shorter text is actually better for translators because it won’t break designs when your text gets super long. If you’re wondering if it make things more difficult to translate, we have a way to attach comments to each one of our strings and that’s how we give context to translators. So if we use the word “auto”, in the comment we can explain where this string appears and whether it is referring to auto as an automobile or auto as automatic. That’s how we communicate with our translators.

Dropbox Paper localized into French.

Adam: What other complications does a UX writer need to be aware of when it comes to translation?

John: I found that the more playful you are the harder it is to localize, and that’s something to keep in mind, especially for startups. Startups tend to be a little more playful in their language compared to these ginormous companies like Google or Microsoft.

I love that challenge. How do we capture this helpful, human tone and make it a little more joyful? And in all languages? One way we do that is through this context building so. Sometimes I will write actual alternatives for other languages. There might be something that I really want to use in English and I know that it will be difficult to translate, but I’ll give an alternative. If you really cannot, if there’s no good way to translate this in your language, you can translate it like this, which is a little less playful, but at least it won’t block translation. Our translators are good. I’m constantly amazed at how they can keep our voice and tone consistent across all languages.

Adam: With the emergence of voice UI and company after company shipping chatbots, how do you see the role of words evolving as the amount of interfaces we design for continues to expand?

John: It’s one reason why more and more companies are hiring these writers on their design teams. Language is now a critical part of design and experience. It’s natural to want to have somebody who’s really knowledgeable about words, semantics, style, word choice and tone. I’m excited personally to see this industry evolve and see more and more conversational UI.

Adam: John, thank you very much for joining us and we’ll look out for more of your writing on Medium.

John: Thanks for having me.