Fix the product before writing the manual

A couple of months ago, I was at a meeting with a prospective client. The developer (or project leader) was demonstrating his company’s web-based product to give me an idea of the work involved.

While watching the demo, I was easily able to pick out inconsistencies in the user interface, even though I wasn’t there to evaluate the user interface. Problems with hyperlinks (colours and fonts), problems with button use, problems with messages, problems with the flow of the application–they stood out in a demo, one where I was an observer. (Note: This had nothing to do with my eye for usability; the inconsistencies would’ve been picked out by anyone.)

When I pointed out a couple of these issues, the person said that they were planning to do a revamp of the user interface or something of the sort. The impression I got, however, was that they were talking about surface improvements in the UI more than anything else. Also, these were the sort of errors that could be fixed relatively easily and don’t require large-scale revamps in my opinion.

There were other problems in the application, ones that would take longer to fix, and that would need some kind of evaluation to find. The company, however, was looking at someone to create a user manual rather than someone to fix the inherent problems in the application. Now I’m all for user documentation but given how reluctant users are to read the fine manual, it makes more sense to invest some time into the design and usability of the application.

Think about how many times you’ve stumbled because of the way a product was designed. Now think about how many times you ran to the manual to figure out your problem. It’s more likely that you tried tinkering around with the product or asked someone before you read the manual.

Which is why it makes sense to invest in some sort of usability evaluation, internal or external, to iron out the flaws in the product. No amount of documentation will solve inherent flaws in a product and sometimes they’ll come across as band-aid fixes.

Sometimes you just need surgery to fix the problem.


2 thoughts on “Fix the product before writing the manual

  1. Their theory – When you are taken in for writing the user manual, you should be doing that – Leave the technical stuff to us.

    Sometimes, it’s good to take feedback from people who are NOT developers or part of the project team, especially those who give genuine feedback, and NOT ego boosters. Unfortunately, most of us need ego boosters, and not genuine feedback.

  2. Yeah but I was actually there for a meeting and I didn’t advise the company to hire a usability consultant. This was a couple of months ago and I thought about it and so I wrote about it on my blog. :-)

    And my point is that someone needs to look at the usability aspect too, whether that’s a developer with interest in usability or a technical writer, a tester, a marketing person… you get the point.

Your thoughts?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s