Transcript of the interview I never had

I’m a big fan of Jane Portman’s UI Breakfast design podcast. I’ve actually written about specific episodes before. It’s kind of a bucket list item for me to be invited on the show one day. On this morning’s commute I listened to the first episode I’ve ever heard her do on UX writing and I thought, “Wow, that’s one I would have loved to have been a part of.” So here ya go, Jane. This is what I would have said if I had been there.

So before we get started on the main topic, can you tell us a bit about yourself, about your background, and what you do?

Sure. So when I was deciding what to major in, in college, I sat down with my mom and made a list of everything I’m good at and everything I like doing and writing was on both of those lists. We figured I probably couldn’t really make much of a career out of writing novels, so we tried to think of a profession that actually pays a salary, and we came up with journalism.

I got my BA in journalism from New York University. It included studying in 5 diverse locations — rural Pennsylvania, New York City, London, Rostov-on-Don in Russia, and Tel Aviv in Israel — and I loved the studies. But when I started working for newspapers and magazines I realized there were a lot of things about the industry that weren’t working for me, but I had no idea what to do next. So I decided to sort of let Fate decide. I sent out my resume to anyone I could find who was accepting applications, even the FBI and the CIA simply because I found out that you could apply online. (They never got back to me.) In the end I was accepted to work at Memorial Sloane Kettering Cancer Center, for a truly inspirational medical oncologist who I am still in touch with today more than a decade later. I decided then and there that I love medicine but don’t like working with patients, so I decided to go into medical research.

I did my MA and PhD in medical neurobiology at the Hebrew University in Jerusalem in Israel. I worked as a freelance writer to support myself the whole way through and at the end decided I really didn’t want to work in medical research either. But at this point I had sort of organically created this niche for myself as a writer for complex and technical subjects so I went to work for a DNA product. I started writing marketing copy and product copy, and really anything else any department needed. It was a crazy, amazing time! I worked with the most amazing people and am still in touch with a lot of them, in particular, my mentor who I adopted there and can really thank for opening the product writing world to me. I fell in love with product writing — UX writing — and decided that was definitely what I wanted to do next.

Now I work in the fintech space. I really wanted to stay in the world of complex products. Israel has been called “the startup nation” and we really do produce an amazing amount of innovative tech, but if that tech isn’t accessible, if it isn’t usable in mass markets, what’s the point? And that’s how I see my role as a UX writer, making innovative tech accessible to mass markets.

Tell us more about that. How did you evolve from someone who is doing that to someone who is teaching others like you are doing now?

When I first discovered UX writing, I was ravenous for more information. There weren’t any UX writers at the company where I was working but I did follow the two senior UX designers around like a puppy dog and begged them to teach me everything they know!

I started reading — actually the first blog that one of them recommended to me was UX Collective. I’ll never forget the first time Fabricio Teixeira reached out to me and asked to publish one of my articles in UX Collective. It was this huge moment for me, that that’s where my story began, and now I was being asked to contribute!

I started writing my Medium blog, at first, just to process my thoughts and everything I was reading. I attended the meetups organized by Kinneret Yifrah and attended big conferences like UXI Live, and participated in Facebook groups, and listened to podcasts like yours :) And eventually, I guess I started to have original thoughts, and wrote about things that other people in the community could relate to. I started being asked to publish in great publications like Prototypr.io and to speak at meetups and give internal talks to departments within the companies where I worked, and I guess it just snowballed from there.

Let’s talk about content designers and UX writers. I would love you to kind of draw that line because I feel a big difference between content being, you know, the heart of the project within the website or within the app, inside the UI, and UX writing being on the shell, on the interface that deals with that content. So the UX writing that are you talking about, what kind of writing is that?

That’s a really good question and a question that’s being asked a lot. My last two titles were “UX writer” but I know at Facebook they call them “Content Strategists” and I’ve heard that in the UK it’s common to be called “Content Designers” but at the end of the day, from the people I’ve spoken to, we’re all doing a lot of the same thing. I actually wrote a whole blog post about this because I saw it coming up again and again.

We are all working from the high level voice and tone mapping, to the strategic implementation — looking at how that voice expresses itself throughout the user journey , which takes place in and out of the product, by the way — to the “pixels” of a writer: the actual words in the interface, from buttons and nav bars, to empty states and error messages, push notifications, SMS notifications, transactional emails, and all of the nitty gritty stuff like that. Content design is also a big part of what we all do, working with visual designers to get the hierarchy right, to decide what structure best conveys the message we’re trying to get to the user.

For example, recently a designer came to me and asked whether her button text was too long for two side-by-side buttons and I took a look and said that actually, if she added a sort of subtitle in the form of a question above the buttons, she could both shorten the button text without losing any of the messaging, and the whole component would be easier for the user to consume. So she really liked that. That’s just one example of what we mean by content design, and how organizations need to recognize that we’re not just “word monkeys” —I’m sure you’ve heard that engineers aren’t “code monkeys” — well we’re not word monkeys who plug in strings to final designs mid-development. We are involved, ideally, from the very beginning, because for the best interface to evolve, the whole design team really needs to work together. Content and visual design are really synergetic if done right, as a collaborative effort.

UX designers who want to do it well themselves, because more often than not we are working within smaller teams and we can’t afford hiring a specialized consultant for that. So UX designers and founders themselves who do that, how can they get better?

First of all, I have to say — I owe it to the community to sing it from the rooftops — to say that companies need to start realizing that they can afford a UX writer, that the ROI will always be worth it. I’m actually preparing a talk now about the ROI of microcopy. I’m happy to share it with you when it’s ready. That having been said, what about companies that don’t have one?

There are definitely some rules of thumb. One is to always ask whether your copy is clear, concise, and helpful. It sounds pretty basic, but it may send you back to the drawing board more often than you would have expected.

Another is to bounce your writing off non-English speakers. Working in English in a non-English-speaking country makes this easy for me, but these days you can find non-English speakers in pretty much any company (I hope). If they have to think too hard to understand what you meant, you should work on it more.

Consistency is also key. Just making sure that whatever you write, you write it the same way every time. However you capitalize, etc. That’s something pretty simple that can make a big difference between a product feeling sloppy, and feeling professional, and anyone can do it.

Also, read your copy out loud. Even if it’s just to yourself. If it feels awkward out loud, don’t use it.

How do you store your decisions besides wire frames or do you just pass over your wireframes to your mobile team, let’s say, so that they can have their take of the copy?

I always work with Google Docs. So first of all, you have the voice and tone guide and the style guide to align to. These are living, breathing documents that are evolving all the time. But by working in Google Docs, everyone can access the most updated version at anytime. So that would be where, like, “master decisions” are kept.

On the more micro level, for each feature or project, I open a doc and share with all of the relevant stakeholders. I’ll include the title of the project, a short brief to give anyone looking at the doc some context, links to the design — or even include screenshots of the design inside the doc so that the placement of the text is clear to everyone. I might also include links to JIRA epics, or PRDs, or any other relevant documentation so that anyone reviewing the copy doesn’t need to go hunting around for other references and supporting material. I used to work with Balsamiq, but I haven’t been doing that lately.

I also love Google Docs, not just because it’s always up to date, but because of the version history. That’s an excellent documentation tool. I iterate with stakeholders in comment threads, and when everything is final, or depending on how big the project is, sometimes at several checkpoint before the copy is final, I sit with designer, or even remotely or asynchronously, we update the copy in the design. It’s really important to see the copy in the design because microcopy never lives in a vacuum. Many times I’ve thought a string was a beautiful masterpiece until I saw that it didn’t work in the design at all, it was such a mess visually, so we started over.

So by looking at the version history and the comments, you can always see how you arrived at different decisions, and then of course, if anything high level changes, because it’s always a constant feedback loop, you go back and change that in the master style guide.

I also like to collect final strings that go live at the end of a project into a string database. I’ve heard about a lot of tools for this but I know there’s always a risk of software fatigue. I prefer to work with a simple Google Sheet. And I just document final strings in one place so that anyone can reference them and recycle them, for consistency’s sake and to save time and for other reasons. So you can always see the application of all of our decisions there.

What should exactly go in [a voice and tone or style guide]? Is it like descriptive copy, saying, like, your language should be friendly? And you should call your users “friends” and things like that? How is it structured?

I always recommend starting with a short description of what the guide is and how to use it. You have to assume that 99.9% of the people reading the guide are not UX writers, and if you want them to apply it, there may be a preliminary level of education involved. Which is fine, that’s part of our job.

Then would be the highest level stuff — voice. If your product was a person, how would they sound? I wouldn’t include the research that got you to that persona, the guide isn’t the place for that. But I would describe it literally like I was describing a real person. Are they an introvert or an extrovert? Things like that.

Then I’d dive into tone. So voice is the personality, and tone is how the “person” (product) sounds in different situations. Right, so your librarian may be a pretty soft-spoken, serious person by nature. But if you tell a hilarious joke you make get a jolly response. You want your accountant or your dentist to be serious and practical and credible, but you also want them to talk like a human being and not a robot, to remember if you just had a birthday or something like that. So after describing your product’s personality, I would dive into how that persona behaves when serious or frustrating things happen, like error messages — right, even if your voice is cheeky, you need to be respectful and empathetic and helpful when mistakes happen. And I’d always recommend using examples throughout.

After that you can get more into the details, like type case, British vs. American spellings, date formatting, and things like that.

Always keep in mind, not only the persona of the product, but the persona of the user base. You might be an app in the healthcare space, and want to sound like a pediatrician, but how does the profile of a pediatrician vary in different communities or segments? What are your specific users expecting to hear or what do they want to hear?

A good way to literally speak the same language as your users is to listen to how they talk. I regularly sit in the Support room, for example, and listen in to live calls with actual customers. I write down phrases and am sometimes able to work their exact quotes into the UI. For example, a customer called in because he couldn’t link two accounts, or something like that. The rep was able to help him and he goes, “Boom! I’m connected.” That was a cool quote and I wrote it down. In the end it didn’t fit with our brand voice so I couldn’t include it, but that’s the idea. You always have to be true to you brand voice.

I remember Kinneret Yifrach spoke about this one time though, she gave a great example. She was writing an interface for avid readers, or speed readers. Something like that. And she needed to write an error message for when the user lost internet reception. She had been reading a lot of posts on their Facebook group as part of her research — this is a very prolific group. And she noticed that they never said they didn’t like a book, they always said “I didn’t connect” to a certain book. So on the error message she was able to use the same term for “didn’t connect” that they use… it’s a play on words in Hebrew. It doesn’t really work in English but you get the idea :)

The next questions would be… there are a lot of things like button copy, error messages, different kinds of notifications, they don’t even have their own place in the wire frames because wire frames, sometimes they just give you the pattern and everything else is added while the product is being sent live. So is there any special place, a document, a library or anything where the UX writer works? What other tools that can later get passed over to the team?

So I already mentioned Google Docs. What I want to say to this question though, is that if that’s the way things are happening, that’s a broken process. Microcopy needs to be part of the design discussion from day one; the words are an integral part of the strategy and the UX and you lose a lot of their potential power when you marginalize the UX writer in the process. At the very least, use protocopy which I learned from Biz Sanford at Spotify. Even just throwing on the paper something super quick, but that communicates the crux of what you want to say there, is better than nothing. My article was originally published on Content Design London’s blog, which everyone should read and follow — Sarah Richards and her team are fantastic!

There are technical details, like one important thing is capitalization, so that needs to be a part of your guide, but generally speaking, a UX writer is not assumed to be a grammar expert. In the ideal world, if you’re building a truly polished product, would you need another person, a grammar and spelling expert, an editor, come in and look over the copy that you’ve got for the product?

So actually, I believe a UX writer should be a grammar expert. I think a lot of writers get into UX writing because you need to be an English expert first and foremost, and you can learn UX best practices later. I think starting in UX and then moving to UX writing, especially if you’re not a native English speaker, but even if you are, shows some lack of understanding, or respect, for the field. It is very niche, and the skills you need to be good are pretty specific, and I think a deep and broad grasp of the language you’re writing in it critical. What they call in political science, “necessary but insufficient”. And of course, it doesn’t have to be English — there are apps all over the world.

There are also UX writers who work in English and then have their copy translated. But translation and localization is a whole other topic. Maybe we can discuss it if you ever have me on your show for real ;)

Whenever there is a writer and they might not need an editor to edit the content of their work, but every kind of human process needs to be proofread, just because there is always place for human error. So you’re saying there is a level of that above the editor, or above the UX writer?

You always have the input of your stakeholders. But when it comes to proofing grammar and spelling and things like that, I would hold the UX writer responsible at the end of the day.

While we are wrapping up the episode, I would love to have your opinion about a few points, down from the skies to the solid ground of practice. Certain really challenging situations that a lot of us face: Should we say “Done” or should we say “Save”? Should we use action verbs in our call to action buttons? Any other advice like that. Some practical tips that you’re teaching? Could you share a little bit of that with our listeners. And also, please tell me if it’s “log in” or “sign in” because that’s my challenge forever, throughout!

Haha. Yes, that is the $64K question! It’s “Log in”. That’s because you’ll probably also want to say “Sign up” and differentiating “Sign in” from “Sign up” is asking way too much of your user. Your goal is to get them where they want to be quickly, not make them zero in on two tiny little characters, especially so early on in the flow.

To your other question, yes, it is best practice to structure buttons as CTAs. But keep in mind that every “best practice” has exceptions. Once you’re experienced enough, you start to be able to identify where breaking the rules is the right thing to do, and where sticking to convention makes more sense. And when in doubt, you can always test it, of course.

One more question: Are there any software companies and tools that you particularly think are nailing it with their copy and their UX copy?

Slack, definitely. Though there was some interesting discussion a while back about whether their voice is scalable. Again, think of voice as a personality… I think the way any person speaks, even while staying true to who they are, would be different if in their living room with a few friends, or at work with a few dozen colleagues, to standing on a stage in front of an audience of 400,000 people. Once you’re talking to 400,000 people, you might change the way you speak a bit. And that’s, I think, a part of what’s going on with Slack. They really are pioneers and a fantastic model of getting voice right, they are unique and delightful, and never miss an opportunity in the product to express themselves. But they are in front of an audience of millions of users now, and sometimes what used to be cute might sound inappropriate now. But that’s a great challenge to have, to be so successful that you outgrow your voice :)

I think MailChimp is also held up as a gold standard often, and I definitely agree that they are a major player. But what people sometimes forget is that the Slack/MailChimp approach is not right for every product. Far from it. Especially when you work with complex products like I do. There is still a LOT I can learn from them, of course, but it’s important to separate out the cute-enough-to-go-viral element that would be a bad idea to model your voice after in a lot of products.

Thank you so much, Yael! Where can people find you online?

I’m on Medium, at medium.com/@yaelbendavid. I’m also on Twitter at @YaelBenDavid.

Thank you so much for having me! It was a real pleasure. I hope to do it again soon.