8 Golden Rules of Interface Design 9-3-2012jsearlem/cs459/fa12/slides/...8 Golden Rules of Interface...

Post on 18-Jun-2020

1 views 0 download

Transcript of 8 Golden Rules of Interface Design 9-3-2012jsearlem/cs459/fa12/slides/...8 Golden Rules of Interface...

8 Golden Rules of Interface Design

9-3-2012

What is Digital Entertainment? It's video games (like SnapShot), short animations (like PaperMan), digital art, and interactivity. So we have created a student club called the Interactive Digital Entertainment

Club -- the IDEA Club!

first IDEA club meeting tonight!

Monday, 9/3/12, 7:00 pm in the CEC

events include

Ottawa International Animation Festival (OIAF)

Montreal International Game Summit (MIGS)

Speakers – Digital Art, using the Kinect, etc.

Animation festival

•Road sign in Mexico

• Controls on a rental car

From: www.baddesigns.com

Usability goals include:

Effective to use

Efficient to use

Safe to use

Have good utility

Easy to learn

Easy to remember how to use

User Experience goals include:

Satisfying

Enjoyable

Supportive

Aesthetically pleasing

Engaging

Helpful

Motivating

Visibility

Feedback

Constraints

Mapping

Affordance

Restrict user actions to valid actions

Eliminate need for perfect knowledge

Recognition over recall

Poor use of constraints Tokyo Stock Exchange software did not

prevent trader from making an outrageous trade

Command line systems force you to remember spelling and syntax of commands

Good use of constraints Click on icons to invoke commands Gray out unavailable actions

Visibility

Feedback

Constraints

Mapping

Affordance

Natural mappings: no explanations needed

User intentions

Available actions

Perceived system state

Actual system state

Relationship between controls and their movements and the results in the world

Why is this a poor mapping of control buttons?

Why is this a better mapping?

The control buttons are mapped better onto the sequence of actions of fast rewind, rewind, play and fast forward

Which controls go with which burners?

A B C D

User intentions to available actions

Is there a natural mapping between what users want to do and what appears possible?

Do users stare at technology for sometime before they take action?

Or do they immediately know what to do?

Simplicity can help

User intentions

Available actions

Perceived system state

Actual system state

User intentions to available actions

Poor mapping

●Stove top controls

●Clustered light switches

Good mapping

●Consistent play, rewind, fast forward, stop controls on media devices

●Clearly visible and labeled power buttons

User intentions

Available actions

Perceived system state

Actual system state

Available actions to perceived system state

The user should not be surprised with what happened after they completed an action

Technologies should behave in expected ways

Quick feedback is very important

Problems more likely if the mappings between user intentions and available actions were not good

User intentions

Available actions

Perceived system state

Actual system state

Available actions to perceived system state

Poor mapping

●Pull from a door knob when you were supposed to push

●Try to close an application that won’t close

Good mapping

●Press gas pedal, feel car accelerate

User intentions

Available actions

Perceived system state

Actual system state

Perceived system state to actual system state

Users think the technology is doing one thing when it really is doing something else

Users unlikely to quickly detect problems

User intentions

Available actions

Perceived system state

Actual system state

Perceived system state to actual system state

Poor mapping

●757 Flight Management System had pilots thinking they were traveling towards different beacon

Good mapping

●Well-implemented progress bars

User intentions

Available actions

Perceived system state

Actual system state

Actual system state to user intentions

Does the system allow states that users would never want?

Difficult to implement

Important for critical systems

User intentions

Available actions

Perceived system state

Actual system state

Actual system state to user intentions

Poor mapping

●Tokyo Stock Exchange software sold stocks far below market price (and more than were available)

Good mapping

●Voting systems that allow you to select only one candidate for President

User intentions

Available actions

Perceived system state

Actual system state

Visibility

Feedback

Constraints

Mapping

Affordance

Refers to an attribute of an object that allows people to know how to use it e.g. a mouse button invites pushing, a door

handle affords pulling

Norman (1988) used the term to discuss the design of everyday objects

Since has been much popularised in interaction design to discuss how to design interface objects e.g. scrollbars to afford moving up and down,

icons to afford clicking on

Poor affordances

e.g. Doors

Push or Pull?

Where to push?

Good affordances

Buttons that appear clickable

Interfaces are virtual and do not have affordances like physical objects

Norman argues it does not make sense to talk about interfaces in terms of ‘real’ affordances

Instead interfaces are better conceptualised as ‘perceived’ affordances

Learned conventions of arbitrary mappings between action and effect at the interface

Some mappings are better than others

Perceived or actual properties of objects

What can you do with it?

Should you click it, drag it, is it part of the background?

Can you tell what parts of a user interface are interactive?

Virtual affordances

How do the following screen objects afford?

What if you were a novice user?

Would you know what to do with them?

Concept How to Use

Usability Goals determining assessment criteria

User Experience

Goals

identifying important aspects of the

experience

Usability Principles assessing the acceptability of an

interface

Shneiderman, Chapter 2, Section 2.3.4:

1. Strive for consistency 2. Cater to universal usability 3. Offer informative feedback 4. Design dialogs to yield closure 5. Prevent errors 6. Permit easy reversal of actions 7. Support internal locus of control 8. Reduce short term memory load

Consistent sequences of actions should be required in similar situations

Identical terminology should be used in prompts, menus, and help screens

Consistent color, layout, capitalization, fonts, etc. should be employed throughout

Exceptions, such as required confirmation of the delete command, should be comprehensible and limited in number

Recognize the needs of diverse users and design for plasticity, facilitating transformation of content. Novice-expert differences, age ranges, disabilities, and technology diversity affect the requirements that guide design.

For every user action, there should be system feedback.

For frequent and minor actions, the response can be modest

For infrequent and major actions, the response should be more substantial

Sequences of actions should be organized into groups with a beginning, middle, and end.

Informative feedback at the completion of a group of actions gives operators a sense of accomplishment (and relief), and a signal to prepare for the next group of actions

As much as possible, design the system so that users cannot make serious errors. For example, gray out inappropriate menu items, do not allow alphabetic data in a numeric field

If a user makes an error, the interface should detect the error and offer simple, constructive, and specific instructions for recovery

Erroneous actions should leave the system state unchanged, or the interface should give instructions about restoring the state

Make error messages specific, positive in tone, and constructive

As much as possible, actions should be reversible. This feature relieves anxiety, since the user knows that errors can be undone, thus encouraging exploration of unfamiliar options.

The units of reversability may be a single action, a data-entry task, or a complete group of actions, such as entry of a name and address block

Experienced operators strongly desire the sense that they are in charge of the interface and that the interface responds to their actions. Surprising interface actions, tedious sequences of data entries, inability to obtain or difficulty in obtaining necessary information, and inability to produce the desired action all build anxiety and dissatisfaction.

The rule of thumb for short-term memory is “seven plus or minus two chunks”

The limitations of human memory requires that displays be kept simple, multiple-page displays be consolidated, window-motion frequency be reduced, and sufficient training time be allotted for codes, mnemonics, and sequences of actions

Where appropriate, online access should be provided

It is a process:

a goal-directed problem solving activity informed by intended use, target domain, materials, cost, and feasibility

a creative activity

a decision-making activity to balance trade-offs

1. Identifying needs and establishing requirements for the user experience

2. Developing alternative designs to meet these

3. Building interactive prototypes that can be communicated and assessed

4. Evaluating what is being built throughout the process and the user experience it offers

User-centered approach is based on:

Early focus on users and tasks: directly studying cognitive, behavioral, anthropomorphic & attitudinal characteristics

Empirical measurement: users’ reactions and performance to scenarios, manuals, simulations & prototypes are observed, recorded and analysed

Iterative design: when problems are found in user testing, fix them and carry out more tests

Not as obvious as you think: those who interact directly with the product those who manage direct users those who receive output from the product those who make the purchasing decision those who use competitor’s products

Three categories of user (Eason, 1987): primary: frequent hands-on secondary: occasional or via someone else tertiary: affected by its introduction, or will

influence its purchase

Who are the stakeholders?

Check-out operators

Customers Managers and owners

• Suppliers

• Local shop

owners