UX writing: from craft to commodity?

At the beginning of 2023, I published a spec project on how to support an MVP launch with content.

The project came with a set of content guidelines (remember those?), which included tone of voice and editorial best practices.

I was so proud of it. And it was only three and a half years ago.

Doing something like that would be unimaginable today. I can’t think of anyone who would click on the document, read it top to bottom and then diligently go apply the guidelines. As Rita Kind-Envy says, tone of voice may be the least of your problems.

Less than a year later, our team decided to bring writing guidelines closer to design. We created component-specific specs and embedded them in Figma.

That was actually a clever move back then.We were treating content as a system that extends beyond the page. But we no longer use it. It’s not working anymore.

Now, UX writers like me create skills for a whole host of tasks. We feed them templates, glossaries, taxonomies, audits, rubrics: things we used to write from scratch or even outsource until not long ago.

We use AI to repurpose existing content. We pair with ML engineers on few-shot prompting, LLM content design and fine-tuning. Some of us write copy in a single source of truth so it can be translated dynamically.

What’s left after we’ve trained the LLM on everything we’re good at?

What happens when the tech folks and the non-writers don’t need our input anymore because they’ve already generated three variations of the deliverable on their own?

Are we just going to turn into agent orchestrators after all?

I don’t know. Since I use AI and work at an AI company, it may seem like I’ve already picked sides. Actually, I’m very conflicted.

I listen to both the doomers and the boosters. Maybe the bubble pops tomorrow. Maybe we’ve allowed AI to seep into our work life so much that we can’t come back unscathed.

But while the technology takes care of some lower-stakes, repeatable workflows, other opportunities are starting to emerge.

UX writing is becoming more focused.

There are a few aspects writers don’t have to worry about anymore, and honestly I’m relieved.

Capitalization. Punctuation. Revisiting brand personality every six months. And, as Kinneret Yifrah explains, obsessing over consistency for the sake of it.

These things are no longer a concern, either because a tool can easily handle them for us or because UX writing has moved past that stage.

This means we’ve freed up time for the more interesting stuff: refining user journeys, creating flowcharts that get validated by engineers, presenting UX proposals to decision-makers.

UX writing is becoming more technical.

We use Cursor, v0 or Claude to vibe-code mockups that would otherwise have taken days to design. We discard what doesn’t work faster, without taking bandwidth away from frontend.

On our team, we’ve quickly learned how to bring instructions and product docs to GitHub via VS Code. We open pull requests to push localization strings to developers. And we’ll soon be able to merge them too, which means owning that process end-to-end.

This is scary, even if you like all the new tools and skills you’re being exposed to. And it’s also kind of needed to stay in the industry.

Being more technical means you’re more autonomous, more in demand and part of the wider engineering team. From this position, you can continue to define and oversee how language is used across the product.

UX writing is becoming more context-sensitive.

Greg Petroff argues that proprietary and user data are the two layers that make the difference. Writers generally know who their customer is, what they do at their company, which devices they use our product on.

But do we actually know what these people need to get done, how hard it is for them and how they manage to get around the problem anyway?

We can fill that gap by spending more time with our internal subject matter experts, like actively inviting delivery teams and business stakeholders into the room and asking them for feedback. Or by seeking work with organizations that value and facilitate this kind of collaboration.

That domain expertise is hard to capture and translate to features for humans, let alone LLMs.

Take your knowledge of tasks and intents, and start asking questions. Combine that information with a deeper understanding of the business and user context.

The definition of "expected output" is now a lot more concrete, and it can soon turn into a user journey, a technical spec or a sequence diagram.

UX writing is still very human.

Every function within the product team now has the resources to learn, test and iterate faster than we ever could.

But that doesn’t mean we’re shipping more. We’re all running, but we don’t know where to.

The truth is, you can’t automate the human factor in product development. A lot of experience design still happens over conversations with engineers and customer-facing people.

Technical leads sit in meetings until a decision is made. Then we, the writers and designers, bring that decision to life. More back and forth. We brainstorm. We shave things off. We merge.

And we go back to the leads, walk through our rationale, listen, revisit the flow, cycle in and out of frustration and finally come to an agreement.

If we don’t talk, and if we don’t write things down, features don’t move forward.

That’s not something the machine can easily replicate… just yet.

Let me know what you think. Is this silly? Are we doomed? Should we move to the Alps and learn to make cheese instead?

READ MORE FROM ME

Ciao 👋 I’m Elisa, an Italian product writer who believes good design is service. This is where I document my work in UX.

Go to the blog