Interaction design with Amy Hoy, Webstock 2008

Notes from the Interaction Design workshop run by Amy Hoy, on the first day of Webstock 2008. We started with an overview of how people interact with computers, and what's effective (or what is thought to be). We then talked about some interface design problems and solutions.

Definitions

An interface is comprised of:

• User expectations - what previous experiences do users have? What knowledge do they bring that will inform their view of the interface?
• Direct interaction - with components of the interface
• Behaviour - software and websites have personality, is the behaviour reliable, what happens to errors, can users recover?

The only part a designer really has control over is direct interaction. It's not easy to control users' expectations, or perception of behaviour.

"Design is not just what it looks like. Design is how it works" Steve Jobs

Some basic principles

There is natural gravity in left-right reading languages, as shown in Amy’s version of the Gutenberg diagram below. Items in the top left get most emphasis. Readers scan left to right, with a pause at end of each line. Gravity pushes the reader to the bottom-right. Note the top-right, and bottom-left dead-zones.

There is a left to right causality. Items to the right are ahead in time or place

Cascading top-down sense of hierarchy e.g. the navigation at the top of a page applies to content below.

Be wary of sidebars and vertical noise. Left sidebars don't stand in the way of the reading flow and are not a good place for critical info (could be okay for navigation if it is not core content). Right sidebars do stand in the way and are more noticeable (but at the cost of interrupting the reading flow).

The myth of content below the fold. It’s okay to have content further down the page. Important content would go near top, but users do know how to scroll.

Beware of designing a ‘satisficing’ experience. Users are satisficed (but not truly satisfied) when they select something that is good enough, but not really what they wanted e.g choosing chocolate when they really wanted chocolate mint.

Design for people’s objectives. What is it the users want? Users have different priorities than the people who designed the software have.

Amy also highly recommended the First Principle article by "Tog" Tognazzini.

Visual perception is predictable

We don't really see everything with our eyes. There is a black hole in our vision that is not perceptible because the brain compensates. Things we observe are not necessarily as we see them, but how they are perceived. When designing objects (e.g. buttons), be aware of the patterns that we can observe.

Primary:

• colour
• shape
• size
• orientation
  

Secondary:

• intensity (luminance)
• density (proximity)
• 3D
• segregation (order)

What people don't see is also predictable, but amazing (change blindness). It extends to real life.

People can be looking right at it and they might not see it. See Darren Brown's example of the person swap experiment when people don’t notice that the person they are speaking is swapped half-way through.

Cognitive mappings - a study in contradictions (Western bias)

Avoid obvious design contradictions:

• red / good combinations don't match e.g. a red continue button
• green / bad combinations don't match e.g. a green cancel button
• don't just use colour - use secondary cues as well
• left to right, and up, indicate more not less

Form design tips

• First: do you really need a form? Is there an alternative e.g. IP detection and country look-up instead of selecting from a country drop-down
• Second: what can you eliminate? “Elegance is taking away everything that can be taken away, but nothing more” Unknown author
• Use HTML label tags
• Text labels to the left or top of fields? Research suggests form labels to the left are better, but top can also be okay
• Segment form into sections with section titles e.g. billing information
• Can use inline fields e.g. “I drink coffee times a day”
• Look for opportunities to respect peoples time e.g. put common countries at top of drop-down list. Include both number and name for month list (lots of people have to count dates in their head)

Designing for mistakes

Fault tolerance is not well designed on the web. Some good ideas:

• Deal with it – in Twitter, if you post too much text, you will get a warning. Twitter will then truncate the posting of the message, but let readers know there is more to see if they want
• Be fault tolerant – Gmail allows users to undo mistakes
• Leave room for mind changing - Writeboard sends an email for recovery of doc deleted
• There are always new ideas coming through, keep up-to-date with new solutions by reading research reports like those at acm.org
• Make errors impossible (poke yoka). Fail safing, or mistake proofing, means avoiding (yokeru) inadvertent errors (poka). It is a behaviour-shaping constraint or a method of presenting errors by putting limits on how an operation can be performed in order to force the correct completion of the operation.
  

Some good design patterns and ideas

• Lazy registration - only ask for info that you need upfront
• Step through orientation - numbered steps in form or action
• Graded, smart help systems - get extra info the first time you log on, but not again later
• Useful footer, embrace your bottom - the users who get to the bottom of a page are dedicated... reward them with something, but make sure it is optional add-on content that is not required
• Make things non-destructive and hard to make a mistake - don't have the cancel button before the submit. If vertical, also have the submit option first. You can separate go / no-go options by distance, icon and colour
• Gradual exposure of features - Flickr buttons that have further roll-down features that can be discovered. New users vs. advanced... there is always a balance between them
• Design for recoverability
• Consistency of design elements - often enforced post-design. See Togs list of seven most important things for consistency... but don't go overboard.
• Maintain state / return to state (closed loop) - come back to the page or place where you unexpectedly left. This doesn't happen often, but would be great if it did
• Re-filling out incorrect form fields
• Be flexible with data input - e.g. accept dates in multiple format to support different countries
• Good use of verbs and noun in labels

Usability

Usability people will tell us that "usability is a science". Don't take usability advice at 100% face-value. It's not a science. It does provide good clues though.

Fitts' law above quantifies the time to acquire a target. User interface researchers have used this formula to consider the design and placement of buttons, or pointing activities on the web. The problem is that this law was conceived 50 years ago. It has been retested more recently, and does still work... but it's not fallible. Research and analysis is not a substitute for thinking. Real life is difficult to measure.

And finally, when creating an interaction design meet people as they are... not as they should be. Don't assume people think a particular way, or understand something the way you want them to. Don't assume, find out.