[ 9 ]

What to Do First

A good plan, violently executed now, is better than a perfect plan next week.

—United States Army General George S. Patton

If you take nothing else away from reading this book, I hope you know that the purpose of UX content is to meet two categories of goals: those of the organization and those of the people who use the experience. To meet those goals, you’ll need to listen to people, prioritize the work, and collaborate with your team.

Decide What Is Urgent and What Is Important

Prioritizing the work is its own challenge, even when the priorities of the organization and the people using the experience are clear. Even when writing the work is tracked and the process is established, it can be difficult to make sense of what you should do first, or even next.

I like using the Eisenhower Matrix for UX content tasks, which categorizes work according to importance and urgency (Table 9-1). Any task or work item is either urgent or not urgent, and either important or not important. The four categories come with implied actions:

• Urgent and important work should be done first.
• Important but not urgent work should be scheduled for later.
• Urgent but not important work should be delegated to people who find it important.
• Work that is neither urgent nor important should be discarded.

Table 9-1. The Eisenhower Matrix, as applied to UX content tasks to be done

	Urgent	Not urgent
Important	Do Design new experiences Unblock design, engineering, research Write text that affects liability	Schedule Repairing existing, broken text Research into effectiveness and usability Updates to voice and terminology Partnering about design strategy
Not important	Delegate First drafts of common, edge-case, or error text	Discard Arguing about grammar, like prepositions at the end of sentences

Work that is both urgent and important should be prioritized over any other work. This includes work that other people are currently engaged in, like developers coding new experiences or updating current experiences, or having just uncovered a failure case for which they need a new error message. This also includes future-facing design and research, keeping designers and researchers unblocked. Designers should have the best possible words before their designs are reviewed, and long before coding. Researchers should have the best possible words in their usability and concept studies to evoke the information that will be the most useful later on.

When work is important but not urgent, we can track it in the work-tracking system and schedule time to do it. This work includes all of the content that UX writers recognize as broken but nobody else is working on. We can make time to create new content for those experiences and lead those projects. These changes are not to be made lightly; we will need to communicate the changes we want and the impact we expect those changes to make. Part of the work will be to articulate how the content underperforms now, and how we will measure the effect of the changes.

When work is urgent but not important, it is not expected to help reach the goals of the people using the experience or the goals of the organization. Writing this text should be delegated to the team member it is most important to. This might be the first draft of a rush-out-the-door experience, notification, or message. Letting other people do the initial UX writing might seem strange, but it’s a great way for teammates to express what they need out of the content. They can put far too many words in, and, if necessary, we can glean what they intend, clarify with them, and help them simplify it. It can save time for both of us and give us the opportunity to build a more solid partnership.

When work is neither important nor urgent, it’s OK to not do it at all. This includes almost every argument I’ve had over grammar, commas, and hyphenation, except where the text change would change the meaning of the phrase. Arguments are an important part of the mix of communication in a healthy team, as long as people are basing their arguments on how best to meet the goals of the organization and the people who will use the experience. But even more important is to build the kind of collaboration in which the person responsible for the words can be trusted to make this kind of decision.

Ground the Content in Empathy

When we create experiences, we need to care about the people who will use the experience. When we don’t care, we risk failing at our core task: to make experiences that meet our goals.

The root of caring is to believe people about the experiences they have. Their experiences can be similar to your own, or they might be literally unimaginable, but we don’t need to imagine them. We must listen to what actual human beings say and observe how they behave and believe that we are hearing their story.

When humans listen to a person’s story, they tend to produce the chemical of caring: oxytocin. When writers listen to a person’s story, we get that oxytocin and more.

For a writer, the simple act of listening uncovers a gold mine. When people tell their stories, they are likely to use the words they will find recognizable. By listening, the writer learns the grammars that the people already understand. The writer learns the emotional lading of the jargon specific to the people’s experience.

When the writer then uses these words, they can create an experience that connects people to the experience without feeling like they are reading.

To write effective UX, work toward understanding the concerns, needs, and the words of the people who will use the experience. Go out and listen to them. Bring them in and listen to them. Watch videos of interviews with them, and seek to understand their point of view. This research will give us an appreciation not only of where they’re coming from, but also of how different our own perspective is.

And while we talk to people outside the organization, don’t forget the people on the team. These people, with their opinions, viewpoints, perspectives, and prior knowledge, will have an enormous impact on the experience, too. There are people invested in making a great experience all over the organization, including the marketing directors, general managers, directors of design, heads of engineering, engineers coding the feature, program managers, product owners, designers, and the sales and support agents.

Anybody, and everybody, can have opinions about words. How to use those words might not be well understood, especially when there hasn’t been a dedicated UX writer.

Introducing UX Content to the Team

If you accept a job as the first content person in an organization, they might think that you’re there to “choose the right word” or to “check the words.” They probably think of it as a word problem: “We need to explain,” or “We need them to understand…” Or, maybe it’s a UX problem: “We need words to go on the buttons” or “there are too many words on the screen.”

“We need words” is not the problem that we solve as UX writers. We communicate. We invite action. We inspire loyalty. Our teams need to know that UX writing can be used to solve problems. It’s up to us to frame our work to reflect the problems we’re helping to solve.

I’ve found it helpful to explain UX writing in terms of programming. Software engineers write in one or more software languages. There are specific grammars and techniques to use in each language to get the best results from the hardware, firmware, and the services on which the software will depend. Those languages are compiled into programs to push the right electrons, at the right moments, to the screens and speakers that people will use.

UX writers write in one or more natural languages. There are specific grammars and techniques to use in each language to obtain the best results from the people and their context. Those languages are compiled by each human as they connect with those screens or speakers to transform those sights and sounds into the right synapses, firing at the right moments, to create a useful, entertaining, or necessary part of their lives.

Therefore, both software engineers and UX writers use the grammars and commands specific to their languages to meet the goals of the organization and the people who use the experience. Both groups work in a process of design, writing, cycles of review and testing, and publishing. Both groups need to be flexible to adjust to idiosyncrasies in the languages, the compilers, the architectures, and contexts the experience lives in. If our teams can work with software engineers, our teams can work with UX writers.

Summary: Use UX Content to Meet Your Goals

Organizations that make experiences are learning the effect that UX content can have when it is written strategically. UX writers, people dedicated to creating UX content, can bring knowledge of best practices, UX text patterns, structures for voice, iterative editing, and review.

Perhaps you are a UX writer, you support a UX writer, or you’re considering adding a UX writer to your team. I’m so excited about the future we have in front of us. We have solid work to build upon, and we have so many possibilities ahead as we continue to invent and research best practices. Together, we have the opportunity to help people and organizations meet their goals by creating, iterating, and measuring the UX content.