UbuntuWiki:Usability

{{#ifexist: :UbuntuWiki:Usability/zh | | {{#ifexist: UbuntuWiki:Usability/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:Usability|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:Usability|1|-1|}} | zh | | }}

ISO 9241-11 defines Usability as: "Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use."

To break this down:

"Extent to which a product can be used..."

Usability is thus not a property of the product itself but rather a property of the using of the product. It is a somewhat measurable property. It may not be easily quantified but can and should be subject of qualitative analysis. Another name for usability is quality in use. Making it clear that it's part of the overall quality of the product.

"...by specified users..."

It's impossible for a product to usable for all users (well almost), why you should define exactly what user the product is supposed to be usable for to be able to determine how usable it is.

A common technique for describing users is to create a persona. JoeSixpack is an example of such a persona:

"Joe Sixpack is the generic guy who sits on his couch watching the football, hockey, soccer, baseball games incessantly, in between watching trashy american sitcoms. This person believes he's a great person and citizen if he votes once every four years." - Joe Sixpack at everything2.com

Although it can be argued that JoeSixpack isn't a very good persona. He is to generic and undefined. A good persona is the result of careful analysis of a specific target group.

"...to achieve specified goals..."

Just as a product must be designed for a specific user it also has to be designed to be usable to achieve a specific goal. It can't be just "usable" it must be usable for something.

A common mistake is to define goals as the technical effect of using a product. A goal for which a product is usable is almost certainly external to the product. Most importantly the goal is something that is important to the specified user, it is not generic.

A goal such as compress sound files is probably to technical, the goal might be to store music or something along those lines. It depends on the user and is one of the hard part of usability analysis to get right. Usually the user isn't very good at expressing his/her goals so careful analysis is required to determine useful goals. Failure to do so often results in late revision in the requirement specification (anyone who has done any development work knows what I'm talking about).

It's also important to determine whose goals are to be met. It isn't certain that the user is the only stakeholder in the product and it's design. In fact, most of the time the most important stake holder isn't the user at all. However to satisfy the main stakeholder one usually have to make sure that the design satisfy the user.

"...with effectiveness, efficiency and satisfaction..."

Also a common misconception is that usability is isolated to efficiency or effectiveness, or even worse ease of use. Satisfaction is an important part of usability, because this is what makes a user want to use the product.

It's only logical that a usable product actually have to be used. A common metric when designing for usability is usage rate, the extent to which the product is actually used in the day to day lives of the users.

"..in a specified context of use."

An often missed part of usability is the context. When and where and under what conditions is the product to be used?

The obvious example is a paper and a pencil. If you study this simple product you'll probably find that it's exceptionally usable. But would be utterly useless if the specified context of use is: underwater at a dive.