Product Design

As a technical writer, I often find myself bemused by the design decisions made by developers and product designers. Any time I find myself bemused by a product I tend to look towards the supporting information.

However, the technical writer also has guard against such things, as evidenced by the instruction manual I received with my new watch. The watch itself has four buttons, and like most digital watches each button will do different things in different modes.

The buttons are not labelled on the watch itself and so the instruction manual is the only place to figure out what button does what. OK, I’ll admit it, I did play with it for a while before turning to the manual at which point I became a little confused.

There are four buttons, and in the instruction manual there is a simple diagram showing that they are labelled A, B, C and D. So far so good.

However, and bear in mind this is a watch so when you look at it the cognitive suggestion is “clockwise”, the buttons are labelled in an anti-clockwise order. Now if each button only did one thing, this wouldn’t be that big a deal. Yet because of the non-intuitive way they had labelled the buttons, I continued to find myself confused as to which button to push, returning to the manual at every point to check which button was next.

This is not a flaw in the hardware (the watch) but in the instruction manual.

Why do I mention this? Two reasons:

  1. We are the interface to the interface. We can break the “product” as easily as we can enhance it.
  2. Making sure co-workers realise that the documentation is part of the product can be tricky, and this leaped out at me as a good example. The product suffers because the documentation is poor.

I’m pretty sure this could have been avoided if the writer had spent more time with the product as there is little better way to fully understand how a product works, than sitting down and using it yourself.

That said, it is a very nice watch…