Improving the Business Impact of Technical Writing and UX Writing

Improving business impact of technical writing and UX writing outlines how to increase the business value of two writing disciplines that directly affect customer experience.

Before diving into that, the backstory shares how I developed an unusual point of view while practicing service design and experiential social media—and how this led me to technical writing and UX writing.

Then the main event: I offer five ways organizations can substantially improve the business impact of technical writing and UX writing.

The Backstory

After working closely with software engineers and financial consultants, I worked as a service designer, and this combined experience led to unusual results.

Experiential Social Media

Experiential social media works by helping customers/users in digital public to attain the outcomes they want when they need [our] product or service. Experiential gets marketing results without marketing, and it I invented it because I had led marketing for several hightech firms, and I clearly saw that marketing as a practice was a bloody ocean and getting bloodier. So we needed a completely new way to attract prospects. Having worked in B2B firms, I had learned that trusted relationships were the only reliable way to build a sustainable business, so I developed experiential to digitize trust building.

Experiential social media’s core activity is helping people who are either frustrated because they are experiencing exceptions (stuff is not working) or they are doing something they have not done before (new opportunity). Since my teams help people in high impact social sites, our care for people scales among people like them who face similar exceptions or opportunities.

To practice experiential, teams need to empathize with the people they want to help, so I developed Agile Digital Ethnography to research customers/users/prospects. It is a group of practices and tools that enables us to get inside people’s heads without asking (and biasing) them. So our empathy is not merely a nice gesture; it is grounded in serious qualitative and quantitative data. Every big brand client I have served has said the data is unlike any they have seen before.

Why Technical Writing, Why UX Writing

I have used many products, and their help, guides, and documentation are horrid with few exceptions. Design has not yet eaten technical communication (as software “ate the world,” design is injecting user advocacy everywhere). My goal is to bring design ethos and practice into the technical writing domain. UX writing is an emerging field that overlaps technical writing to some degree, but it is usually grounded in design, not writing or engineering. Technical writers usually have writing and engineering backgrounds.

I am very excited about the emergence of UX writing, which began on the West Coast. The UX writing role is usually scoped as a design role, so UX writers orchestrate and write all the verbiage within our application/website. As writers, they are hyper-aware of word choice, and they often use design research processes. They may or may not do long-form writing as do technical writers. UX writers are more front-end as their work is within the product.

How to Improve Business Impact of Technical Writing

Here is some of the low-hanging fruit for improving the business impact of technical writing and UX writing:

Make Research User-Centric

Currently, it is common practice for technical writers to interview subject matter experts to learn the product and its features. Technical writers also interview or survey users, but these research methods are biased and usually produce limited data. Conducting Agile Digital Ethnography changes the game because it is user-centric, deeply qualitative, and quantitative. Since it focuses on user outcomes, not product (service) use, it is also ideal for new product categories.

Increase Credibility of Technical Writing

Technical writers everywhere complain that they are brought into the product development cycle too late. This organizational habit is left over from the old waterfall days when product development took years, and documentation was written very late in the cycle. In the agile world, it often makes more sense to develop documentation in parallel with the product. That said, I have acquired a deep respect for what I call “organizational readiness.” It is counterproductive to try to compel people to change; that is like pushing string. Instead, technical writers need to build trust through interactions that demonstrate their ability to add value. Then they can engage much earlier in the product cycle. In most situations, they can earn their spot at the table by contributing valuable user insights that product teams don’t have. This is a huge opportunity to improve the product and its support aids.

Enhance Document Management

Technical writing and documentation management are currently digitizing in a big way. As software has become progressively more abstracted (object-oriented, service-oriented, virtualized, serverless), so is documentation. Some hot technologies and practices are DITA, single-sourcing, and topic-based authoring. To be successful, however, they must have architectures that are as user-focused as possible, and Agile Digital Ethnography is a fast, inexpensive way to understand user outcomes and journeys. This will make documentation of all sorts more effective in empowering users. When we make them more successful, churn and support costs go down while customer lifetime value goes up.

Use More Empathic and Relevant Language

More on the writing side, Agile Digital Ethnography enables us to learn how users think and talk about things. It enables us to have true empathy based on real data. So our writers can write for real people and use users’ expressions. Experiential social media has taught me that word choice, word and phrase patterns, and attitude are key to building trust and relationship. Virtually all the documentation I have encountered reads like a “manual.”

Shift to a User Perspective

I always seem to end up doing things I do not know how to do, but that does not stop me. Since I usually have little time, I am self-taught. Of course I check product maker’s help aids and virtually always find them of marginal value. My hypothesis is that their rationale is documenting features, not showing users how to do things. In the old days, I would buy a Peachpit Press book like David Blatner’s The QuarkXpress Book. These days, I often find what I need online by researching other users’ experiences and interacting with them.

The point is, all help aids need to change perspective. Users do not care about our product or its features. They want to use it to do something important. Let us design our aids from users’ perspective first and wrap all the needed documentation around it.

By building interfaces and user documentation around users’ voices, we can make users’ experiences more intimate and much more useful. Most applications put the brand’s agenda in the front seat and conduct user research from that perspective, so apps leave money on the table. Technical documentation is too focused on explaining features and gives short shrift to user outcomes. UX writing and technical writing can do much, much better by developing deep understanding of user outcomes and journeys. Conducting Agile Digital Ethnography on the front end develops vivid pictures of user goals and journeys.