Kursusgang 2 Oversigt Sidste kursusgang Opgaver Interaktionsdesign Identificering

Kursusgang 2 Oversigt: • Sidste kursusgang • • Opgaver Interaktionsdesign Identificering af behov Formulering af krav DIEB 1

Sidste kursusgang Oversigt: • Kurset • Interaktionsdesign • Mål for interaktionsdesign • Principper for interaktionsdesign DIEB HCI disciplinen Hvorfor er HCI design vigtigt? Formål, indhold og evaluering Fra computere til interaktive produkter Godt og dårligt design Hvad er interaktionsdesign Brugbarhed (usability) Oplevelse (user experience) Affordance (visibility og constraints) Consistency Mapping Feedback 2

Opgave 1: Prioriter mål for interaktionsdesign Meget vigtigt Usability Vigtigt Mindre vigtigt Irrelevant Effectiveness Efficiency Safety Utility Learnability Memorability Experience Satisfying Enjoyable Fun Entertaining Helpful Motivating Aesthetically pleasing Supportive of creativity Rewarding Emotionally fulfilling DIEB 3

Opgave 2: Elektronisk patientjournal • Relation til de 4 design principper • • Affordance Mapping Consistency Feedback DIEB 4

Opgave 3: Autopilot DIEB 5

Opgave 4: Placering af motorinstrumenter Alternativ DIEB 6

Kursusgang 2 Oversigt: • Interaktionsdesign • • Fire centrale spørgsmål Aktiviteter Udgangspunkt og resultat Identificering af behov Formulering af krav DIEB 7

Interaktionsdesign: Fire centrale spørgsmål 1. Hvem er brugerne? 2. Hvad er behov? (senere i denne lektion) 3. Hvordan genereres alternative design? 4. Hvordan vælges mellem alternativer? (lektionerne om prototyping, user centred design og usability evaluering) DIEB 8

1. Hvem er brugerne? • • Klassisk tilgang til definition: stakeholder analyse Eksempel: Reservationssystem til flyselskab • Primære stakeholders: ansatte i rejsebureauer, ansatte i flyselskabets booking afdeling Sekundære stakeholders: kunder, flyselskabets ledelse Tertiære stakeholders: konkurrenter, luftfartsmyndigheder, kunders rejsepartnenre, flyselskabets aktionærer Faciliterende stakeholders: design team, ansatte i IT afdelingen Vi er mest interesserede i primære og sekundære stakeholders DIEB • • • Hvordan hænger stakeholders sammen med aktører i OOA&D? Hvor beskrives de? Del af A i systemdefinitionen 9

3. Hvordan genereres alternative design? • • • Umuligt at lave metode for "To get a good idea, get lots of ideas" (Rettig, 1994) Vigtige teknikker: DIEB Brainstorming Tænke i analogier Brug af checklister 10

Interaktionsdesign: Aktiviteter • • Fire grundlæggende aktiviteter i interaktionsdesign Grundbevægelse og sammenhænge mellem aktiviteterne Udgangspunkt Identificer behov Etabler krav Generer design Evaluer design Byg interaktiv version DIEB Resultat: Endeligt produkt 11

Interaktionsdesign: Udgangspunkt og resultat • Udgangspunkt: Analyseresultater fra OOA&D Hvem: aktørtabel Hvad: klassediagram og funktionsliste Hvordan: brugsmønstre • Interaktionsdesign: de 4 aktiviteter • Resultat: et evalueret design af brugergrænsefladen DIEB 12

Kursusgang 2 Oversigt: • Interaktionsdesign • Identificering af behov • Formulering af krav Udgangspunkt Identificer behov Etabler krav Hvad er "behov" Interview Generer design Evaluer design Byg interaktiv version DIEB Resultat: Endeligt produkt 13

Hvad er behov? • • Kan vi ikke bare spørge brugerne hvad de vil have? Kan vi ikke bare observere den aktivitet, som systemet skal understøtte? … nej, for • Brugerne kan ofte ikke udtrykke hvad de vil have Eksempel: var det første tekstbehandlingssystem "bare" en computer baseret skrivemaskine • Tit har vi ikke adgang til brugerne Eksempel: en ny type mobiltelefon • Et system understøtter ikke altid en eksisterende aktivitet Eksempel: regneark, mobiltelefon, PDA • Balance: Tradition Û Nyskabelse DIEB 14

Interviewteknikker Interview: • Teknik til indsamling af viden om brugeres behov i relation til et system • Ustruktureret: intervieweren stiller de spørgsmål, som forekommer relevante ud fra interviewpersonens svar Styrke: relevans og fleksibilitet • Struktureret: Intervieweren har en liste med forberedte spørgsmål, som stilles uafhængigt af interviewpersonens svar Styrke: systematik og komplethed • Top down eller Bottom up DIEB I projektarbejdet: • Fokuser på primære stakeholders • Udvælg så vidt muligt 2 3 kommende brugere • Forbered nogle spørgsmål på forhånd (struktureret) men vær åben over for ting I ikke har overvejet (ustruktureret) • 2 3 medlemmer af gruppen laver interviewet • 1 medlem er interviewer Denne person stiller de forberedte spørgsmål og noterer undervejs ideer til yderligere spørgsmål 2 medlemmer tager notater De stiller supplerende spørgsmål til sidst Interviewpersonen orienteres fra starten om dette forløb 15

Spørgsmål til interview • • • Få overblik over helheden af arbejdsprocesser i anvendelsesområdet "Kan du fortælle hvad hele virksomheden laver" Få indblik i anvendelsesområdets struktur, for eksempel afdelinger, ansvarsområder, grupper og lignende "Hvilke afdelinger eller ansvarsområder findes der i virksomheden" Få interviewpersonen lokaliseret "Hvilken afdeling/ansvarsområde/gruppe er du i" Få indblik i sammenhænge med andre dele "Hvilke andre afdelinger arbejder du mest sammen med" n w o D p To Få en detaljeret forståelse af den arbejdsproces, interviewpersonen udfører "Hvad er dine arbejdsopgaver" "Kan du beskrive hvordan du udfører hver af dem" Forsøg først at forstå standardforløbet i den enkelte arbejdsopgave og gå først derefter ind på afvigelser og undtagelser DIEB p U m o t t Bo 16

Kursusgang 2 Oversigt: • Interaktionsdesign • • Udgangspunkt Identificering af behov Formulering af krav DIEB Grundbegreb Personas Scenarier Brugsmønstre Identificer behov Etabler krav Generer design Evaluer design Byg interaktiv version Resultat: Endeligt produkt 17

Formulering af krav • • Krav: et udsagn om om et påtænkt produkt, som specificerer, hvad det skal gøre eller hvordan det skal performe Dilemma: På den ene side vil vi gerne forsøge at indsamle meget information, før vi nedskriver detaljerede krav til systemet På den anden side kan vi kun indsamle information, hvis vi har et relevanskriterium (så vi ved, hvad vi skal kigge efter) • • Løsning: Vi samler information og formulerer krav gradvist 1. trin er at afgrænse: • 2. trin er at præcisere • OOA&D: systemdefinition (1) og analysedokument (2) DIEB hvem er brugerne: personas hvilke aktiviteter skal systemet understøtte: scenarier hvordan skal brugerne anvende systemet i disse aktiviteter: brugsmønstre 18

Personas og scenarier: Kilde Alan Cooper and Paul Saffo. The Inmates are Running the Asylum. Simon and Schuster. 1999. Grundide: at "tvinge" designere til at tænke på brugerne og deres aktiviteter, når de specificerer krav (så kravene ikke kun bliver tekniske) Hvorfor er det nødvendigt? DIEB 19

- fordi systemudviklere ofte ikke forstår brugerne og deres aktiviteter • • • Jeg har brug for hjælp til at udfylde min SU ansøgning Vi starter på Aalborg Universitets web sted: Vi finder aldrig den nødvendige hjælp; kun samlinger af regler og bestemmelser DIEB 20

Personas • • En ny teknik til identificering af typiske brugere (primære stakeholders) En persona er en fiktiv person, der kunne være en typisk bruger af systemet En persona bygger på data fra mange brugere. Disse kan indsamles fra mange kilder: markedsundersøgelser, spørgeskemaundersøgelser og interviews med kommende brugere. En persona er en konkret beskrivelse af en bruger med navn og alder, der sætter designgruppen i stand til at danne sig et billede af brugeren. Ofte er der et billede knyttet til beskrivelsen. • • DIEB Kira er 15 år og går i 9. a. Hun er belæst og klog, men hun har det med at dagdrømme og lade sig rive væk. Hun laver mange sjove ting med vennerne, men hendes store passion er: chokoladekager. Almindelig mad skal helst være lige det, hun har lyst til, og det skal være lækkert, for hun er lidt kræsen. Man kan overhovedet ikke se på hendes lange tynde krop, at hun bager og fortærer de skønneste kager. Gregers Petersen og Lene Nielsen, Institut for Informatik, Handelshøjskolen i København. Juli 2004 http: //design. emu. dk/artik/04/31 brugerdesign. html 21

Personas: Eksempel (1) DIEB 22

Personas: Eksempel (2) DIEB 23

Scenarier • • Et scenarium er en beskrivelse af en menneskelig aktivitet. Den omfatter ikke nødvendigvis brug af teknologi Tommelfingerregler: • Tænk på scenarierne som en "proces", der udføres af en persona Scenarier skal indfange den virkelige kontekst for brugen af systemet (problemområde og anvendelsesområde) Beskriver trin for trin men overordnet hvad brugeren gør • • Fokuser på det daglige arbejde Læg vægt på bredde frem for dybde DIEB 24

Scenarier: Eksempel Brugeren indtaster navnene på alle mødedeltagere sammen med begrænsninger såsom mødets varighed, omtrentligt tidspunkt og stedet hvor det skal foregå. Systemet checker så i forhold til de individuelle kalendere og den centrale afdelingskalender. Brugeren præsenteres for en serie af mulige datoer, hvor alle er tilgængelige på samme tid. Derefter kan mødetidspunktet vælges, og det skrives ind i deltagernes individuelle kalendere. Dog vil nogle personer ønske at blive spurgt, før tidspunktet lægges fast. Systemet kunne måske automatisk sende dem en email, hvor de bedes om at bekræfte aftalen, før den lægges fast. (PRS, p. 224) DIEB 25

Brugsmønstre • I mange år var beskrivelse af behov baseret på en analyse af eksisterende arbejdsgange, som skulle automatiseres Eksempel: SA/SD • Brugsmønstre blev "opfundet" som et redskab til at beskrive brugen af systemer, hvor der ikke var et eksisterende manuelt system Ivar Jacobson: OOSE (1992) Arbejdede for Ericsson med udvikling af software til apparater • • DIEB 26

Brugsmønstre til interaktionsdesign • I OOA&D laves der to slags beskrivelser af brugsmønstre: • • • Brugsmønsterspecifikation Tilstandsdiagram for et brugsmønster I SAD kurset lærer I at lave brugsmønstre (kapitel 6) De specificerer krav til brugen af systemet I DIEB kurset skal vi bruge dem som grundlag for design af brugergrænsefladen DIEB 27

Essential Use Case • • Indeholder det samme som et brugsmønster Adskiller aktør(er) og system DIEB 28

Dekomponering af opgaver: Hierarkisk opgaveanalyse • • Klassisk teknik til detaljeret analyse af en arbejdsopgave Fokus på handling gennem begrebet opgave (task) En opgave deles op i mindre (del)opgaver i en hierarkisk struktur Kaldes Hierarchical Task Analysis (HTA) Delopgaverne på et niveau udføres i sekvens En plan beskriver strukturen i udførelsen på et givet niveau Planen kan benytte forskellige kontrolstrukturer DIEB A E B C F G D 29

Eksempel: Telavning (figur 15. 4 i Dix) Kontrolstrukturer: • • DIEB sekvens: plan 3 selektion (optional): plan 0 – "if …" venter: plan 0 og plan 1 repetition (cycles): plan 5 parallelitet: task 1 og task 2 valgfrihed (discretionary): rum kan støvsuges i valgfri rækkefølge kombinering af flere kontrolstrukturer 30

Eksempel: Kontanthævning • • Plan 0: Udfør 1 2 Hvis koden godkendes udfør 3 Plan 3: Gentag 3. 1 3. 2 indtil transaktion godkendes Hvilke af handlingerne kan vi iagttage for en konkret bruger? Blade kontra indre knuder i træet DIEB 0. Hæv kontanter 1. Indsæt kort i automaten 2. Indtast kode 3. Udfør hævning 3. 1 Vælg beløbs størrelse 3. 2 Godkend transaktion 31

Næste gang • • • Forståelse og modellering af interaktion Begrebsmæssige modeller og dialogformer Fra OOA til interaktionsrum DIEB 32