A framework for designer–writer collaboration.
A lot has been written about UX writing (also known as content design). By now, many product teams understand the value of having dedicated UX writers to protect the product narrative. I’m an avid proponent, too.
Something that’s less often defined is what happens after a product team hires their first UX writer.
If you’ve operated without one for a while, your product copy might need some love. You’d likely also benefit from a style guide and content design standards. These things are essential to your product’s success.
But have you considered how UX writing will actually live within your team and workflows?
- Which type of work will be assigned to writers?
- When and how will designers collaborate with writers?
- How much time will be needed from a writer per project?
These are tough questions to answer. There isn’t one magical solution to rule them all, either. Each team has unique needs, depending on the type of products and resourcing they already have in place.
That being said, there is a common reality shared by many product teams: there are simply more words and content design problems to solve than a UX writer can realistically devote deep attention to.
This happens because the role is still taking root. Even if teams see the value, they have to inspire buy-in from decision makers, and it’s an oddly specific skill set that can be hard to hire for.
So the first UX writer on the team often works on many types of projects, maybe across many products, while supporting many designers.
My past year as a UX writer at Amazon has been a similar story. I support 10 designers and work across 5 products with many more product teams. Sometimes I work on cross-functional projects that include designers in adjacent UX teams. I’ve also worked closely with my fellow UX writer (and more recently another 😄) on our sister team to create and maintain a style guide spanning all of our organization’s products.
In other words, there’s no (sane) way for us writers to dedicate our undivided attention to all of the things, at all times. The thrilling-yet-daunting game of Whac-A-Mole comes to mind.
This means that we have to be as efficient as possible with our time, and provide the most value we can, at scale.
We do this through a mix of self-service solutions, like our style guide, and mechanisms for visibility and collaboration, like daily standups and weekly design reviews. We even have UX writing “office hours,” a dedicated time to provide writing feedback to designers and PMs on the fly. (If you can get past the weirdly academic-sounding name, it’s super helpful.)
One puzzle piece we’d like to get better at is understanding how much of our time is needed per project, and earlier.
Being the systems nerd that I am, I took some time to evaluate the types of projects I’ve worked on, how I’ve collaborated with designers and our product partners, what’s worked well, and what hasn’t. I’ve found that there are 3 categories that all of my work has fallen into.
Own, partner, or consult
Generally, it’s worked for me to either own a project, partner with a designer, or consult with a designer. This is what’s worked for determining which model of engagement makes sense for the project:
Own
The UX writer “owns” the project, meaning they’re the UX lead
The UX writer is responsible for the content strategy and writing, and for selecting the appropriate design components. They consult with a designer as needed.
This works well for projects that are writing-centric and don’t require new design work, meaning the writer can reference existing design components without needing to design new ones.
The scope of UX writing can be of any size, as long as the design scope is minimal. In theory, if a UX writer has design experience, they could work with an expanded scope of design, depending on their interest and the team’s resourcing needs.
Partner
The UX writer “partners” with a designer on the project
The designer is the UX lead, responsible for the overall design and strategy, and they’re the UX point of contact. They collaborate closely with the UX writer, who’s responsible for the content strategy and strings.
This works well for new product and feature launches. It also works well for projects that involve complicated features or flows, even if the quantity of writing involved seems small.
The UX writing scope, in other words, should be large to medium.
- Large scope means that the writing involved requires independent work time and additional meetings outside of standing meetings, such as weekly design reviews and writing office hours.
- Medium scope means that the writing or feedback involved requires time outside of standing meetings (even if minimal time).
Consult
The UX writer “consults” with a designer as needed
The UX designer is the UX lead on the project, responsible for the design and strategy, and for using the appropriate writing patterns. They consult with a writer as needed.
This approach works well for projects that don’t require extensive or complicated writing — they just might benefit from a writer’s perspective and quick feedback.
The UX writing scope in this case needs to be small. Small scope means that the writing or feedback required can be provided during standing meetings. That being said, sometimes projects like these will increase in UX writing scope as requirements change. If more time becomes needed from a writer, switch to the “partner” model.
Flipping it and reversing it
You might notice that the “own” and “consult” categories are simply inverses of one another. While this framework is meant to determine where a UX writer should be involved to support a designer, it could easily be flipped to determine where a UX designer should support a writer.
It might be strange to think of it that way, especially given the current reality of an often tiny ratio of writers to designers. But if you think about interfaces that are text-forward and visually simple, this approach makes a lot of sense.
UX writers need to be design thinkers in order to solve writing problems effectively. There’s a lot involved besides “wordsmithing.” Information architecture, especially, is critical to great UX writing.
If UX writers have the experience, skills, or interest in becoming more hands-on with design, similarly to how many UX designers hone their writing craft, teams could really benefit from rethinking their UX resourcing in this way. To what extent tactical design skills should become a hard requirement for UX writers is another topic for another day.
Conclusion
While this framework is by no means set in stone, it has been a helpful way for our team to assign work to UX writers. As we continue to use it, we’ll continue to iterate based on our evolving needs and as we learn more. Stay tuned for updates.