Beyond microcopy
I love UX writing (aka UXW). All of it. Not just the microcopy.
‘Microcopy’ is a hot buzzword, and for good reason. User interface (UI) copy has not gotten enough attention in the past and it’s certainly overdue for some serious recognition, thought, and community to leverage for developing best practices and solving common challenges. However, as a UX writer, writing microcopy is only about 50% of what I do.
🔍 Related: What is UX writing?
Here are other aspects of the work that I love.
Content design
I love working with designers to make sure the design fits the copy and not just the other way around. When we lean into the synergy, everybody wins.
One story I tell about this is when a designer asked me, “Is my (placeholder) button copy too long?” It was way too long. But the solution wasn’t to bring in a writer to make it concise. The solution was to redesign the element so that there was room for a question above the button, and then break the button into two — “Yes” and “No”. That’s content design. Structuring the content in the way that gives the user the best experience possible and working the visual containers around it.
Another time, the team was stuck on how to word button copy to accurately manage expectations: We wanted the user to fully understand that they were about to make an irreversible commitment to one product over another; however, once committing, they would be able to customise the product they chose. So on the one hand this was a very final moment, and on the other hand, it wasn’t the end. In was a PM who came along and said, “What about helper text”? After 50 iterations on the button microcopy, we ended up changing the content design, adding a line below the button, that together with the copy on the button, got the job done.
Helper text got the job done where button copy couldn’t do it alone.
Restructuring content like this is critical for creating the best user experience and that kind of thinking outside the box may not be something you’re used to if you’re in an exclusively microcopy frame of mind.
Voice and tone
This includes development, documentation, distribution, and quality control.
Development: Working with stakeholders to determine the personality of the brand, identify the persona of our the users, and then create high-level guidelines as to how the conversation between those two sides should sound.
Documentation: Getting the final decisions down on (virtual) paper. Thinking through what to include and how to publish it — is it a Google doc? A Confluence page? A website? Then getting feedback and iterating and then final approval, all with the caveat that this is a living breathing document that will continue to evolve, both because the product and user base evolve and because you get smarter as you go.
Distribution: Who do you share the documentation with and what education do you provide along with it? You can’t just blast an email to the entire company and expect anything to actually happen. You can build interactive online modules using programs like Lessonly, you can plan live workshops with individual teams, or take any of a number of other approaches. Planning and executing the distribution of the voice and tone is a critical yet often overlooked part of the UX writer’s role.
Quality control: We also set up processes to make sure that the voice and tone are applied comprehensively. Who should a writer go to if they have a question they can’t answer from the documentation? Are there “spot checks” to catch copy that is not aligned? Do you implement a tool like writer.com which works as a sort of Grammarly-like plugin for voice? It’s not enough to create a voice, it’s the UX writer’s job to follow through to the end and ensure the voice comes alive.
Style guide
Like the voice and tone, this also includes development, documentation, distribution, and quality control.
The style guide is the nitty-gritty of the voice and tone guide. Here is where you dive into your company policy on capitalization (title case on buttons? sentence case everywhere? etc.), spaces around em dashes, British vs American English, date formatting, etc. Some of these decisions reflect the voice and others just need to be documented for the sake of consistency. People need a source of truth to align to because the user should be interacting with a product — not with a marketing team, product team, UX team, R&D team, etc. All communications need to be cohesive and consistent because they all reflect a single personality: your brand voice.
Plain English translation
If we don’t point out to the lawyers that our users don’t speak legalese, no one will. At the end of the day, legal and compliance departments have similar interests to user experience people — we all want the user to have all of the information they need and we want to adhere to guidelines that are often there to protect the consumer. By working together, we can optimize transparency and trust factor (and learn a lot on the way)! There are a number of approaches to translating legalese for our users: providing parallel plain language documentation; sprinkling plain language summaries throughout legal documentation; replacing legal documents entirely with versions normal people can read, and more. As with everything we do as UX writers, it depends on empathy for stakeholders as well as for our users, and on collaboration.
Accessibility
From a) researching and mastering best practices and even laws, to b) auditing the existing experience, and c) leading implementation of improvements, the accessibility of our content is our responsibility. Thankfully, there has been an explosion of resources made available in the last couple of years to guide us, like the Readability Guidelines.
It can be an incredibly daunting task. And it may take considerable effort and planning to get stakeholder buy-in and to carve out time in our day-to-day to dedicate to it. But it also may be the most rewarding part of what we do — our little slice of the human effort to make the world a better place.
Research
Maybe this should have been the very first section because it comes before all the writing — getting to know the users. Researching how they use the product and why. What’s working and what isn’t. What they understand and where they need help. What resonates and what alienates. Researching our users is fascinating and surprising and fundamental to doing our job well, because writing a digital product is not like writing a poem or a book where success is more or less in the eye of the beholder. When we write a UI, it’s not for us, and it’s not to be judged subjectively. UI writing is “good” when it works for our users and in order to achieve that, we need to start with research. A few of the many helpful tools out there are fullstory, usertesting.com, user interviews, and listening to support/sales call recordings.
We also need to continually stay on top of the latest research when it comes to UX writing best practices. Plenty of conventions have been updated based on data and to do our job well, we need to at least be constantly learning from others’ research if not also contributing research findings to the community ourselves.
Testing
Unlike a lot of other forms of writing, our work is not done once we publish. In fact, publishing means we’re only about halfway there. The next step is to track our copy’s performance and plan the next iteration. This part can be exhilarating! Proof there are real live people interacting with YOUR words to accomplish things!
But not always. I can’t say I love surprisingly disappointing results — like the button copy I was SURE was going to double engagement, actually had no effect at all, or the subject line I changed for compliance purposes but didn’t expect to hurt open rates and ended up slashing opens in half. But even in those cases where you have to make set your ego aside and make changes, it feels good to know you’re doing the right thing by your users, even if that takes a spoonful of humility.
Content ops
The depth and breadth of the work we do, and the fact that we’re usually a very small team relative to the teams our work touches, means documentation and process are crucial.
Owning content ops means, among other things, managing the documentation of copy iterations, decisions, and current “inventory” of strings in production.
New tools like Ditto, Frontitude, writer.com, and more are starting to fill a painful void that was previously patched with Google docs, Excel spreadsheets, and other nightmares.
Content ops also includes taking responsibility for company-wide education around UX writing. Everything from creating onboarding modules around the voice and tone for new employees and running ongoing workshops for ICs across the company who write user-facing copy, to simply being an accessible resource for questions about “how this whole copy thing works”, is part of running the operation.
🔎 Related: Five ways to be a better UX writer
Community and advocacy
Content design is growing fast and everyone involved is shaping the field. Each and every one of us has unique experiences and knowledge to share with the community.
For me, writing about UX writing, speaking about UX writing, participating in the UX writing community on Twitter, LinkedIn, Facebook, at conferences, meetups, internally at the companies where I work, and shouting from any rooftop I manage to access — that’s fun! And it’s important. Because we don’t have time to repeat each other’s mistakes or to make the same arguments to get UX writers “a seat at the table” when even better cases have already been crafted. The product content community is an amazing place to grow and make an important impact on the end experiences that in this digital age, make so much of the world go round. Being part of the community and leveraging what we learn from each other to advocate for more investment in UX writing, essentially unleashing the potential it has for the success of any product, is one of the things I love most.
Collaboration
Collaboration is certainly not least, though I’ve left it for last, because in a sense, it’s included in every section above. Here though, I want to highlight the personal growth that comes from collaborating daily with engineers, designers, product managers, compliance officers, and everyone else. There is so much to learn from the different experts we work with, the perspectives they bring that are different than ours, while working toward the same goal.
Collaboration doesn’t mean sharing a doc for the sake of iterating in the comments, it’s sitting down and having a conversation about those comments — why they were made, what’s the context, what are the considerations when making this decision, where is each stakeholder coming from, aligning on the goal and figuring out how to leverage what everyone has to offer even when they seemingly conflict. These conversations can be mind-blowing. And at the right company, the people themselves are interesting, too. I can’t tell you how much I’ve learned while working on copy, that has nothing to do with copy. Sometimes it seems like I should be paying to do my job, instead of getting paid to do it.
=====
These articles may also interest you
