Why Usability is Praised and Tech Comm is Ignored

While I was in Missouri at a technical writing conference for teachers and students last weekend, I had an interesting conversation with a lady who happened to drop by from Canada. She had transitioned from tech comm to usability, and she explained an interesting parallel. I had just presented my “Anyone Can Write: Changing Roles for Technical Communicators” presentation to students, and she commented that many have the same assumption about usability: anyone can do usability. However, whereas tech comm is generally under-appreciated or ignored, usability is on a higher level of appreciation. Why the difference?

Here’s what my friend explained: project members see the usability deliverables, but they don’t see the tech comm deliverables. When the usability experts create wireframes or prototypes, the whole team meticulously reviews the designs. But when a technical communicator creates a 200 page user manual, a smooth-looking online help, some video tutorials and other deliverables, almost no one sees them except the person assigned to review them. As a result, people see and appreciate the usability specialist / interaction designer’s work, but they continue to undervalue the technical communicator’s work.

Madcap FlareAdobe Robohelp

By Tom Johnson

I'm a technical writer working for the 41st Parameter in San Jose, California. I'm interested in topics related to technical writing, such as visual communication, API documentation, information architecture, web publishing, JavaScript, front-end design, content strategy, Jekyll, and more. Feel free to contact me with any questions.

  • http://www.twitter.com/ninety7 Robert Armstrong

    And I would call the usability professional a technical communicator. Wireframes are a form of technical communication as they break down a design into ‘technical’ directions that allow a development team to create what the designer had in mind.

    Same with some graphic designers, information architects and UI designers.

    Technical communication isn’t just user assistance. And I know YOU know that.

    • http://idratherbewriting.com Tom Johnson

      Thanks Robert. Yeah, I know all of this can wrap up under technical communication. But it’s not a concept that a lot of companies embrace. And usually the tech writer’s role in these other areas is not as extensive as it could be. At my work, we have full-fledged interaction designers who play the usability role as well as the design role. These guys are coding wizards in everything from CSS to Javascript to jQuery. There is some overlap with the tech comm role, of course. But they aren’t interchangeable.

      Hey, on a total side note, do you remember that video plugin you showed me that made videos pop out in a modal, dimming the background? Do you remember what that plugin was called?

  • http://twitter.com/writer0357 Ben

    Funny you mention this. Recently, a Scrum project that I was lucky to be part of required the sprint/iteration demos to show the documentation/online help as part of the demo to ensure content was complete, along with the committed features for that sprint. Not sure if that made the documentation any more appreciated, though. It did it make it more visible to everyone besides the content reviewers.

    • http://idratherbewriting.com Tom Johnson

      That’s a step forward, certainly. I’ve had a few documentation demos in front of teams as well, but they tend to be 5 minutes long and aren’t really presented in the same light as a design prototype that everyone discusses and picks apart.

  • http://user-assistance.blogspot.com/ Michael Hughes

    I think Usability plays more directly to product acceptance and customer satisfaction, therefore, it has a bit more sizzle. There is a sense that “all the customers use the product; only some might read the doc.” I’ve done both, and ironically I do believe that usability has a higher value proposition, but documentation is the safer job. Everybody thinks they can do the usability piece; nobody wants to do the writing piece. Also, user doc is seen as a check-off, i.e., can’t ship without it. In dire times, the usability folks get laid off before the writers.

    Ain’t saying what ought to be, just trying to understand what I think happens in the real world.

    • comma hater

      This is so true. Usability is that enjoyable feeling you get every morning when driving your new car. Documentation is knowing that if something breaks, it can quickly and easily be repaired.

      If I ever create a description of what a tech writer does, I’d be sure to include that the occupation includes one of the lowest amounts of public recognition for work required.

      What sets this apart from other low-recognition jobs is that I think there’s some expectation that since we create a very user-centric product, there should be more recognition.

      • http://idratherbewriting.com Tom Johnson

        Comma hater, I like the analogy with driving! You’ve also got me thinking about recognition here. You’re right that there seems to be an expectation about recognition that, when unfulfilled, produces a sense of let down among writers. Why do we expect some recognition for our labors when other roles don’t expect this same degree of recognition?

        Just out of curiosity, what is it with commas that you hate?

    • http://idratherbewriting.com Tom Johnson

      Isn’t it somewhat a paradox that a role with a higher value proposition is let go before the role with the lower value proposition? I agree with what you’re saying here. I just thought it was strange to have a high value proposition tied to a role but low job security with that role at the same time.

  • http://www.squidoo.com/hmm-what-does-my-name-mean waht does my name mean?

    sup wat is ur myspace name

  • Derek Warren

    Some years ago I heard a tech comm conference key-note presenter say, “And interaction designers are at the bottom of the totem pole, just below tech writers.” And then this from a 2003 blog on tech support: “That’s why engineers tend to hate tech support folks — because it’s tech support’s job to make sure everyone knows who isn’t wearing any clothes, and that creates conflict. So support ends up, politically, somewhere just above tech writers . . . Which explains why manuals generally suck, too”.

    I do think that this question merits an entire thesis study. There is plenty of evidence to show that both IxDs and tech writers are among the first to go when a RIF comes around. (If it’s not in the code, it’s dispensible?)

    But I think a related and significant question is, Why do most development efforts end up compartmentalizing its constituent teams by creating imaginary hierarchies and boundaries that limit/restrict the total, cross-discipline engagement required to produce the very best product imaginable? Aren’t we supposed to be creating “intellectual property,” and so doesn’t it stand to reason that every ounce of intelligence should be harvested to its fullest? This whole business of who matters most is hogwash, and just sad, given “what might have been”.

  • Derek Warren

    Wow, who wrote that last, dizzying comment. Oh, that was me.

    All I meant to say is that I think the problem regarding who gets the credit is deeper and uglier than between IxD and tech writing. Jim McCarthy wrote a great book on the subject of software development and suggests that the most successful teams are those that value equally all constituents…that is, creating great software requires the equal inclusion of all disciplines and seeks to keep turf wars far away as they are the plague that vexes excellence. (McCarthy, Dynamics of Software Development)

    K, I’m done now.

    • http://idratherbewriting.com Tom Johnson

      Derek, sorry for the slow reply. Thanks for the quote from the McCarthy book. I’d be interested in reading more or hearing more about it. Maybe I’ll swing by your cube sometime and chat more with you about this topic.

      • Derek Warren

        Tom, I’d love to talk about it, and you’re certainly welcome to borrow my book, and oldie but a goody.