So what’s the difference between microcopy and UX writing?
The growth of UX writing and content strategy has sparked all sorts of great conversation and debate. Whether you call yourself a digital copywriter, content specialist or UX writer, there’s a growing set of expectations around the role and what you should contribute to a design team.
That’s all fine. Great, even! But it also means there’s a lot of misunderstanding about what a UX Writer is, and what it isn’t. This conversation is complex — and there should be room for nuance — but there is one misconception we need to clear up right now:
UX writing is about much, much more than just microcopy.
How Google would answer that question…
As a UX content strategy lead at Google, we had a defined understanding of the role of content strategy, UX writing, and microcopy. Each one of these roles is responsible for deciding the right thing to say, to the right people, at the right time. The obvious difference is the scope.
The overarching discipline with the broadest mandate is content strategy.
UX writing is narrower, focusing on product writing for the end-to-end user journey.
Microcopy just defines a category of UI text that falls solidly within UX writing. Calling all UX writing “microcopy writing” is just—wrong. You can think of UI text and microcopy as interchangeable, but UX writing is much broader than that. It describes the customer-facing communication at every point in a long customer journey, not just the bits of UI text that accompany components.
Let’s go a bit deeper.
UX Content Strategy
If you take any large body of writing intended to serve the various audiences a company speaks to, you’ll need several strategies to serve that content appropriately. You’ll need:
Whether your audiences are internal, business-to-business, analysts, the press, or consumer customers, some group must determine the right thing to say at the right time. Corporate communications, public relations, marketing, and business development teams will have distinct areas of responsibility. A UX content strategist or a UX writer will advise these groups, often writing the text or providing directional input.
Managing the repositories and content management systems (CMSs) for large bodies of content falls under the “governance” label. At Google, there’s a heavy role for database and search engineers for this work, less so for content strategists. At Intuit, we used a tool called Madcap Flare. It required content strategists who could serve as build engineers for the giant help systems it supported. Companies that use Drupal or similar tools might also have content strategists who bridge between tech writers, system administrators, and content creation.
…aka writing. Most UX content strategists are also writers. All UX writers write microcopy. Not all microcopy or UI writers can say they’re UX writers because they might not be looking at the whole experience.
Junior UX writers are often in charge of microcopy while more senior UX writers and strategists design for the whole narrative arc of a product journey.
So, we’ve covered the basic difference. Now let’s talk about user experience writing. It’s content design. It’s UI writing. It’s experience design. It’s content strategy for products.
UX writing is about much, much more than just microcopy.
We’ve seen this pop up a lot. Whether it’s in social media groups, advertisements, job descriptions, online courses, etc, too many people who’ve never done the job are floating the idea that UX writing is really just crafting copy for buttons and error messages.
Recently, Scott Kubie referenced this in a must-read Twitter thread:
This is spot on. Any UX writer worth their salt will tell you that microcopy creation comes at the end of a writing and research process. The initial design work can take weeks or months. But the discussion needs to go even further than that: we need to undo the thinking that isolates “microcopy” as anything other than the culmination of a robust research and design experience.
Visual designers can relate. It’s the equivalent of saying you guys “make things pretty.” Or worse, “Anyone can pick colors.”
I understand why people are focusing on microcopy so much: it’s a deliverable. It’s something we can actually see, understand, and react to.
Don’t get me wrong: microcopy is an essential part of the UX writing process. We think of it as “confetti” that brightens and delights throughout the experience.
But there’s a whole cake underneath it
Praising microcopy alone minimizes the work that goes into the rest of the process: voice development, narrative arc creation, interaction design and task flows, info hierarchy, error prevention, concise guidance and nearly invisible but encouraging instruction and context at every single step in the user journey. Literally all the words in the interface—not just the cute ones.
Focusing on microcopy minimizes the role of the UX writer
The majority of your job won’t be spent writing this microcopy — it’ll be understanding all the context that gets you there in the first place. And it’s important for new UX writers to understand this, because setting expectations is everything. If you walk into a job thinking your entire role will be creating little moments of delight with funny and quirky copy, then you’re going to be sadly mistaken when you’re sitting in front of an Excel spreadsheet conducting your 20th hour of a messaging audit!
At Google, and at most large software companies, UX writers are interaction designers for product content.
So, what does the real process actually look like?
Most UX writers will experience something like this:
Your design team starts with a hypothesis
Together with software engineers, product managers, business analysts, UX designers and anyone else in the group, you start with an idea. That idea is always based on solving a problem for the user first, and working with your business goals at the same time.
The business goal might be to increase active use, introduce a new feature, convert more people from trial to subscriber, prevent dropoffs, or it might be bigger than that. Maybe you’re launching a brand new product and you need to teach people everything about how it will help them and how to use it.
For argument’s sake, let’s say you work for an ice cream delivery app company. Now, a business requirement has come down to your team: currently users need to get through 6 screens to order ice cream. You have to reduce that to 4 because data is showing users abandoning the flow.
You start gathering data
Heatmaps, traffic, user interviews, recordings. Everything you can get your hands on to understand the problem and how people interact with it. If you’re more technically minded you might be doing some SQL queries to find the data yourself. You partner with your design team to break down all the clues.
Then, you start creating ideas
With your goal in mind, the team gets together and starts ideating: what could we do to make sure that users only see 4 screens instead of 6?
Together, you put ideas on the table and you may even start sketching them out. You’ll debate on what might be the best idea, and then you think about time frames. For instance, you might have ideas that require building new components — which could take weeks or months.
Once you have an idea, you build a prototype
Together with the designers, you’ll start creating a prototype. You’ll actually write some rough copy here, but it’s not going to be your final. Instead, it’s going to be your content prototype. You’ll put it in front of users to test it.
You start prepping your test questions
Together with UX researchers, you’ll start figuring out what it is you need from your test users. As a UX writer, you’ll be focused on copy: what language will resonate? Is the copy clear, concise, and compelling? Does it make them curious and motivated? Is it useful?
This is an important phase. Designing questions and scenarios is a key part of your role, and you’ll need to understand a lot about human behavior to do it well.
Synthesize the results and put them back in your prototype
The UX researchers will likely run the tests, but you’ll still have a key role in determining what direction you should take based on users’ feedback.
This is much, much harder than it sounds. Especially because user behavior can tell you one thing but mean another.
There’s a great scene in The West Wing where the White House communications director Joshua Lyman speaks with a pollster. Lyman’s pissed because some polling data shows people in five key districts don’t back a proposed gun control law.
Lyman says they need to tone down their gun rhetoric as a result. The pollster asks: why not dial it up?
“Numbers don’t lie,” he says.
“They lie all the time,” the pollster replies.
The pollster is right: there is more than one way to analyze behavior, and this part of the job gets difficult. It’s here where you’ll spend a lot of your time — figuring out what people want is hard. They might say one thing and do another. They might not know what’s possible and discount solutions.
Your job is to understand the user’s mental model, their current basis for understanding, and shift them to understand what it is you’re offering.
Finally, you polish
Based on everything you’ve done so far, you start crafting copy.
See how this comes at the end of the journey? Now that you understand the problem and the context, writing microcopy comes within a fuller context that will take the scope of the users’ needs into account. Writing messages at the beginning of this journey would negate all the discovery you’ve done.
(Side note: this is exactly the process outlined in an online, self-paced UX writing course we recently created.)
Skipping straight to microcopy is like building a house by focusing on the style of your door knobs or the color of your walls before the framing is planned out.
UX writers are part of a thorough design process, and microcopy is just one outcome of that process
By helping UX writers learn about the entire UX process and not just the “fun” parts, we’ll encourage more UX writers to be accomplished, talented, user-centered, and fully integrated into design teams.
This blog post was originally published on Medium.