Posts

Showing posts with the label manuals

The Manuals Problem

In the Healthcare industry I work in, we have to “validate” the product before we start selling it. In our context, the term “validate” means something more than just “to test”. Rather, it means “testing by the person who would be the actual user of the product”. Why is this so important? An example will clarify.   An engineer who is designing the product may use the touch interface on the screen and conclude it’s all good. But what if the nurse or doctor wears gloves in their work environment? Does the touch interface still work fine? Or maybe the terms used onscreen are obvious to engineers but make no sense to anyone else? It is to try and discover such issues that validation by a “real user” is critical.   But even our doctors who validate our products won’t help validate the manuals. Who wants to go over a manual and give feedback as to whether it is clear or not? This, of course, is a problem with all manuals, across product categories and across industries. ...

End of the Manual

When my parents bought their iPad, they wondered where the manual was. There isn’t one. Today, the no-manual approach is standard for almost all our gadgets. But Steve Jobs saw that technique for the first time when he worked at Atari. Walter Isaacson, in his (official) biography of Jobs, describes it thus: “(Jobs) intuitively appreciated the simplicity of Atari’s games. They came with no manual and needed to be uncomplicated enough that a stoned freshman could figure them out. The only instructions on Atari’s Star Trek game were: 1)       Insert quarter. 2)      Avoid Klingons.” It hit me only then: I never had any trouble learning any of the Atari games as a kid even though there were no instructions or manuals. They were that intuitive. But surely our gadgets are more complicated than video games, right? Like when we were setting up the Wi-fi on my parents’ iPad, they entered the wrong password. So it wouldn’t connect; but i...