Web Usability

(1)

Web Usability

Gilles Bailly

gilles.bailly@telecom-‐paristech.fr

(2)

Thanks

•  Wendy Mackay

•  Patrick Baudisch

•  Jan Borchers

•  Michael Rohs

(3)

INTRODUCTION

(4)

•  Gilles Bailly

•  Chercheur CNRS à Telecom ParisTech

•  Équipe VIA (VisualizaLon & InteracLon)

– Groupe IC2

•  Departement INFRES

(5)

(6)

•  Have you ever:

– goVen lost in a Web site?

– le7 a site without ﬁnding the informaLon you wanted

– waited too long for a page to download – gone to a site you can’t view or read

– visited a site with outdated informaLon

•  Do you want people to visit and return to your site?

(7)

People cannot ﬁnd the informa/on they seek on Web sites about 60% of the 3me

[User Interface Engineering]

=> Wasted Lme, reduced producLvity, increased frustraLon, loss of repeat visits and money

The Back bu7on accounts for somewhere between 30 and 40% of all Web clicks

[Catledge 1995]

62% of online shoppers have given up at least one 3me

[Davis 1999]

(8)

Studies of user behavior on the Web ﬁnd a low tolerance for diﬃcult designs or slow sites.

People don't want to wait. And they don't want to learn how to use a home page.

There's no manual for a Web site. People have to be able to grasp the func3oning of the site immediately aLer scanning the home page

[Jakob Nielsen]

(9)

Avant (1999)

La foncLonnalité la plus uClisée était … Recherche.

“Les uLlisateurs n’arrivaient pas à naviguer sur le site.”

La seconde foncLonnalité la plus uClisée était … Le bouton ‘HELP’.

“car le moteur de recherche était ineﬃcace.”

Après

L’uLlisaLon du bouton ‘Help’a baissé de 40%

Les ventes ont augmenté de 400%

(10)

A Story

•  In 1995, now-‐famous web guru Jakob Nielsen had less than 24 hours to recommend if adding three new buVons to Sun’s home page was a good idea

•  He found that each new, but unused buVon costs visitors 500 000 $ per year.

•  2 of the 3 new buVons were taken back out

•  The method he used for his esLmate: GOMS.

Check out his “Alertbox” online column for good (and olen fun) web design advice0

(11)

DEFINITION

(12)

Usability assesses how easy your site is to learn and use by your customer

(Jacob Nielsen)

The usability of a website is based upon whether people can ﬁnd informaCon they need (Jared Spool)

The usability is based on whether you are meeLng your business and user

goals with your product (Brian Sullivan)

(13)

GOALS

(14)

•  Create Usable Web sites

•  Create Usable Web applicaLons

(15)

(16)

(17)

(18)

N’oubliez pas

l’uClisateur

(19)

Design Process

implementaLon

(20)

Today

•  Create Usable Web sites and Web applicaLons

•  Lecture

– Design Process

– Guidelines for your web pages – Web 2.0

•  Exercise

(21)

Design Process

Gilles Bailly

Gilles.bailly@telecom-paristech.fr

(22)

Design Process

implementaLon

30s Brainstorming

?

(23)

The Wrong Way: Waterfall model

2

Mobile and Physical Interaction WS 2010/2011 3

Jörg Müller, Michael Nischt, T-Labs

Analysis

Design

ImplementaLon

Test

Maintenance

Milestones (docs, solware)

Problems

–  Phases idealistic, reality requires backtracking

–  Specifications often too abstract to guide design

–  Wrong assumptions hard to detect & ﬁx early

(24)

Human activity is too complex and flexible for complete specification

⇒  Involve final users as much as you can

(25)

Researchers &

Designers Engineers &

Developers Users

(26)

Source: Preece et al.: InteracLon Design

(27)

GeneraLve

Design

(28)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

IteraCve

Process

(29)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

(30)

UNDERSTAND WHO IS THE USER

Capture users in context

Develop personas IdenLfy

key issues

Collect informaLon

Design Resources

Analyze informaLon

(31)

Learning About Users

•  Providing useful functions/contents is not enough

•  Functions/contents need to fit seamlessly to user’s tasks

•  Find real people interested in your system (otherwise there’s a problem)

Find and Know the Users

(32)

Finding Users

•  Designer: “My system is useful for everyone”

•  Designer: “I am a typical user myself”

–  Would you really use it daily?

–  Usefulness apparent to designer after long

thought process may not be obvious to the user

Find and Know the Users

(33)

(34)

How to capture data?

Interviews

Questionnaires Observations

Introspection

(35)

Interviews: Data Recording

• Notes, audio, video, photographs

• Notes plus photographs

• Audio plus photographs

• Video

(36)

Interviews: Methods

• Unstructured

–  Not directed by a script –  Rich but not replicable

• Structured

–  Tightly scripted, olen like a quesLonnaire

• Semi-‐structured

–  Guided by a script but free to explore interesLng issues in more depth

–  Good balance between richness and replicability

(37)

Interviews: How to Ask QuesCons?

• QuesLon order maVers !!!

• Start speciﬁc then general

• Start with directed then open

• Start with facts then opinions

How many messages did you receive today? (count them)

Within the last week, did you look for a speciﬁc mail message?

Did you ﬁnd it? Describe how you ﬁnd it?

Describe how you classify your messages?

Speciﬁc & directed Speciﬁc & open

General &open

(38)

How to capture data?

Interviews

Introspection

(39)

QuesConnaires

• Can be administered to large populaCons

– Paper, email, social network and the web used for disseminaLon

• Provide clear instrucCons on how to complete the quesLonnaire

• Decide on whether phrases will all be posiLve, all negaLve, or mixed

(40)

Likert Scales

• Measures degree of agreement with a statement

• Widely used for measuring opinions, artudes, beliefs

(41)

Advantages of Online QuesConnaires

• Responses are usually received quickly

• Data can be collected in database for analysis

• Time required for data analysis is reduced

• E.g.

surveymonkey.com

• Limesurvey

• Google Form

(42)

Problems with Online QuesConnaires

• No control over user context

– Validity of data cannot be guaranteed

• Diﬃcult to get a random sample that represents the whole populaLon

– PrevenLng individuals from responding more than once

(43)

How to capture data?

Interviews

Introspection

(44)

(45)

(46)

ObservaCons

•  Observing ≠ interacLng with users

•  Ethical quesLons

– Ask for permission

– Accept ‘no’ for an answer – Do not distribute data

(47)

UNDERSTAND WHO IS THE USER

Capture users in context

Develop personas IdenLfy

key issues

Collect informaLon

-‐introspecLon -‐ interviews -‐ quesLonnaires -‐ observaLons

Design Resources

-‐ Persona -‐ scenario

Analyze informaLon

-‐ idenLfy the key points -‐ give a code

-‐ group codes with similar content

(48)

Personas Example

(Cooper, About Face, Chapter 5)

•  Goal: Building a car that pleases everyone

Marge, mother of three children

Marge wants safety and room for many passengers. A minivan meets her needs.

Jim, construc3on worker

Jim wants cargo space and the ability to carry heavy load. A pickup truck meets his needs.

Alesandro, soLware engineer

Alesandro wants sporty looks and speed. A two-‐door sports car meets his needs.

Building a car based on three personas (represenLng larger groups)

(49)

Representations of Scenarios

•  Text

•  Storyboards

•  Video mock-ups

•  Scripted prototypes

•  Physical situations

•  Different levels of detail possible

•  Expanding scenarios if needed Example storyboard

(50)

Scenario Perspective

•  User’s point of view of:

•  what happens,

•  how it happens

•  and why it happens

–  User motivations toward the system –  User actions taken

–  User’s reasons why actions were taken –  User’s perception

–  Results in terms of user’s motivations and expectations

(51)

QuesCons

•  What is the most important unLl now?

–  Know and ﬁnd the user(S)

•  How to capture informaLon about users?

–  IntrospecLon –  QuesLonnaire –  Interviews

–  ObservaLons

•  How to create resources for design?

–  Persona –  Scenario

(52)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

(53)

Collect informaLon

-‐ Web search -‐ Brainstorming

Design Resources

-‐ Key ideas -‐ Design space

Analyze informaLon

Create axes

Generate new ideas

Design space

What is possible?

InvenCon

(54)

yet it fails if iniCal idea starts on a smaller hill

Engineering iteration

(1) create design / generate an idea (2) iterate by hill climbing

à this process finds the top of a hill

height =

utility of design

Design Right

(55)

Design Process

(1) create k new designs;

(2) drop k-1 worst designs

this process finds the tops of multiple hills and works with “distracter” hills

Right Design

(56)

The Master’s Book

Bill Buxton

58

(57)

Brainstorming

(58)

Brainstorming

•  Collect as many ideas on a given topic as possible

•  Quantity, not quality; include crazy ideas

–  Go for a large number of ideas

–  “To get a good idea, get lots of ideas” (Marc Rettig)

•  !!!!!No judgments!!!!!

–  Do not criLcize or argue

•  How: Scribe collects ideas visible for all:

Whiteboard & Post-it.

•  Limit to 5-10 minutes

(59)

Opposite Technique

If you get stuck, push exisLng ideas in new direcLons

Opposites:

•  Simple vs. Complex

•  Short vs. Long

•  Direct vs. Indirect

•  Text vs. Graphic

•  Funny vs. Serious

•  Process vs. Object

•  Start vs. End

•  Single vs. Sequence

(60)

Collect informaLon

-‐ Web search -‐ Brainstorming

Design Resources

-‐ Key ideas -‐ Design space

Analyze informaLon

Create axes

Generate new ideas

Design space

What is possible?

InvenCon

(61)

(62)

Affinity diagrams

Arrange cards into groups (or structure)

Find category names

Capture and discuss the groups

(63)

QuesCons?

•  How to get the RIGHT design?

– Brainstorming

•  What are the three rules?

– QuanLty not quality – No judgement

– Keep it short

(64)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

(65)

What should it be?

Design

Collect informaLon

-‐ sketches

Design Resources

-‐ Low-‐ﬁdelity protoype

-‐ Medium-‐ﬁdelity prototype -‐ High-‐ﬁdelity prototype

Analyze informaLon

Design brief Prototype opLons Select &

reﬁne prototypes

(66)

seattle public library

many of the following slides: courtesy bill buxton & Patrick Baudisch"

(67)

model

(68)

PART I: Design As Dreamcatcher

Figure 34: Details from Taccola’s Notebook (from first half of C15) Several sketches of ships are shown exhibiting different types of protective shields, and one with a “grappler.” These are the first known examples of using sketching as a tool of thought.

Source: McGee (2004); Detail of Munich, Bayerische Staatsbibliothek.

Codex Latinus Monacensis 197 Part 2, fol. 52’

Sketching is a tool of thought

Writing is slow Reading text is slow

Sketching is slow Reading sketching is

fast

(69)

(70)

The Abributes of Sketches

•  Quick

– To make

(71)

The Abribute of Sketches

•  Quick

– To make

•  Timely

– Provided when needed

(72)

The Abribute of Sketches

•  Quick

– To make

•  Timely

– Provided when needed

•  Disposable

– Investment in the concept, not the execuLon

– Inexpensive

(73)

The Abribute of Sketches

•  Quick

–  To make

•  Timely

–  Provided when needed

•  Disposable

–  Investment in the concept, not the execuLon

–  Inexpensive

•  PlenCful

–  They make sense in a a collecLon or series of ideas.

(74)

Design Process (Right design)

(1) create k new designs, add to set;

(2) drop k worst designs

this process finds the tops of multiple hills and works with “distracter” hills

(75)

What should it be?

Design

Collect informaLon

-‐ sketches

Design Resources

Analyze informaLon

reﬁne prototypes

(76)

Sketch Prototype Low investment

More opportuniLes to explore Fail early… learn

Ideas generate more ideas

Ideas selected and refined

Starting point

Focal point

(77)

Forms of Prototyping

• Low-‐ﬁdelity prototyping

• Medium-‐ﬁdelity prototyping

• High-‐ﬁdelity prototyping

Sketch Prototype

Low-fidelity Medium-fidelity High-fidelity

(78)

VerLcal prototype

Scenario

Horizontal prototype

Full interface

Nielsen, J. (1993) Usability Engineering, pp. 93-101, Academic Press.

LimiCng Prototypes

• VerLcal prototypes

–  Includes in-‐depth funcLonality for only a few selected features

–  Common design ideas can be tested in depth

• Horizontal prototypes

–  The enLre surface interface with no underlying funcLonality

–  A simulaLon; no real work can be performed

• Scenario

–  Scripts of parLcular ﬁxed uses of the system;

no deviaLon allowed

(79)

(80)

(81)

(82)

Add post-its etc for interactive widgets

(83)

Arrange them so as to have them ready

(84)

Play it out with paper as if it was real

participant

interviewer

computer

(85)

Ink Chat

assemble sketches into higher functions

Link diagrams

(86)

here: blue = links between pages

(87)

Forms of Prototyping

• Low-‐ﬁdelity prototyping

• Medium-‐ﬁdelity prototyping

• High-‐ﬁdelity prototyping

Sketch Prototype

Low-fidelity Medium-fidelity High-fidelity

(88)

What should it be?

Design

Collect informaLon

-‐ sketches

Design Resources

Analyze informaLon

reﬁne prototypes

(89)

QuesCons?

•  Why should we use paper?

– Sketches and prototypes – Quick and cheap

– Easy to communicate – Support evaluaLon

(90)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

(91)

Does it work?

EvaluaCon

Collect informaLon

-‐ Empirical evaluaLon -‐ AnalyLcal evaluaLon

Design Resources

-‐ list of problems found -‐ implicaLons for re-‐design

Analyze informaLon

-‐ staLsLc analysis Analyze

data

Generate design suggesLons

Set up studies

(92)

EvaluaCon Methods

98 Mobile and Physical Interaction WS 2010/2011

Empirical  With Users AnalyLc 

(Without Users)

QualitaLve QuanLtaLve

(93)

(94)

Between groups

(95)

Withingroups

1

ObservaLon: Marking menus (1.5s) vs. Linear menus (2.5s)

Marking menus faster?

2

WS 2010/2011

(96)

Withingroups

1

ObservaLon: Marking menus (1.5s) vs. Linear menus (2.5s)

Marking menus faster?

1

WS 2010/2011

(97)

(98)

[ Source : James Hudson, PayPal ]

(99)

(100)

(101)

(102)

33 % conversion

66 % conversion

(103)

(104)

EvaluaCon Methods

(Without Users)

(105)

(106)

(107)

(108)

EvaluaCon Methods

(Without Users)

(109)

Top ﬁve plausible excuses for not tesCng web sites

•  We don’t have the Lme

•  We don’t have the money

•  We don’t have the experLse

•  We don’t have a usability lab

•  We wouldn’t know how to interpret the results

(110)

HeurisCc EvaluaCon

1.  recruit a small set (3-‐5) of “evaluators”

2.  evaluators independently check for compliance with usability principles (“heuristics”)

3.  diﬀerent evaluators will ﬁnd different problems 4.  evaluators only communicate afterwards

5.  ﬁndings are then aggregated

6. à use list of problems to redesign/ﬁx

applicaLon ¹¹⁶

Mobile and Physical Interaction WS 2010/2011 Jörg Müller, Michael Nischt, T-Labs

(111)

The heuristics

H2-1: visibility of system status

H2-2: match between system & real world (speak the users’ language)

H2-3: user control and freedom H2-4: consistency and standards

H2-5: error prevention (minimize users’ memory load)

H2-6: recognition rather than recall

H2-7: flexibility and efficiency of use (shortcuts)

H2-8: aesthetic & minimalist design

H2-9: help recognize, diagnose, & recover from errors H2-10:help and documentation

(112)

visibility of

system status

• pay attention to response time

– 0.1 sec: no special indicators

– 1.0 sec: user tends to lose track of data

– 10 sec: max. duration if user to stay focused on action – for longer delays, use percent-done progress bars

(113)

match between

system & real world

• speak the users’ language

• follow real world conventions

• example of violation:

dragging disk to Mac trash should delete it, not eject it

bad

(114)

(115)

user control & freedom

– offer “exits” for mistaken choices, undo, redo

• wizards: must respond to question before going to next

• good for infrequent tasks (e.g., modem config.) and beginners

• not for common tasks and experts à have 2 versions (WinZip)

good

(116)

(117)

consistency & standards

bad

(118)

(119)

error prevention

recognition,

not recall

(124)

(125)

flexibility and efficiency of use

– accelerators for experts (e.g., gestures, kb shortcuts) – allow users to tailor frequent actions (e.g., macros)

bad

(126)

aesthetic & minimalist design

– avoid irrelevant information in dialogues

bad

(127)

(128)

help recognize, diagnose,

& recover from errors

– error messages in plain language – precisely indicate the problem

– constructively suggest a solution

(129)

help & documentation

(130)

(131)

Who is the user?

Discover

What is possible?

InvenCon

What should it be?

Design

Does it work?

EvaluaCon

IteraCve

Process

(132)

Design guidelines

Gilles Bailly

(133)

(134)

Do not make me think !

SemanLc

Aﬀordance

(135)

•  We don’t read pages. We scan them.

•  We don’t make optimal choices. We satisfice.

•  We don’t figure out how things work. We muddle through.

Reasons: hurry; no penalty; guessing is fun; habits

ObservaCons

(136)

Create a clear visual hierarchy

(137)

ConvenCons are your friends

(138)

Make it obvious what’s clickable

(139)

Omit needless words

(140)

Speak the user language

(141)

NavigaCon

•  Search-‐dominant users

•  Link-‐dominant users

(142)

(143)

(144)

(145)

Home page

What is this?

What do they have here?

What can I do here?

Why should I be here -‐ and not

somewhere else?

(146)

Usability guidelines for Website on mobile devices

•  Reduce the amount of content

•  Single column layouts work best

•  Minimize text entry

•  Take advantage of inbuilt funcLonality

(147)

HeurisCcs for blogs

1.  Strategy. No clear Blogging strategy 2.  Credibility. Lack of Credibility Cues

3.  Headlines. Poorly WriVen Headlines to Grab

4.  NavigaLon. Using only One NavigaLon Search schemes 5.  Content. WriLng IneﬀecLve Content

6.  Frequency. Infrequent or Irregular Updates 7.  Burying. Classic Hits are Buried

8.  Bad Forms. Cumbersome Forms to Use 9.  Search. Bad Search Forces Users to Think

10. Unresponsive. Blog can only be viewed on one device

(148)

Web Design Team Arguments

•  Diﬀerent opinions

– Everybody likes – The myth of the

average user -‐>

persona

Project Manager

Developer

MarkeLng

Designer

(149)

(150)

Web 2.0

Gilles Bailly

(151)

(152)

(153)

(154)

End of so7ware cycle

•  Solware must be maintained on a daily basis

•  Real-‐Cme cycle

•  Users are treated as co-‐developers

– Perpetual beta

(155)

Lightweight Programming Models

•  Simplicity in APIs

•  Generates new interesLng applicaLons of solware

•  Barrier to entry is low

•  Web 2.0 sites have sophisLcated databases with valuable informaLon

•  Open APIs for non commercial use

•  Google Maps API

hVp://www.google.com/apis/maps/

(156)

So7ware above the level of single device

•  Web oﬀers a common point for many diﬀerent devices

•  PC as mediator between web and mobile device

•  Leverage the power of the Web pla}orm

– Web become invisible

(157)

Rich User Experience

•  Full scale applicaLons

•  Fluid movements are appealing

•  (Re)implemenaLon on the web vs. specialized desktop applicaLons

(158)

Examples

•  hVp://zoom.it/

•  www.simile-‐widgets.org/exhibit/

•  hVp://slides.html5rocks.com/#landing-‐slide

– hVp://slides.html5rocks.com/#web-‐storage – hVp://slides.html5rocks.com/#web-‐workers – hVp://slides.html5rocks.com/#drag-‐and-‐drop – hVp://slides.html5rocks.com/#slide-‐orientaLon – hVp://slides.html5rocks.com/#new-‐form-‐types