This article was
This article first appeared in the Communication Times, newsletter of the STC Toronto Chapter, Spring/Summer 2007
About the Author
Theresa Putkey is an independent consultant in information architecture and technical communication. She runs Key Pointe, a consulting company, out of Vancouver, BC.
Using Technical Communication Skills in User Experience
It started with the small stuff. I sweated it all: field labels, button positions, lining up the label and the field, ensuring the icon was understandable. After 2 1/2 years of correcting designs, the heavens opened: the project was delayed, and no one could do the requirements and UI design. How were they going to get it all done? Special T (that's me) stepped in to save the day, of course. "If you don't have time, then I'd like to do it."
I don't care; I'll take scraps (err-experience) where I can get it. I come from a technical communication background and seen many successes and failures with user experience in the software world.
It started as a backwards, fix-the-design approach but eventually became a more forward process, designing from a blank slate. Technical communication skills can be a great starting point to an interesting and more lucrative user experience career, if the communicator knows how to apply those skills.
User experience professionals can also learn some lessons from and find potential recruits in technical communicators as they have skills that can be applied directly to the design process.
Technical Communication Skills
Technical communicators may be the only user representative in an R&D group. As a more traditional role, managers have some embedded idea of professional responsibilities. In these situations, the communicator must speak up often: when an error message sucks, when a field label is inappropriate (or misspelled), or when the flow of a wizard doesn't work.
Communicators must understand both the forest and the trees, and they must constantly scan for inconsistencies. As a best practice, communicators create documentation plans that include help topics, embedded assistance, and context sensitive help. When the plan doesn't flow, the communicator speaks up to illuminate the shortcomings of a design. (A solid plan, like a solid information architecture, highlights when a feature is problematic or just doesn't fit.)
As a communicator moves from novice to master, emphasis moves from editing messages and button labels to the placement of those elements. Grouping fields on a form or the location of forms in a program transforms into scenarios and use cases behind those forms. This is how I started my move from technical communicator to user experience.
Along with the big picture/detail skills, communicators must be able to structure information and see the not-so-obvious structure of an interface. Structuring information starts with the documentation plan, but goes beyond that exercise. As features are fleshed out, more information becomes available and must fit into the plan. I liken it to expanding an information architecture: your architecture can be too ridged, too flexible, or appropriate and accommodating.
Eventually the ambitious communicator can start to develop the initial design instead of fixing it, or find opportunity in a design vacuum, as I did. When I volunteered, the project leads thought this was a perfect fit. I always complained about the design, so why not let me do the initial design? (I also benefited from a trusting team that worked well together.)
Giving something in return: how communicators can help UX pros
Communicators are the UX professionals' natural ally. Since communicators know that fantastic documentation can't make up for a poor design and system architecture, they champion the cause of better design and information architecture. Communicators are in the trenches, talking with QA and developers about problems and how to solve them.
On multiple occasions, coworkers asked me about changing a design that was created by the UI designer. "It's just a small change, can't you just make it? It's not a big deal." Having seen the results of a lot of small changes, my responses included:
Communicators reinforce the idea of a formal design process and back up the designer in advocating a positive user experience. In certain company cultures, designers can be seen as antagonistic to developers and QA. Communicators can use relationships with these roles to smooth the way for the UX professional.
How to make that move
Based on personal experience and speaking with other communicators and UX professionals, here are my recommendations for making the move either as an employee or independent:
Remember that it might take longer than expected: I love when things happen overnight. I'm an instant gratification kind of person, so naturally my move is taking longer than anticipated. I keep advising myself to stick with it. As an external motivator, my spouse would freak if I went for a career change! Being independent was enough of an adjustment.
I'm following my professional passions from communicator to user experience professional. I'm a mover and am trying to smooth the way for those who will come after me. Not all communicators want to be in the UX field, but for those who do it is a natural move.
For those already on the design side of the house, hopefully technical communication colleagues can become allies, and you can look to them for support, insight, and maybe even as your next new hire!