UX Writing for Beginners — A chapter from the new free book
If you’ve not downloaded the number 1 free book in website design, or the number 1 free book in technical writing…why not? UX Writing for Beginners is free right now on Amazon worldwide.
It also comes with a bunch of free templates I built for UX writers. You can download those free at uxhewrote.com/templates.
In the book I talk about how to be a better UX writer, I provide free templates for project and time management, there are a ton of resources for inspiration, as well as templates and guides for UX content research and testing.
If you’re still curious about what’s inside, here’s a chapter from Part 1 of the book. In Part 1 I talk about knowledge gaps and what UX writers need to learn to become better. None of the tips mention getting better at writing!
Enjoy.
Tip 1: Learn objective distancing
“Yes, but the user doesn’t know that.”
You’d be surprised how many times I’ve said that in design review meetings.
It can be challenging for anyone on the team to separate themselves from the project they’re working on. But this lack of distance prevents you from seeing the design objectively. You will end up both missing problems and opportunities for improvement.
In his now classic book Don’t Make Me Think, Steve Krug introduced UX professionals to the concept of “knowing too much”. But it’s not a concept unique to product design.
Miriam Heren cites philosopher Jean-Paul Sartre when discussing gaining objective distance from her work.
Sartre said it takes twenty years for a writer to objectively read their own work as their audience does.
You don’t have twenty years, so you need to learn objective distancing now. The good news is UX writers are in a unique position where they naturally have a certain amount of distance from projects. Take advantage of that position.
This is the one skill that, if you learn it well, will instantly make you an expert UX writer.
Krug explains that when you’ve worked on a project for too long, the only way to gain objective insight is through user testing. While this is sound advice, and you should do research and testing, UX writers are in a unique position to unlock the power of objective distancing.
As the UX writer, you’re the one person who has to explain the product features to your users. That’s the unique position I’m talking about.
Designers and product managers overlook a lot of details and flaws in product logic. This is because they never actually consider explaining a product to a new user.
Are things explained clearly?
When assessing a product or user flow with objective distance, think about:
Have you told the user how things work?
Does the user know what to do next?
Do they know what they can do on this screen?
Design teams too often forget that the user doesn’t know what they’re supposed to do next, or where they should start.
Product teams design interfaces which allow the user to do everything they need. But then they forget to guide the user by telling them where to start.
You’ll often see this kind of poor design “fixed” with notification banners at the top of the user interface. But good design doesn’t rely on notifications to help the user navigate the interface.
Sometimes, important information is hidden in a tooltip, or it’s presented too late in the user flow. I once saw a checkbox which provided more information about a feature only after checking it. Useless! How can you be sure about selecting a checkbox if it doesn’t explain what it does until afterwards?
Knowing what to write is only half the problem, you need to know when and how to present information to the user.
Are you over-explaining?
While you need to explain everything clearly, it’s important to find a balance between clarity and clutter. It can be tempting to think you need to explain everything to the user, but over-explaining overcomplicated.
Error messages are a great example of oversharing in UX writing. Some people say never write the generic error message: “Something went wrong, please try again.” Yet, in certain situations, this error message is fit for purpose and possibly the best choice.
Not all errors need explaining in detail. Some errors are far too complex to explain to the average user.
The user doesn’t need to know the intricacies of your backend code. They just need to know it’s not serious and what they should do next. If explaining the reason for an error adds no value, why bother? Don’t overload your users with unnecessary information.
Is the design affected by the company or product structure?
As we’ll see in the next tip, you need to understand your product inside and out. But that doesn’t mean your users need to.
Users don’t care that they can’t use a specific feature because of a legacy issue with the code. They don’t understand that a feature has to be used in a certain way because of the way your app was originally set up. All they see is something that doesn’t make sense. And there’s nothing you can say about the product, the company, or the code that will make them see it as anything but bad product design.
You’re the one who has to explain how and why things work the way they do. Sometimes, product teams can overlook the fact that the product logic may seem ridiculous or confusing to users. As the UX writer, you bring the objective distance to the conversation by presenting the problem from a content point of view, and importantly, the user’s point of view.
Does the product architecture make sense?
Another issue at many organizations is problematic information architecture. This is sometimes caused by the company’s departmental structure. It sounds absurd for a company’s internal structure to determine the structure of their product. But it happens.
I saw departmental structure negatively affect information architecture at an online travel agency.
A section of the product called “Tours and Attractions” already had an entrance on the home page navigation bar. Then a separate department called “Group Tours” emerged within the organization and insisted on having its own, separate entrance on the home page.
How are users supposed to know the difference between “Group Tours” and “Tours and Attractions”?
A similar thing happens when a product is designed around features, not user goals.
Users come to your product to achieve something — to buy something, like a post, find information — not to use features. Features are simply how they accomplish those goals.
Users don’t think in terms of features, they think in terms of tasks and goals.
The best way to check if your product has been incorrectly designed around features, is to map out a real user journey through your product.
Start with a typical user goal, then map out how a user would navigate through your product to accomplish said goal. If they constantly have to navigate away to different pages just to turn settings on and off, or they need to backtrack or jump between different parts of your product, you might have a problem.
Product teams sometimes get caught up in what makes sense to their team. That, or what’s possible because of existing product design. As a UX writer somewhat removed from the original project conception, you’re in a unique position to bring clarity.
Points to remember
Looking at a product through your user’s eyes is difficult. But, it will come with time and practice. It requires learning everything about your product and its features, then pretending you know nothing to see if it still makes sense.
Here are a few tips and tricks you can try to help you gain objective distance:
1. Remember that users know nothing
Users don’t necessarily understand your product or know your company’s reason for designing it a certain way. They only care about the goal they came to achieve, and how easy it is to accomplish. Don’t assume they know about your product, the code, or company structure. Assume that they don’t.
2. Take breaks from your work
This will allow you to see it with “fresh eyes” later. This is particularly true when you’re deeply involved in just one project. Get away from your desk, spend time on different tasks if possible and see if your project still makes sense when you return.
3. Get feedback from colleagues
Part three of this book provides research and testing templates I use to get quick, often free, feedback. At the very least, however, you can ask a colleague what they think, or how they understand a project you’re working on. Ask a coworker in a department unrelated to product design. I often show a design file to the Finance team to see if they get it. This is an easy way to gain new perspective and feedback.
4. Put the user first
Exceptional designers and writers care about making quality products, not just a product that benefits the company. Genuinely care about your users. In doing so, you’ll spot design problems easily and your creations will naturally benefit the user and the company.
If you like what you read and want more, get the free book on Amazon now, and download the templates free at uxhewrote.com/templates.
