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.
Tom Mulhern
Cool piece, and an important observation. Actually, UX and tech writing should be part of an ongoing “suite” that includes customer support people and application engineers who are versed in the new product’s predecessors, as well as those who are involved in training end users. There also needs to be a readiness group that looks at the product and its ancillaries that will be released. Someone has to coordinate this, naturally, but everything has to focus on user experience, or the product won’t be as profitable or as well regarded by users. Trainers, customer service reps, etc., all get valuable feedback from end users that can help enhance the user experience of new products. The challenge, of course, is being able to capture, analyze, and distill that valuable information.
As for the tech writer being involved earlier to help in the screens, it goes even wider/deeper: Many UI screens are translated into multiple languages. If the screen real estate is tight, this can be a problem especially in non-Euro language translations. Arabic and Asian languages present the largest hurdles, followed by German and Nordic languages. Non-English marks (accents, umlauts, etc.) add to the problem. Awareness of these bits of friction make the process smoother, as well as working with trusted translators who understand (or can be made to understand) the subject matter, rather than merely translating words in isolation.
JP
I see where you are coming from with this and agree tech writers do have skills that would be valuable during project development. I do wonder though whether they could actually write the doc initially, including screens, and simply pass that on to Dev to build.
Are tech writers handy enough to interview stakeholders, interpret requirements, and articulate them in a project spec? Or are tech writers more ‘after the fact’, able to pick up on a product only after it has been fleshed out into some level of proto-type that they can touch and feel? I really don’t know.
I do think having them available during the proto-type phase of a project would be valuable. Tech writer feedback on process flow, navigation, layout, etc from their user training point of view could decrease the amount of time and iterations spent refining the UI over the project lifespan. I’d rather have a tech pro tell me what was wrong with the UI rather than the stakeholder or actual users.
admin
Thanks for the points. I do think it is time to emphasize placing user-centric skills at the definition end of development cycles. I have seen many flows and interactions questioned by tech writers too late to have an impact. In those cases, the doc winds up explaining craziness. Nobody is happy.
Sarah Maddox
Great post! I’ve been in the position a few times, of having to write the doc that explains the craziness. On occasion it’s been too late in the cycle to fix the problem. Once we even had to pull the feature from the release because the user workflow just didn’t make sense. In my current role, most projects do consult the tech writers early in the development phase, for feedback on the UI text and usability. We also have a Design team who are involved even earlier, in the design and prototyping phase.
Most tech writers do have the skill, experience and interest needed to contribute to the early design and even to write the specs with screen mockups. Many of us have doubled as BAs too. What we lack, though, is the time for such detailed analysis. The core role of documenting the product and helping people to use what’s there tends to be all- consuming.
So I’d agree that tech writers should work with the designers and developers, creatively giving feedback from early in the development stage, and should concentrate on creative documentation too.
Rhonda
Most of my software tech writing experience has been in very small companies where I’ve been the only tech writer and where UX people and QA testers have been non-existent. As a result, I’ve often been the first person to see the product as a whole, usually at the alpha stage.
Documenting a software product means clicking every button, working through every screen, undertaking every task that a user might do, etc. And in that process, tech writers get to see things that perhaps the developers don’t see because they are only focused on functionality and whether it works. Things like error messages, UI text, UI workflow and groupings, mis-aligned UI objects, and the like. Unfortunately, often when such bugs are reported, we only have the option of categorising them as ‘cosmetic’ with the result that they go to the bottom of the pile for fixing ‘in a later release’.
Some companies bring in the tech writer much earlier in the design process (e.g. at the paper prototyping and design docs stages), and issues with workflow and logical groupings of objects on the UI can often be identified and sorted out before a line of UI code is written. Some companies I’ve worked with have also handed over the resource files for the error messages to the tech writer too. And other enlightened companies have set aside a day of a developer’s time to just fix the UI text and object alignment issues identified by the tech writer.
But some companies are still in the dark ages. I received this email from a tester a few years ago: “In my opinion trapping exceptions with … plain english dialogs is folly; a waste of developers’ time, a waste of development budget when there are more important things to do.” Details here: http://cybertext.wordpress.com/2007/01/06/usability-is-a-folly/
Not having worked with large software companies, I can’t comment on the value of technical writers’ input to UI issues under those circumstances, but for small companies, it is vital — there’s often no-one else to act as an advocate for the user.