There’s No Such Thing as the UX Writing Process

Arbitrarily dividing your team’s design labor and processes between stuff you’re comfortable with (UI) and stuff you’re less comfortable with (words, for my purposes, but also user research, market research, accessibility, etc.) means that closely-related design choices—choices experienced by users as part of the same components, screens, flows, and experiences—get made separately, by separate people, at separate moments in time.

Do I have to explain why that’s bad? I guess I do!

For starters, it creates needless process friction, such as additional “hand-offs” of design comps to writers and back again. It also reduces the ability of designers or writers to create elegant solutions. When that work isn't on the same track, it’s harder to solve design problems with words and word problems with design.

One process to rule them all? 

Users don’t evaluate or experience the UI and the words within it separately. The words depend on the design that depends on the words. So why the process separation? Why do so many teams seek to establish a singular and discrete “UX writing process”, separate from the rest of their design activities?

Perhaps they don’t. But I’ve been led to believe otherwise, in part by the many job descriptions I’ve read, many of them for mid-to-senior level UX writers or content designers who will be the first word-focused designer for a given product team or organization. Invariably, those JDs include phrases like “establish our UX writing process” in the list of responsibilities.

The impulse is understandable—you’re tired of stalling out on the words; of having to sift through piles of stakeholder opinions on what to say and how to say it; of feeling like this shouldn’t be so hard and if we could only come up with a repeatable process for “doing” the UX writing, everything will work out. So you decide to hire a writer/designer of some kind who knows how this stuff works. Except then you ask them to:

1. Establish a new process, new standards, and related workflows for “UX content”.
2. Not change anything at all about how you already do design work.

Neither of those are correct. The error wasn't thinking that you would benefit from hiring a design specialist whose core competency is writing (you would), nor was it your general desire for structure. Standards, workflows, and systems are all good things.

The primary error was believing in one singular approach you can point to and call the UX writing process, the content design process, or the product writing process, and that it’s discrete from the rest of your design work. You don't want a wholly separate process, and you don't want to trap your design process in amber—you need to help it evolve to a point where you and your team are finally taking words seriously.

Writing the interface is a design activity, not a “content” activity. There will be any number of word-related tasks and activities necessitated by your design work that you need to identify and plan for, and you will need to plan them in tandem with the rest of your work. This scoping and planning process—the process of figuring out what all needs to be written, by whom, to what end and what level of quality—that’s the part you can and should formalize.

You have to talk about how to get the writing done every time.

Let me put it more simply: You have to talk about how to get the writing done every single time. Doing so is normal and good.

You have to talk about it every time because every sprint and project is different and will require different kinds of words and different quantities of words, all to potentially be written, reviewed, and approved by different people. These details depend on the thing that everything else in design depends on: context.

Interested in product writing? Join my Product Writing Crash Course workshop on July 22 — only $99.50 for a limited time!

Align on how to get the writing done with your team.

Whether or not you have a dedicated writer, your product team will need to align on an approach to get the writing done for your design projects and sprints. Let’s explore how.

1. Assign roles and responsibilities.

As I am fond of saying, someone has to do the writing. Even if you’re leaning heavily into generative AI, some individual human being still has to prompt the AI and assess, edit, and implement its suggestions. There are many valid approaches to doing the writing, and even if yours involves a lot of ⌘C and ⌘V, that’s still a role you need to assign.

If you’re lucky, the writer (role) for your project will be a writer—a craftsperson who specializes in the type of writing that needs to happen. For interface copy, that might be a UX writer. For onboarding or support content, that might be a technical writer, or a product marketer for an announcement or update.

But the role of writer might well land in anyone’s lap: a designer, a developer, a PM. That is also normal and good. If the person being assigned the writer’s role does not feel especially comfortable with writing, that’s something you can account for in your planning, just as you might account for any lack of specialization on your team that the current work requires (e.g. animation, video editing, accessibility).

Consider: Who will choose the words in our interface? Who will write any content necessitated by our design work, such as help text, onboarding guides, or new support articles? Who will need (or want) to review the UI copy and any related content? Who will need (or want) to approve the UI copy and any related content?

2. Articulate and scope the writing work.

Design solutions often create new content problems—changes to the interface, big and small, often mean that other kinds of content are now out of date, or that new content needs to be created.

To scope the writing work necessary to support your design, you need to consider the overall impact on the experience. Some prompts:

• What impact might this work have on existing documentation?
• What impact might this work have on existing marketing content? Will any new marketing be required?
• What communications to customers or other stakeholders might be necessary as a result of this work, and through which channels?
• What internal stakeholder groups might be interested in the words and writing that are part of this design? Brand? Marketing? Localization? Legal? Sales?
• What content and interface copy might exist outside of the primary flow we are changing or designing? Error messages? Empty states? Pre sign-in?

3. Identify relevant inputs.

Originality is prized in novels and essays, and at some point before Speed II: Cruise Control, it was prized in movies, too.

In product writing, however, originality can work against you. Novel terms, patterns, and turns of phrase can confuse users. Originality can also create unnecessary work; it’s exceedingly rare that you have to start completely from scratch. There is language to take inspiration all around: in your existing product, in the way your users talk about the experience in research sessions, in your style guides and design systems, in books (I’m fond of The Yahoo! Style Guide as a desk reference for interface writing), and even in your competitor’s products.

Before you start a blank new document and hope the words come to you, identify any relevant inputs and references that might shape your writing, be they documentation, marketing content, research transcripts, stakeholder interviews, empathy maps, journey maps, experience and content audits, or anything else that seems to have bearing on your work. The more stuff you have to look at and work with, the less likely you’ll get stuck.

4. Establish process milestones.

Even if much of the writing and design happens in tandem, it can be useful to establish milestones specific to interface copy and content work.

For instance, putting a content critique session on the calendar could drive the work that needs to be ready for critique and keep it from stalling out. You might also plan any number of workshops or other design activities to support the writing work, such as design studios (sketching workshops), content-focused research sessions or usability testing, and pair writing and co-design.

This part will be tricky until you find the cadences and rituals that work best for your team. Don’t be afraid to experiment! And please: don’t throw any babies out with the bathwater; just because a given method or workshop doesn’t give you the results you want on the current work doesn’t mean it can’t work well in another context.

5. Write in increasing levels of fidelity.

Even with a robust component library and design system, UI design work still tends to proceed in a progressively iterative fashion: sketches to wireframes or rough comps, wireframes to polished comps, and on through various prototypes and test deployments until you can hand-off to engineering.

There’s no reason you can’t work the same way with the words in your designs and documents. In fact, I recommend it. Effective writing does not tend to come out perfectly formed on the first try. Working iteratively, through multiple versions and refinements of the text, will give you better results.

Fidelity is not always as apparent when it comes to words, so you might try conventions like putting rough draft copy in a prominent off-brand color or a handwriting-style typeface; anything that says “hey, this isn’t quite done yet”. This gives you the freedom to start with really rough copy, or even quick bullet points that describe what content you still need to write. Approaching the writing work in this way ensures that you can keep evolving it alongside the rest of your design work, rather than waiting until the “end” and then trying to “fill” your design with words—a recipe for disaster, or at least for bad work.

6. Collaborate and learn through workshops, critique, and ongoing feedback.

Assigning the role of writer ensures that someone takes responsibility for getting the writing done, but that doesn’t mean that they have to get it done alone. Smart teams apply their existing product and UX design skills to developing effective interface copy and compelling and useful content. Continue to look for opportunities to involve multiple parties in the writing work. Engineers can help ensure the accuracy and clarity of interface copy. Product marketers and researchers can provide insight into language that resonates with customers. Members of your support or technical content teams will have insights on the types of things that users find challenging or confusing. Members of other design teams can weigh in on how they’ve handled similar patterns, or how your terminology choices might resonate or conflict with other terms in their part of the experience.

7. Take the words seriously.

Commit to product writing as a team competency. Schedule trainings. Take a workshop (ahem). Talk about words and content in your retrospectives.

Continue to learn and adapt. Keep an open mind. You're not going to get it right the first time. What you learn about process on one project may not fully inform what you'll need to do on the next one. And don't be hard on yourself (or your designers!) if the writing work doesn't go swimmingly from the start. As Jake the Dog tells us, “Sucking at something is the first step towards being sorta good at something.”