The writer should own the text during your design process.
For this to work, you and your team will have to agree on what the writer, own, and the text all mean.
Being the writer
Irrespective of job titles, someone’s role in your team’s design process must be writer. If that label conflicts with someone’s sense of identity (or the org chart), you can call them an Interface Writer, or Content Specialist, or Word Wrangler, or Captain Comma. The label for roles isn’t important if you’re clear about the responsibilities.
This person does not have to have “writer” or “content” anywhere near their job title — it could be anyone willing to occupy the role. The more experience that person has with writing in a design context the better. But there are other important skills a design writer needs, like being able to understand and respond to user needs, conduct or analyze research, coordinate with subject matter experts, and so on. Even if your team is just one designer and one developer building an app in a weekend startup competition, one of you needs to be the writer.
If you don’t articulate and assign the writing role, then either everyone is the writer, or no one is the writer. Neither situation is fun, and will make words a weak spot in your designs. When everyone is the writer, it gets very hard to keep track of what’s true about the text, and will slow your process down. It also leads to a lot of subjective bickering; often, there are any of a dozen “right” ways to say something, and you need a writer to just make the call. When no one is the writer, design teams draw lots of squiggly lines to represent where they think text should maybe go, but never get around to understanding the purpose of that text in their design, let alone what it should actually say. That means the actual design is only halfway done. So: have a writer!
The writing role does not have to be exclusive to other roles. One can be the writer and the designer, or the writer and the researcher, or the writer and the project manager.
The writer’s role can be occupied for as little or as much time as is sensible. One could be the writer for the life of:
- A workshop (wear the writing hat for 90 minutes)
- A sprint (you’re the writer on this for the next two weeks)
- A release (you’ll lead UX writing for this feature)
- A whole product (you’re our UX Writer, welcome to the team!)
Design teams for big tech products are moving toward that last one, and hiring dedicated UX Writers to serve in the writing role. But that’s only one way to handle it. Your designs need words whether or not you have a full-time UX writer. Writing interface copy is a design skill, and it’s perfectly fine to have designers in the writing role.
Owning the text
The most important job in the design process for your writer is to own the text.
Owning the text means having responsibility for the words in the design. If you’re the writer, you are the person who will care the most about the words. On mature UX teams, that won’t mean that you’re the only person who cares about the words, just that you’re paying the most attention to them.
Practically speaking, owning the text means being the sole source of truth about copy during the design process. It probably doesn’t mean making or approving every decision about the words. It just means that you know what’s true and not true about the copy in the design. Has this text been reviewed? Is this draft copy or final? Does this part of the text need to go through legal? And so on. If a spreadsheet or Google doc or a tool like Gather Content or Qordoba helps the writer manage that truth, great, but a person still has to manage that responsibility.
In the book, I talk about how being the writer on a design project doesn’t necessarily mean writing original words. Just as a designer can “do design” by selecting, arranging, and optimizing elements from a design pattern library, a writer can “do writing” by collecting and applying copy and UI strings from other sources (e.g. copy decks, testimonials, controlled vocabularies, existing workflows, or — here’s a crazy idea — design systems that include content). The writer could also manage other writers and subject matter experts to help get the writing done. (In these cases, a label like “content specialist” might be more appropriate, but the spirit of ownership and ultimate responsibility remains the same.)
My personal favorite way to “do the writing”? Help the team reconsider the design such that words are no longer necessary! Sometimes this happens just by having a writer ; by the time the designers finish explaining what need to explain to users with copy, they’ve realized there’s a simpler design solution that won’t require explanation.
Scoping the content
A writer has to know the actual scope of the text required by this design. This might be harder than you’d think. A single screen or webpage is often comprised of several very different sorts of text: User-generated content, information populated from databases, persuasive marketing copy, user interface text like button labels, user assistance text like tooltips, and more. Not all of these requirements are obvious, especially if you’re working from static wireframes.
Broadly, the writer is going to:
- Ask lots of questions to generate a list or inventory of content required by the design
- Share those requirements with the team
- Write/find/collect the words that satisfy those requirements
It’s more complicated than that in practice, but that’s the general idea. I get into ways to scope writing assignments and frameworks for talking about different types of copy in greater depth in Writing for Designers.
Another difficult thing about scoping content requirements: Your design will probably become part of some larger thing, like an onboarding workflow layered onto an existing app or an article that lives on a webpage that’s part of a larger site. Understanding what’s part of your team’s design work, and what’s part of something else, will take some digging. It may be that your team needs to include text in your design that you’re not equipped or even allowed to write — better to discover that now than later.
On good teams, this is all a collaborative process, where the writer contributes on equal footing in all design conversations. It should not mean waiting for the wireframes to be “ready” and “filling in” the words.
What happens to the text when the design is done?
When the project is over, your design-process text will become in-product content. The ingredients become the cake, so to speak. At this point, your content governance or product management framework should help determine who owns the in-product content going forward.
This transition from design material to content asset is more complicated than it sounds, and why product teams need content strategy, too!
The writer may need to continue serving as a source of truth about the text after the rest of the design team has moved on, depending on how the thing you’ve designed will be built/implemented.
What happens to the writer when the design is done?
Everyone buys them a drink! 🍻