No One Is Immune to Usability Problems

No matter how much an organization wants to build good usability into its products and services, sometimes things get overlooked. Often it’s the little details that people don’t think of that cause the biggest problems and cost the most to fix.

That’s why having a trained technical communicator on staff is a great idea. A technical communicator is vigilant about ensuring specifications will result in a usable (meaning something that helps users achieve their goals) product. They also user test prototypes and products in the development and construction phases to make sure usability is adequate.

Recently, an organization that shall remain nameless (but I’m sure you can guess) redesigned and rebuilt its computer consoles. For a user population with an average age of late 40s, they got pretty much everything right except perhaps the most important thing: the ON button for the computers.

Oh, there is one. It’s just so small and hard to see that they needed to create a label pointing to it. And still you have to hit it with a pen or a nail file to get it to turn on. Bad. Very bad. Obviously a technical communicator was not involved anywhere in that process.

In this picture, the buttons are very tiny, as you can see. From an adult’s viewpoint, standing, with this “control panel” covering the computer that sits in the bottom of the cabinet, it is very difficult to see, as well. Therefore, it is easy for someone to press the wrong button, too. Let’s hope there are no negative consequences!

Button too small

That organization is left with two choices: pay a lot of money to re-do the work, or put up with the high level of user frustration that results. Neither choice is desirable. With a technical communicator’s eye on that re-design, this would have been avoided, because the techwriter would have questioned the size of the button given the intended user base. Indeed, every techwriter with whom I’ve shared this story has asked the same question: “Why did they do that?!”.

That’s how a technical communicator adds value to your organization — they prevent you from making costly mistakes that increase support costs. Just ask the help desk techs who have had to go turn on these computers.


FSOSS 2009 & Documentation

Concluding Open Source week in Toronto, Seneca held its annual Free Software and Open Source Symposium (FSOSS) yesterday. I was privileged to have the opportunity to speak about documentation for open source projects.

What is truly exciting about open source development is the collaborative and community aspect of it. I love the synergy of keen minds working on a collective project. Documentation too benefits from having multiple people contribute to and review it. While there is the danger of it sounding a bit like “authorship by committee” I think that problem is easily avoided by having an editor who is responsible for smoothing out the voice.

As we drift more toward topic-based writing that addresses user tasks rather than features, we can accommodate multiple writers because the style guidelines for topic writing are very straightforward. Publishing in an open source environment often involves Wikis, which are an excellent collaboration tool. Marry the idea of topics with a wiki that allows anyone on the team to contribute to the project and you have some excellent documentation that can be developed quickly.

I still encourage documentation plans, and reviews/approvals as part of the process, but generating content is much simpler.

I also still emphasize authorship, meaning document ownership. I don’t mean that someone gets to “own” the documentation in a proprietary way. Open Source is all about moving away from that idea of singular intellectual property toward a collaborative work package that represents the best a group of people can produce. Document ownership is simply taking responsibility for your contribution. Even though other people will look at it and edit it, each author does the best they can to make the documentation excellent.

Another point I brought up in my presentation was that documentation really includes all of the information, communication and knowledge around any particular product. Documentation is a way to add intelligence to the product during development to create a superb user experience. This can be as simple as putting informative labels of data fields that are to be filled in. The example I gave was of a web form that provided for a 10-digit telephone number, without hypens. The user doesn’t know that, however, until they start filling in a phone number 800-555-12 and run out of space. It takes very little effort to indicate how the user should input things like phone numbers, dates, postal codes, and so on.

Of course I recommended that technical communicators be involved in producing the documentation for Open Source projects. I know where you can get some if you want them.

The recorded version of my presentation will be available on the FSOSS web site shortly.


Gadget Junkie Heaven

  • If you were the kid who took all her toys apart to see how they worked…
  • If you love to browse the tools, products, and gadgets in every Big Box store you see…
  • If your version of the ideal present is something that whirrs, clicks, or runs on electricity…
  • If you’re an inveterate tinkerer…

…You might be a Technical Communicator!

Many of us get into this profession because it gives us access to technology in many forms. We have the mandate, if not the divine right, to fiddle with new products or investigate technology we’ve never seen before.

FACTOID: HALF of the top 10 blogs are about gadgets and technology.

To be a good technical communicator, you must have an unending curiosity about how things work, but more than that, you care about how they work for people.

Knowing that technology is only as good as it is usable, meaning that it allows someone to accomplish their objectives with it, we explore and assess new gadgets to make sure they do what we need them to do. And then we write about it. We communicate what we’ve learned about the technology so that others can use it better.

And sometimes, we read instructions just for fun.


Dependencies: The Bane of Efficiency

Students in the Technical Communication program learn how to manage their documentation projects. I’m fond of drawing the parallel between the Software (or Product) Development Life Cycle and the Document Development Life Cycle. They both have the same phases.

The keys to project management of course are to control scope, supervise resources, and manage dependencies. It is this last item, dependencies, that often gives project managers their biggest headaches.

A dependency occurs when one part of the project cannot go ahead without another part providing input or a trigger for it. For example, technical communicators cannot complete documentation on a product unless they have a stable and complete version of the product to work with. Their work is dependent upon something produced by someone else. No matter how efficient they might be, they are brought to a halt quickly when some dependency is not ready.

Because so much of what we do as technical communicators depends upon actions taken by others, we develop skills to ensure others do what we need them to. You might think of us as professional gadflies. We coax, prod, chivvy, encourage, and even annoy those upon whom we are dependent. We relentlessly follow-up; we continually pursue loose ends. We check and double-check. We ask, “Is this ready yet? When will it be ready?” — questions others often don’t want to hear.

Our tactics are not enjoyable but they are vitally necessary. And too frequently, it is the technical communicator who ends up driving the project forward simply by virtue of needing certain things done by specific dates.

If your projects are sluggish, and efficiency is hampered by too many dependencies, get a technical communicator on your team and watch things start to happen.