Archive for September, 2012

Wiio’s law

September 28, 2012
  1. Communication usually fails, except by accident

    1.1 If communication can fail, it will.
    The factors that can make human communication fail might not be very serious, when each of them is taken in isolation. However, there are so many risks and they can interact in so many ways that it is statistically almost certain that communication fails.

    1.2 If communication cannot fail, it still most usually fails
    Even if you pay great attention to make your communication unambiguous, effective, and understandable, there will still be too many risks you haven’t taken care of. Moreover, your measures are at best functional most of the time, which means that the combined probability for your communication to fail in at least one one of the ways in which it could fail is higher than you dare to imagine.

    1.3 If communication seems to succeed in the intended way, there’s a misunderstanding
    When communication seems to be simple, easy and successful, it’s probably a total failure. The recipient looks happy and thankful, because he understood your message his way, which is what he likes, and very different from what you were actually saying.

    1.4 If you are content with your message, communication certainly fails
    Being content with the formulation of your message is a sure sign of having formulated it for yourself.

  2. If a message can be interpreted in several ways, it will be interpreted in a manner that maximizes the damage
    This Murphyistic remark is a warning about the very real possibility that ambiguities will be resolved in just the way you did not mean. Notice that this does not mean the worst misunderstanding you can imagine; rather, something worse – an interpretation you could not have imagined when you formulated your message.
  3. There is always someone who knows better than you what you meant with your message
    People who understand you can be a real nuisance. It might take some time before you see that they completely failed to see what you meant, but that does not prevent them for propagating their ideas as yours.
  4. The more we communicate, the worse communication succeeds
    There’s a widespread superstition that the more you communicate the better. In reality, increasing the amount of communication most probably just causes more misunderstandings.
  5. The more we communicate, the faster misunderstandings propagate
    In addition to reformulating law 4, this refers to the fact that repetition strengthens false ideas. When people see the same message repeated over and over again, they usually start believing it. Even if your message happened to be true, they misunderstood it, so what they actually believe is not what you meant. And since the message has been presented so strongly, they tell it to their friends, who propagate it further, etc. Naturally, in that process, it gets distorted more and more.
  6. In mass communication, the important thing is not how things are but how they seem to be
    This law is just remotely related to the basic law. It is however more and more important: mass communication creates a world of its own, and people orient themselves in that virtual world rather than the real one. After all, reality is boring.
  7. The importance of a news item is inversely proportional to the square of the distance
    Even more remote to our main topic, this simply states that events close to us look much more important to us than remote events. When there is an aircraft accident, its importance in Finnish newspapers basically depends on whether there were any Finns on board, not on the number of people that died.
  8. The more important the situation is, the more probably you forget an essential thing that you remembered a moment ago
    Similarly to law 6, this illustrates one of the causes of failures in communication. It applies both to senders and ecipients. The recipient tends to forget relevant things, such as items which have been emphatically presented in the message as necessary requirements for understanding the rest of it. And the sender, upon receiving a request for clarification, such as a question during a lecture, will certainly be able to formulate an adequate, easy to understand answer – afterwards, when the situation is over.

How all human communication fails, except by accident according to Professor Wiio

Flow

September 23, 2012

Based on Mihaly Csikzentmihalyi’s concept of ‘Flow’:

Achieving flow – or being in the ‘flow zone’ – indicates a player’s state between anxiety and boredom, meeting his own motivational level in that experience.

From: Gabe Zichermann & Christopher Cunnningham (2011): Gamification by Design. Sebastopol: O”reilly

Comparative Usability Evaluation

September 23, 2012

CUE stands for Comparative Usability Evaluation. In each CUE study, a considerable number of professional usability teams independently and simultaneously evaluate the same website, web application, or Windows program.

The Four Most Important CUE Findings:

  • The number of usability problems in a typical website is often so large that you can’t hope to find more than a fraction of the problems in an ordinary usability test.
  • There’s no measurable difference in the quality of the results produced by usability tests and expert reviews.
  • Six – or even 15 – test participants are nowhere near enough to find 80% of the usability problems. Six test participants will, however, provide sufficient information to drive a useful iterative development process.
  • Even professional usability evaluators make many mistakes in usability test task construction, problem reporting, and recommendations.

In more detail:

CUE-1 to CUE-6 focused mainly on qualitative usability evaluation methods, such as think-aloud testing, expert reviews, and heuristic inspections. CUE-7 focused on usability recommendations. CUE-8 focused on usability measurement.

  • CUE-1 – Four teams usability tested the same Windows program, Task Timer for Windows
  • CUE-2 – Nine teams usability tested http://www.hotmail.com
  • CUE-3 – Twelve Danish teams evaluated http://www.avis.com using expert reviews
  • CUE-4 – Seventeen professional teams evaluated http://www.hotelpenn.com (nine teams with usability testing and eight teams with expert reviews)
  • CUE-5 – Thirteen professional teams evaluated the IKEA PAX Wardrobe planning tool on http://www.ikea-usa.com (six teams with usability testing and seven teams with expert reviews)
  • CUE-6 – Thirteen professional teams evaluated the Enterprise car rental website, http://www.Enterprise.com (10 teams with usability testing, six teams with expert reviews, and three teams with both methods)
  • CUE-7 – Nine professional teams provided recommendations for six nontrivial usability problems from previous CUE-studies
  • CUE-8 – Seventeen professional teams measured key usability parameters for the Budget car rental website, http://www.Budget.com
  • CUE-9 – A number of experienced usability professionals independently observed five usability test videos, reported their observations and then discussed similarities and differences in their observations (the “Evaluator Effect”)

Most important finding from individual CUEs:

  • Realize that there is no foolproof way to identify usability flaws. Usability testing by itself can’t develop a comprehensive list of defects. Use an appropriate mix of methods.
  • Place less focus on finding “all” problems. Realize that the number of usability problems is much larger than you can hope to find in one or even a few tests. Choose smaller sets of features to test iteratively and concentrate on the most important ones.
  • Realize that single tests aren’t comprehensive. They’re still useful, however, and any problems detected in a single professionally conducted test should be corrected.
  • Increase focus on quality and quality assurance. Prevent methodological mistakes in usability testing such as skipping high-priority features, giving hidden clues, or writing usability test reports that aren’t fully usable.
  • Usability testing isn’t the “high-quality gold standard” against which all other methods should be measured. CUE-4 shows that usability testing – just like any other method – overlooks some problems, even critical ones.
  • Expert reviews with highly experienced practitioners can be quite valuable – and, according to this study, comparable to usability tests in the pattern of problems identified – despite their negative reputation.
  • Focus on productivity instead of quantity. In other words, spend your limited evaluation resources wisely. Many of the teams obtained results that could effectively drive an iterative process in less than 25 person-hours. Teams A and L used 18 and 21 hours, respectively, to find more than half of the key problem issues, but with limited reporting requirements. Teams that used five to ten times as many resources did better, but the additional results in no way justified the considerable extra resources. This, of course, depends on the type of product investigated. For a medical device, for example, the additional resources might be justified.
  • The number of hours used for the evaluations seems to correlate weakly with the number of key issues reported, but there are remarkable exceptions.
  • Expert review teams use fewer resources on the evaluation and in general report fewer key issues, but in general their results are fully acceptable.
  • The teams reported surprisingly few positive issues, and there was no general agreement on them. Many positive issues were reported by single teams only. You might ask whether the PAX Planner is really that bad, or if usability professionals are reluctant to report positive findings.
  • Spell out your recommendation in detail to avoid misunderstanding and ‘creative misinterpretation.’
  • Recommend the least possible change. Tweaking the existing thing is always preferable to starting over. Major changes require major effort, including retesting a lot of ‘stuff.’
  • Be careful when you report minor problems from a usability test. No one else may agree with you that the problem is worth reporting.

DialogDesign

Contingency design OR Defensive design

September 18, 2012

Contingency design is design for when things go wrong . It’s the error messaging, graphic design, instructive text, information architecture, backend system, and customer service that helps visitors get back on track after a problem occurs.

Whitepaper on 37signals.com

Defensive design is inspired by the concept of ‘defensive driving’ (that is , recognizing potential accident situations developing and taking advance measures to avoid them). (…) Site builders must constantly search for trouble spots that may cause visitors confusion and frustrations.

(…)

Examples of successful contingency design:

  • An error message that clearly explains how to fix the problem
  • A form field that prevents a visitor from entering too many characters
  • A form that validates responses before they accepted
  • Customised ‘Page not found’ screen that explains the problem and helps people get to the desired page
  • Contextual help (definitiojns and inline FAQs that answer questions on the spot
  • Login help (for instance ‘Forgot your Password? Click here’)
  • Help copy that doesn’t require a dictionary or technicalk manual to understand
  • FAQs that solve the most common problems that plague customers
  • A smart search engine that understands misspellings and other common errors
  • Email notification for the return of an out-of-stock item

Matthew Linderman with Jason Fried (37signals): Defensive design for the Web (2004), New Riders

PICTIVE

September 5, 2012

PICTIVE (Plastic Interface for Collaborative Technology Initiatives through Video Exploration) is a paper mock-up technique that allows users to participate in the development process. A PICTIVE is a representation of a graphical user interface (GUI) or a Web page on paper. A PICTIVE prototype gives a user a sense of what a system or a piece of software will look like and how it will behave once it is finished. PICTIVE enables a non-technical person to contribute ideas to the development process.

http://searchenterpriselinux.techtarget.com/definition/PICTIVE