February 2025
Service Design
In Progress! Check back soon!
View Post
“If you design a digital product without focusing on the words, it’s easy to avoid thinking about the message that it sends to its users. When you take responsibility for the words in an interface, you are the last line of defense against manipulative practices, misinformation, and jargon.”
When designing a product, writing/content often falls on the shoulders of designers; the role of ‘UX Writer’ or ‘Technical Writer’ has become much more common but is still not a guarantee for the typical team. Additionally, one of the aspects of creating a style guide that I’ve always struggled with is the ‘brand tone and voice’ section. When it comes to digital products, cohesion is key and it’s often difficult to maintain a certain tone/voice when working with others collaboratively.
I asked UX Writers for book recommendations to learn more about best practices; a few recommended this book as a great introduction to thinking like a UX writer while still having your primary role be ‘designer.’
Above all else, I’ve learned within the last few years that certain aspects of design are roles, not job titles. Similar to not having ‘Researcher’ as an explicit job title on some teams, research still happens and is performed by designers. Writing follows the same convention.
We live in a digital age - one where users skim pages and search for specific results rather than read through everything. We also live in an increasingly globalized world - one where countless languages need to be accounted for.
The single most important thing we can do is write in plain language. As defined by the Plain Writing Act (2010), plain language is defined as:
“writing that is clear, concise, well-organized, and follows other best practices appropriate to the subject or field and intended audience”
The benefits of writing for clarity:
1. It’s concise: it saves time
2. It helps those who speak English as a second language
3. It improves SEO/Searchability
Designers will already be familiar with the importance of testing with users; however, there is a distinct difference that I noticed when thinking of testing through a writing lens: pay close attention to what language users use. Format testing scripts accordingly: leave out jargon or specific terms used internally on a team!
One of my favorite quotes from the book states that:
“Users aren’t alone in bearing the error on themselves—the companies making the experiences often fall into the habit of blaming them too, even when the technology itself or the way it was designed is what’s actually failing. Companies do this because they feel they have a brand image to protect. Unfortunately, passive aggressive messages that make your users feel bad also hurt your brand image, while lowering user adoption and retention—two metrics that are important to the growth and development of a product."
When delivering an error message, strategize using the following 3 mindsets:
1. Avoid - find ways to help users without showing them an error; assist with formatting and data entry wherever possible (Example: mm/dd/yyyy)
2. Explain - tell your users what’s going on and what went wrong (Example: Password doesn’t meet 12 character count minimum)
3. Resolve - provide a solution to the problem that the user is facing (Example: Link to page with next steps)
You won’t be able to account for every type of error at first:
“There are many, many ways to avoid or reduce errors before they happen. It takes a design mindset, a strong understanding of the technology involved, and a deep familiarity with the business constraints to do it effectively. “
In order to maximize inclusivity, designers need to be able to design for accessibility - a very large part of that comes from writing. For any user who uses a screen reader, writing and structure becomes the entire interface.
Some best practices to keep in mind include:
1. Avoid language that assigns value to traits
2. Avoid prescriptive language when talking about people
3. Write chronologically, not spatially (Say “Next,” not “Below”)
4. Describe the action, not the behavior (Say “Select,” not “Press”)
5. Use the singular “they” pronoun
6. Write left to right, top to bottom
7. Don’t use colors and icons alone
In order for content to be accessible, it should always be:
1. Perceivable - content can’t be invisible to all of user’s senses
2. Operable - interface can’t require interaction that a user can’t perform
3. Understandable - content can’t be beyond the user’s understanding
4. Robust - content should remain accessible as technologies evolve
There are multiple types of voice:
Brand Voice - the consistent, goal-driven expression of a brand through words. In other words:
“It’s how a brand would speak and write if it were a person.”
There is also:
Product Voice - defines what an app or digital product produced by this brand sounds like
The authors provide lots of recommendations for developing voice; many of them are not unique to UX Writing but to UX in general: get feedback on your work, read aloud, and documentation is key but keep flexibility in mind.
Voice - personality that your product/brand manifests which sets it apart from others
Tone - the way the voice is expressed in certain contexts (Example: “404 Error” vs. “We couldn’t find the page you’re looking for”)
Using a ‘tone hierarchy’ or ‘tone spectrum’ can aid with content strategy and providing users with the most appropriate tone profile for a specific action.
The most effective method (for me) outlined by the authors is to practice writing in a variety of tone profiles to find the best fit for an action; the user journey typically follows this order:
1. Encouraging - “Welcome! Add a section to your profile to get started!”
2. Informational - “Add a section to your profile to enhance community visibility”
3. Trustworthy - “This step takes a few moments to complete for security purposes.”
4. Sympathetic - “We’re sorry this happened to you; here are steps to help.”
Wow! In addition to cultivating a UX Writing mindset (my original goal), I learned a lot about specifics of UX Writing: tone, voice, inclusivity, accounting for errors, and the actual practice of being a writer/designer in the workplace. Metts and Welfle begin the book by talking about the dynamics associated with writing and the modern workplace; writers are often less valued and left out of the design process until the last second.
One of the most powerful visuals I’ve seen lately was this:
Among other designers, I often forget just how much of an impact content has on an experience - specifically words/language. One of the most valuable lessons I learned from this book is to conduct user interviews with an absence of any technical language; allow them to provide language about processes they complete. In the past, I’ve often missed this opportunity to learn even more throughout the discovery process by framing questions even more carefully.
Another main reason I chose to read this book was to get more formal definitions and context of the usage of ‘tone’ and ‘voice’ in products and more specifically: how they’re documented and how they scale. As with many other aspects of design, I think I was overthinking this a bit; the authors specifically say that flexibility is the most important part of documentation. Writers document styles in a similar way as designers: through style guides. The Associated Press Stylebook and the Chicago Manual of Style are the two cited by the authors - they’re worth checking out!
Overall, this was an informative and enjoyable read! Metts and Welfle end the book with a powerful quote that I definitely needed to hear:
“At the end of the day, regardless of your title, there’s one thing that’s important to remember: Everyone on the team is working together to design the experience.”
10/10!
