Tuesday, April 10, 2007

Using Technical Communication Skills in User Experience

Moving from technical communicator to user experience professional ...

"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 have plenty of 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.)"    (Continued via Boxes and Arrows)    [Usability Resources]

0 Comments:

Post a Comment

<< Home

<< Home
.