Can you design your way to a “no user documentation” approach?

Chris Edwards has written an article on product design in the E&T magazine called “The art of avoiding lemons“, in which he looks at whether there is more to product design than simply getting your design to look good or your product to work. He shows there are many situations where brilliantly designed products still fail.

Managing customer expectations

Edwards quotes findings from Elke den Ouden and colleagues at Eindhoven University of Technology and Philips Applied Technologies, who found that half of the consumer electronics products returned to stores worked just fine: the customers simply had not been able to figure out how to get them to operate properly.

According to den Ouden:

For businesses today, the main risk with respect to quality and reliability of new products is not just technical failures, but also failures of a non-technical nature, that is, complaints due to the product not meeting the consumer’s expectations.

He also cited findings from a 2006 report by consultant Sara Bly and a team from Intel Research and the University of Washington, called “Broken Expectations in the Digital Home“. This report listed:

A litany of failure by consumer-electronics vendors to provide products that did what the users wanted. And yet each product surveyed did, at least nominally, what it was designed to do.

Connectivity – A series of unfortunate events

In addition to the broken expectations also mentioned by den Ouden, Bly stated the reasons for these failings were partly due to users being unable to connect one device to another. This complexity issue has also been highlighted by research into how small to medium sized enterprises use IT. Dr Alan Rae’s “Abandoned Heroes” report stated similar findings, where a single individual in the business often had to rely on their own self-taught expertise and felt ill-equipped to carry out the implementation tasks required of them.

Meaningless dialog boxes and error messages

Edwards also claims that users can be stumped by error messages. He quotes Don Norman:

(Product designers) assume perfection, a smoothly operating ticket machine, always performing smoothly and efficiently.

If we also consider Rachel Potts’s article, “3 good reasons software will always need help“, where she argues users may need key concepts and context explained to them, then we may come to understand why dialog boxes such as the one below may need some explaining:

No amount of good design will help you understand a “wiggle factor of 4”, if you have no understanding of the concept of “wiggle factors”.

Different users on the Rogers Technology Adoption Lifecycle Curve will have differing requirements

At last week’s UA Conference Europe 09, IBM’s Mike Hughes made the great point that the adoption of technology over time will have an impact on the effectiveness on your design.

He said that different types of users will have different expectations and needs for documentation. Sometimes, all you need to tell users what is a good choice. At other times, you need to explain how to do things, step by step.

My thoughts

For simple, commonly known actions in a closed environment, you probably can design your way to a “no user documentation” approach. Good design can also lead to less documentation. However, customers may expect to do more than that with a product and, in those situations, documentation can play a key role in meeting those expectations.