Everybody has to write at some point, in some way shape or form. In the product development world writing is particularly important because it can easily sneak up on us as a given skill, but we don’t always pay close attention to our writing and how that affects those who we communicate with, users and stakeholders alike. In this case, I’m going to focus on how writing impacts user experience. When I say writing I refer to any form of text that will be read by users and should help them understand, use and navigate a given product. Even though I write as a UX designer, these ideas are for anyone involved in product development (developers, project managers, etc.).

Many professionals in the field don’t work with a dedicated team of writers, and therefore are asked to provide the copy that should accompany the user interface. This, however, is a specific kind of skill that is hardly ever taught (UX Writing), or even conceptualized in its uniqueness. Designers are not the only ones who run into these situations. Front-end developers will eventually find themselves writing some piece of UI copy, especially when designs for previous workflows are reused and they’re asked by project managers to just “come up with new text” for a similar workflow. Back-end developers might not be exposed as closely to the final UI of a product, but the terminology they use to name features or sections of a product will very likely make its way to the UI that users will interact with. Finally, project managers will have to write too, and not exclusively for internal communication artifacts. Many times, project managers are the ones providing language for product releases or communicating with marketing teams about the products they’re in charge of.

All this to say again that everyone in the product development lifecycle will inevitably write a piece of text that users will interact with. The goal of this article is to provide an overview of the types of writing that are involved in product development and how to approach it from a very high level.

Information Experience

What we are calling UX writing falls within the category of Information Experience (IX). IX is not a well defined field, but we could loosely understand it as the experience users will have interacting with textual information that explains and guides the use of a digital product. You can already see the big overlap with a definition of UX design; however, the main focus of IX is textual information, as opposed to other elements of UX such as interaction design, iconography, color semantics, etc. Within IX, there are other subcategories like Information Architecture (IA), Technical Writing, and obviously UX Writing. Let’s spend some time exploring these categories.

Information Architecture (IA) is the structuring and labeling of content to help users understand where they are and how to arrive to where they want to go; in other words, find-ability. What signage or maps are to a physical space, information architecture is to digital products. It is typically developed in the early stages of product development, and it heavily influences how the product is engineered on the back-end. Despite established industry standards for IA, the best architecture for a given product will be based on the user’s goals, mindset and workflows. Let me give an example from my personal life on how IA can simplify or hinder user experience.

When my sister came to visit me in Michigan from Peru, she and her husband went to the supermarket to get orange juice. Back in Peru, we don’t consume as much orange juice as in the United States, and it’s not sold in the same way. They thought of it as orange juice (emphasis on the orange part), so they assumed they’d find it in the fruit section, but they didn’t. After their initial confusion, they thought they’d find the orange juice (emphasis on the juice part) in the beverage section, but they didn’t find it either—just ‘pops’ and other drinks. Finally, after wandering the store for a while, they found the orange juice in the refrigerators of the breakfast section (next to the milk, butter and other dairy products). When they came home, they told me their experience and said it was very strange for them because it was not intuitive at all. In Peru, we don’t drink orange juice for breakfast as in the US, so it didn’t make sense to them to group it with refrigerated dairy products. Clearly, they are not the main users of this Midwestern supermarket information architecture. But for the vast majority of regular shoppers it makes total sense.

Proper or improper information architecture of a product can make or break it, and it has to be specifically tailored for the main users’ mindset, workflow and language. It also needs to have other support systems that would aid those who don’t fit in the main users’ pattern, like my sister in the supermarket.

Secondly, we have Technical Writing. Technical Writing aims at guiding users through technical workflows by explaining to them how a particular product or feature works and how to solve common problems. Support documentation, instruction manuals, help center content, video tutorials, and Frequently Asked Questions sections are very good examples of Technical Writing. This content needs to be clear, concise and specific enough to be useful. However, the same product might have many more use cases than the ones a particular user might encounter, and the instructions have to be tailored to a wide range of users and use cases. Technical writing typically appears at the very end of the product development process.

Let me give you another example. My mom recently turned sixty and she also just learned how to drive. She had never been a car owner, so naturally there was no need for her to take care of a vehicle either. What’s more, she has only lived in the United States for a few years and she has a basic knowledge of English. How would you explain to my mom how she has to change a car wheel? Consider how basic the terminology has to be for the car parts and instruments. Consider her physical ability at 60. Consider how you would break down the steps. Would you add images? Would a video be better? This is the kind of questions technical writers have to answer before writing how to use a product. Maybe users will be highly technical and understand complex terminology, but maybe they won’t be.

Technical Writing typically engages the product development cycle at the very last stages. The product is working, and now we have to explain how to use it. This documentation however is never static, since products change very often and very quickly. Terminology, steps, use cases and labels used throughout the product need to be updated and clarified often.

Finally, let’s turn to UX Writing properly speaking, although what we mentioned before is deeply related. UX Writing means writing for product interfaces in order to guide users navigate and use said product so they can accomplish their tasks. UX Writing pairs with UX Design in the creation of interfaces for product user experience, but is not concerned with the specific graphical elements of the interface, just the text. When I say user interface, I mean the specific graphic elements users interact with such as menus, toast messages, tooltips, buttons, empty state screens, loading state screens, modals, form fields, etc., most of which require text. UX Writing usually appears throughout the whole product development process, but typically after the Information Architecture has been established.

Like in the previous two cases, a real life example will help. Picture your kitchen and the many drawers and cabinets you might have. You might have a way of grouping elements in the kitchen: by size, proximity to the stove, usage, even by color. Now, imagine someone else will come to use it without you being there (maybe you’re renting your place in AirBnb). How would you label your kitchen drawers and cabinets? The elements are already in place, you’re just labeling. If the Tupperware, bowls and pots are together, would you call it “containers”? If your grilling tools are next to the baking tools, what would you label them? That’s more or less what a UX writer has to deal with while aiming for clarity and simplicity.

Oftentimes UX Writing is a balancing act. On the one hand, the most commonly used items should be easily findable. On the other hand nothing should be hidden, otherwise it won’t be used even in the rare occasions that someone needs it.

These are three important areas of Information Experience that all those involved in product development should—and probably already are—somehow familiar with. They share very similar principles, but they should be approached slightly differently. In the product development world, there are cases when these three fields overlap and strict definitions are less useful. For example, for an app onboarding or a new product release (Technical overlaps with UX Writing), or a new feature name (Information Architecture overlaps with UX Writing, or even marketing).

Writing seeps through the experience of a product from beginning to end, and all those involved in the process need to understand the implications of tailored, concise and clear writing.