Technical Writers as User Experience Designers – A Revolution

In my nearly 15 years of work in user interaction design, I have come to see user experience as tightly coupled with customer experience and corporate brand. Even with that view, I understand the need for ‘guerilla UX’ in today’s environment and look for ways to shape the product with rapid development and testing cycles. We have to get products to market faster and cheaper than before, yet with a higher caliber of information built in.

I’ve found several interesting ways to flex the UX process to suit Agile scrum development in particular. When working in Agile, a superior UX designer will earn a seat at the release vision/release backlog table to bring user views to that forum. As a corollary to that, the single most important responsibility of a UI designer is likely liaison between various roles around the product, such as users, product owners, and stakeholders, all of whom have distinct goals.

Can you think of any others on the project team who have those skills?

When I noticed that about 30% of usability bugs reported in testing were mentioned in feature after feature, I began developing a set of acceptance principles for all stories that touch the UI, which are designed to become part of the project DNA. These principles included getting developers to consult a tech writer on the verbiage for dialog boxes and screens. What came out of this from the writers was an unexpected degree of insight on the entire UI, not merely the wording of messages.

The not-so-great way to guide edit actions:

This forces user to compare four concepts: OK, Cancel, Stop, and Delete to decide on an action

The short and sweet way to guide edit actions:

A technical writer suggested leaving
Yes and No out of the text entirely

I came to see technical writers as quite akin to UX designers. Most are skilled, some are visionary, and experienced with many types of software products. I began to use the writers as my first line of prototype review, and saved my team a good deal of cycles in the process.

The conclusion I arrived at shortly thereafer was that the tech writers should simply write the doc first, including all the screens etc., and have Dev build that. Tech writers do all that when they document after the fact, and this move would save all the scrambling at the end interviewing developers and improve product quality to boot. It would save us from some of those misbegotten features that have ‘coding coolness’ as their reason to be.