inf5120 – modellbasert systemutvikling · telecom and informatics 4 rational for introducing...

1Telecom and Informatics

INF5120 – Modellbasert Systemutvikling

F13-2: Brukskvalitet, evaluering og bruker opplevelser(chapter 10: Usability and User Experience ++)

Forelesning 21.04.2005Arne-Jørgen Berre


Definition of UsabilityA concept comprising the effectiveness, efficiency and satisfaction with which specified users can achieve specified goals in a particular environment (ISO 9241 v 2.5)

The extent to which a product can be used effectively, efficiently and with satisfaction by specified users, for specified tasks in specified environments (ESPRIT 5429: MUSIC project)

“ a measure of ease with which a system can be learned or used, its safety, effectiveness and efficiency, and attitude of its users towards it” (Preece, 1994, pp 722)


Why usability?

shortening the time to accomplish tasks

reducing the number of mistakes made

reducing learning time

improving peoples’ satisfaction with a system

reduce development time


Rational for introducing usability

IBM gained a 400% increase in online sales (and an 84% decrease in help button usage) after redesigning their web site according to usability principles (Tedeschi, 1999).

Productivity within the service sector would rise 4% - 9% annually if every software program were designed for usability. (Landauer, 1995)

According to a 1995 study by The Standish Group the three main factors in a successful software project are; user involvement, support from executive management and clearly formulated requirements (http://www.standishgroup.com/chaos.html).

The implementation of usability engineering techniques has demonstrated a reduction in the product development cycle by 33% - 50%. (Bosert, 1991)

Every $1 invested in user-centred design returns between $2 and $100. (Pressman, 1992)


User-centred design implies

early focus on users, tasks and environment; the active involvement of users; an appropriate allocation of function between user and

system; the incorporation of user-derived feedback into system

design; iterative design whereby a prototype is designed, tested

and modified;


Development processPhases - organisation along time

Supporting activities

Iterations:

Requirements capture

Analysis & design

Implementation

Test

Process activities Elaboration ConstructionInception Transition

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

preliminaryiteration(s)

Project management

Review milestones:Pr

oduc

t Com

mit

Tech

nica

l Aud

it

Dem

onst

rato

rIt

erat

ion

Laun

ch

Dem

o / D

eliv

ery

Bet

a Te

st L

aunc

h

Acc

epta

nce

Mee

ting

Dem

onst

rato

rIt

erat

ion

Laun

ch

iter.#m

iter.#m+1

Work product management

Business analysis

Phases - organisation along timePhases - organisation along time

Elaboration ConstructionInception Transition

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

preliminaryiteration(s)

Act

ivity

orga

niza

tion

by w

ork

type

Ince

ptio

n R

evie

w

iter.#m

iter.#m+1

Prot

otyp

eIt

erat

ion

Lau

nch

Evaluation of the product with real users to see if it meets user requirements

User-centered techniques which give input to the design prosess


Why modeling?

Communication with developers Users have mental models of their world ( user model ) …


Target audience and description format

users Visual designers

Software developers

The description of the

results should foster communication

with the target audience


The user and the designer

Descriptions

Designers

produce and use

Users' world

Users

Prototype

Implementation

ImplementationReferents

GoalsTasks

Referents

inform

guide

specify

specify

Designers' world


Models of the users world

User' World

Referent

User

Task

ReferentDescriptions

User Profile

Taskdescription

Use Case

Scenario

uses

performsdescribes

describes

describes

describes

describes

0..1

*

0..1

0..1

*

involves

involves

0..1

0..1

*

*

*

**

*

*

*

correspondence

1..*

1..*

1..*

1..*

1..*

*

*

*

11

1

illustrated byillustrated by

used in taskperformance

1..*


Handbooks

http://www.informatics.sintef.no/projects/HCI/doc/index.html


‘Pen-case’ used for paper prototyping and requirement sessions


Viktige ting å tenke på når en skal planlegge bruk av brukersentrerte teknikker Brukere – få med alle viktige brukergrupper: Ledelse,

sluttbrukere, support, …. Kritiske oppgaver – finnes det noen oppgaver som MÅ

støttes Hvor mye ressurser og tid er tilgjengelig? Lokal organisering og eksisterende metodikk


Hva er oppgaveanalyse?

Teknikker som har til hensikt å beskrive forutsetninger for og konsekvenser av å utføre en gitt oppgave.

Særlig vekt på faktorer i arbeidsomgivelser, organisasjon og egenskaper ved brukere.

Arbeidsoperasjoner brytes gjerne ned i deloppgaver for videre analyse.


Hierarkisk Oppgaveanalyse

1 Sett inn kortet 2 Tast inn pinkode

1 Sjekk saldo på konto

2 Sjekk saldo i kortet

3 Bestem beløp

4 Tast inn beløp

3 Velg beløp 4 Ta kortet 5 Ta pengene

Trykk avslutt

Velg skjerm/utskrift

Les ny kontostatus på skjerm

Motta kvittering

6 Avslutt transaksjon

0 Ta ut penger fra minibank

Plan 01 - 2 - 3Hvis penger på konto 4 - 5 - 6

Plan 31 hvis saldo > 0 gå videre

ellers gå til 062 hvis saldo > 0 gå videre

ellers gå til 063 - 4


1. Forberede for kjæremåls-utvalg

PLAN 1 Sivile saker1: Når posten er fordelt (2 g/dag + bud fra adv. / statsadvokaten)(2: Ikke aktuelt)3: Når saken er mottatt4: Når saken er registrert5: Når saken er tildelt fra utredingsleder6: Når saken er ferdig utredet

1.1 Motta sakfra underrettellerriksadvokat

1.2 Registrereny straffesaksak

1.4 Planlegge utredning

1.5 Utrede sak 1.6 Fordele tilkjæremålsutvalg

PLAN 1 Straffesaker1: Når posten blir fordelt eller saken kommer med bud til straffesaksfunksjonær 2: Når saken er mottatt - Fengslingskjæremål først, andre saker når fengslinger er ferdig fordelt til kjæremålsutvalget(3: Ikke aktuelt)4: Når saken er fordelt til kjæremålsutvalg 5: Når saken er tildelt fra utredingsleder6: Når saken er registrert

NB! Begjæring om omgjøring av beslutning

1.3 Registrereny sivil sak

1.4.1 Definerehva saken gjelder

1.4.2 Fordele til utreder

Se detaljeringSe detaljering Se detaljering Samme som 1.2.2

3. Forberede for avdelings-behandling

4. Forhandle sak i avdeling

5. Etterarbeid med avgjort sak

2. Behandle sak i kjæremåls-utvalg

6. Post-behandling

8. Utarbeide HRs sammen-setning og tablå

9. Utarbeide statistikk

7. Svare på direktehenvendelser

Avgjøre saki høyesterett


SpørreteknikkHierarkisk oppgaveanalyse

Hva er oppgaven

?

Hvorfor?

Hvordan?

Hva går forut? Hva følger etter?


Tabularisk oppgaveanalyseOppgavensmål Hva erhovedmåletved å utføredenneoppgaven?

Valg Kanbrukerenvelge omde vilbrukeproduktettil å oppnådet deønsker?

Resultat avoppgavenHva erresultatet avoppgaven?

BivirkningerKan det atoppgavenblir utførtresultere iuheldigebivirkninger?

OppgavefrekvensHvor ofteer detvanlig åutføreoppgaven?

Oppgavens varighetHvor langtid vilbrukerenvanligvisbruke påoppgaven?

OppgavensfleksibilitetMå brukerenfølge enbestemthandlings-rekke for åutføreoppgaven?

Fysiske ogmentalekravFaktorersom gjøroppgavenkrevende.

SikkerhetEr opp-gavenskadeligellerfarlig forbrukerenellerandre?

0 Ta utpengerframinibank

Få merekontanter

Ja, ibankensåpningstid.

Brukeren fårmerekontanter oglavere saldopå konto.

Noen brukerevil brukemere pengerenn ved uttaki bank.

1 til 5ganger permnd.

5 min Ikke fleksibel Forstyrrelserfra andre ikøen. Huskepin-kode.Lesbarhet avskjermen.Skinn iskjermen.

Sjansenfor å bliranet erstørre ennved uttak ibank. (?)

1 Stikkeinn kortet

Startetransaksjon,identifisereseg.

Nei Adgang tilnestedeloppgave.

Brukeren kanvære usikkerpå omautomaten"sluker"kortet.

Hver gang 10 sek. (?) Ikke fleksibel Vanskelig åsette kortetriktig inn.Noen vil haproblemermed å rekkeopp.

Nei

2 Tasteinn pin-kode

Identifisering Nei Adgang tilnestedeloppgave.

Mulighet forat andre serpin-koden?

Hver gang 20 sek. (?) Ikke fleksibel Man måhuske pin-koden.

(Sebivirkninger)


Fra brukersentrert teknikk til UML diagram En oppgave i oppgaveanalysen kan brukes for å

identifisere ett use case (systemnivå). COMET kravmodellering. Use casene kan videre analyseres med tanke på bruker-

opplevelse og grafisk brukergrensesnitt.

En oppgave i oppgaveanalysen kan brukes for å identifisere en aktivitet i en prosess (virksomhetsnivå) COMET virksomhetsmodellering. Aktivitetsgrafene analyseres videre for å identifisere krav til

systemet.


Activity: Model the User-Experience Artifact: User-Experience Model (Use-Case Storyboards)


Activity:Model theUser-Experience

Artifact:User-ExperienceModel


Usability and User Experience

1) Systems must provide a way to aggregate data and commands

2) Systems should allow users to cancel commands 3) Systems should allow concurrent use of applications 4) Systems should check for correctness 5) Systems should allow recovery from systemic failure 6) Systems should allow retrieval of forgotten information 7) Systems should provide good help

kap. 10, side 210-215



8) Systems should allow reuse of existing information 9) Systems should leverage users’ existing knowledge 10) Systems should allow easy modification of interfaces 11) Systems should allow navigation from within a single

view 12) Systems should display the system state 13) Systems should allow working at the user’s pace 14) Systems should predict task duration



15) Systems should support Undo, whereby a user may use the Undo command to revert to the state prior to an action

16) Systems should help users working in an unfamiliar context

17) Systems should verify resources before initiating an operation

18) Systems should operate consistently across views 19) Systems should support appropriate visualization 20) Systems should support comprehensive searching 21) Systems should provide ways to evaluate the system


Brukersentrert evaluering Brukskvalitet (ISO 9241-11)

Spesifiserte brukere, kontekst, oppgaver Måloppnåelse Effektivitet Tilfredshet

Hensikt Avdekke og analysere brukerproblemer Identifisere design-forbedringer Identifisere gode løsninger

Tidspunkt Konsept Tidlige prototyper Kjørende prototyper Ferdige produkter/tjenester


Grunnlaget for brukersentrert evaluering

Brukergrupper Motivasjon IT-kompetanse Erfaring med lignende tjenester (behøver ikke være IKT-baserte) Domenekunnskap Evt. redusert funksjonsevne

Kontekst Sosial/organisasjonsmessig Teknisk Fysisk Opplæring

Primæroppgaver I verden – som ikke utføres gjennom brukergrensesnittet

Oppgaver Målsetninger med UI-interaksjon (fra brukerperspektiv) Frekvens og viktighet av oppgave Oppgaveanalyse


Evalueringsmetoder

Analytisk vs. empirisk Analytiske metoder

Heuristisk evaluering Cognitive Walkthrough

Empiriske metoder Brukerevaluering i laboratorium Brukerevaluering i felt

Brukere og kontekst

Primæroppgaver

UI-relaterte oppgaver

Steg-for-steg gjennomgang

Cognitive walkthrough

Brukereval. i laboratorium

Brukerproblemer Design-forbedringer

Gode løsninger


Kvalitetskriterier for evalueringsmetoder

Reliabilitet Validitet Grundighet

Effektivitet (Validitet*Grundighet) Nytte i utviklingsprosessen Kostnadseffektivitet

Oppsummering: I hvilken grad hjelper evalueringsmetoden til med å avdekke og

forstå virkelige brukerproblemer? I hvilken grad bidrar evalueringsmetoden til at man får en mer

effektiv prosess og/eller et bedre produkt?


Metoder iht. kvalitetskriteriene

Høy

Middels

Lav

Lav

Kostnad

Sent

Midt ->

Tidlig ->

Tidlig ->

Når nyttigst?

HøyMiddelsMiddels-Høy

Brukereval. i lab.

Middels-Høy

Middels-Lav

HøyBrukereval. i felt

MiddelsMiddelsMiddelsCognitive walkthrough

Lav-Middels

Høy?LavHeuristisk evaluering

NytteGrundighetValiditet

Reliabilitet og kostnadseffektivitet ikke med i tabellen pga. vanskelig å gjøre generelle vurderinger av dette


SOTA – evaluering av mobil IKT


Empirisk evaluering - Introduksjon av kontekst I lab uten kontekst

I lab med enkel kontekst

I lab med omfattende kontekst

I felt

Antall kosmetiske problem

er

Antall kritiske problemer

Praktiske problem

er

Kjeldskov/Stage, 2004

Kjeldskov/Skov, 2004

Kjeldskov/Skov/Als, 2004

Kostnad


Analytisk evaluering- Sammenligning av metoder Analytiske metoder – ”discount methods” Heuristisk evaluering - problemet med mange ”falske

positiver” Chattratichart/Brodie: Betydningen av å bruke domene-

sentrerte heuristikker* HE Plus overgår HE Markant bedring av effektivitet og reliabilitet

Andre, 2003: Betydningen av å være oppgaveorientert* Teoribaserte metoder (CW) overgår heuristisk evaluering Bedret validitet -> bedret effektivitet

Vetere, 2003: Tilpasning av heuristikker til mobil IKT Heuristic walkthrough

*)Studier gjennomført på stasjonær PC


Effektivisering av analysen

Kostnadseffektivisering gjennom forenkling av analysen Rapid reflection Instant data analysis

Kortvarig brainstorming umiddelbart etter gjennomføring av datainnsamling i evalueringsmetode Liste med usabilityproblemer Mindre spesifikk, mindre omfattende Kan overse kritiske problemer – bør brukes med forsiktighet

Pedell, 2003Kjeldskov, et. al, 2004

inf5120 – modellbasert systemutvikling · telecom and informatics 4 rational for introducing...

Documents