Observasjonsteknikker - oversikt

Transkript

1 Observasjonsteknikker - oversikt Navn Formål Type data God på Dårlig på Spørreskjema Få svar på spesifikke spørsmål I hovedsak kvantitative Kan nå mange personer Vi må vite hva vi skal spørre om Intervju Utforske. Få innblikk i et tema. Kvalitativt Gi innsikt i et problem. Dialog med bruker. Tar tid, og viser ikke faktisk arbeidskontekst. Fokusgrupper og workshops Dialog med gruppe av brukere Kvalitativt Komme dypt i å forstå et problem. Brukerinvolvering Ressurskrevende. Feltstudie Studie av faktisk brukskontekst Kvalitativt Forstå brukerens faktiske hverdag. Tar tid. Krever ofte tillatelse, f.eks. på sykehus. Brukbarhetstesting. Evaluering av prototyp eller produkt Kvalitativt og kvantitativt Evaluere brukskvalitet av prototyp/produkt. Krever at man har prototyp. Skjer ikke i faktisk kontekst. Logging av bruk Evaluering av faktisk bruk Kvantitativt Faktisk bruk. Mange personer. Gir ikke innsyn i årsaker til problemer.

3 Intervju Utvelgelse av intervjuobjekter Typer av intervju: Strukturert intervju Semi-strukturert intervju Åpent intervju Intervju-guide Datainnsamlingsteknikker Analyse av intervjuet

4 Eksempel intervjuguide (1) Oppfattet nytte Hvor ofte benytter du tjenesten? I hvilke situasjoner får du bruk for tjenesten? Fordeler med å bruke tjenesten Ulemper ved å bruke tjenesten Hvordan bør tjenesten ideelt være? Oppfattet brukervennlighet Noen svakheter/mangler? Stopper du opp noen steder? Er alle navnene intuitive? Support? Lett og komme i gang med tjenesten? Tilfredsstillende, liker og bruke systemet?

5 Eksempel intervjuguide (2) Sikkerhet og trygghet Sikkerhet er en viktig ting når det gjelder pasientjournaler og opplysninger? Trygg på at informasjonen kommer til rette personer og bare rette personer? Relevante funksjoner Lett å bestille tjenesten Oppkobling Support Tid brukt for å utføre bestemte oppgaver Hvor lang tid bruker du på en gitt oppgave(ulike oppgaver listes opp) Effektivt å bruke, oppnå et høyt produksjonsnivå Tilgjenglighet Lettere å være tilgjenglig nå enn før? Integrasjon med andre IT-systemer Lett og overføre meldinger inn i journalene? Endre notater Arkivering Match med eksisterende arbeidspraksis Hvordan jobbsituasjon var før og er nå Brukte du Post-it lapper, notisbøker? Hvordan ble beskjeder gitt innad på kontoret? Registrerer dere mer nå enn før? Enklere/vanskeligere og holde styr på beskjeder/notater? Hvem tar ansvaret for mottak av meldinger

7 Feltstudie Hva er vi interessert i å vite mer om? Hvor skal vi observere? Når skal vi observere? Hva skal vi ha fokus på? Hvordan skal vi gjøre datainnsamlingen? Hvordan skal vi tolke dataene?

8 Observasjonsrapport Oppsummering av observasjon og intervju i forhold til bruk og behov. Hvem er brukeren? Hva holder de på med ( tasks )? Hvilken eksisterende teknologi inngår? Scenarier. Forståelse av rammebetingelser, bedriftskultur og praksis.

9 Usability --> Actual security Research question: Does [bad] usability affect the actual level of security in a hospital setting?

10 Case study: Login Login at a large hospital The study was done over a period of three weeks in a medium size ward with 21 patient beds. Smartcard used both for login both on PCs and for door etc. Two-three levels of login: Windows + portal + system.

11 Login: observations Average login time was 1 minute and 11 seconds. In 23% of the observed login sessions the user left the PC unattended while being logged in. Users found the existing login very cumbersome.

12 What is context-of-use for nurses and doctors? Four medical students studying use of IT in a hospital over a period of three weeks.

13 Physicians: Heterogeneous context-of-use 29,6 24,5 Physicians, info. retrieval (N=311) 28,4 24,1 21,6 Physicians, registration (N=102) 14,1 11,5 12,7 9,3 8,7 10,8 1 Pre-pre rounds Office work Ward round Discharge Silent pre rounds meeting Nurses: Pre rounds meeting 79,6 95,7 Nurses, info. retrieval (N=49) Nurses, registration (N=47) 12,2 2,1 8,1 2,1 Med.adm. Pre rounds meeting Handover/report

15 Fokusgrupper og workshops Samle et antall brukere for noen timer eller en hel dag. Gå igjennom systemene og få tilbakemeldinger. Viktig: Ha en detaljert plan klar på forhånd over hva som skal skje. Ha også en plan B i nødfall.

17 Spørreskjemaer Identifiser brukergruppen. Bruk tid på å lage et godt skjema. Ta gjerne utgangspunkt i f.eks. skjemaet i læreboka. Bruk tid på å analysere resultatet. Gjør helst noe intervju og observasjon først for å unngå hull i spørreundersøkelsen.

18 Eksempel

19 Velg en, fritt valg

20 Likert skala

22 Brukbarhetstesting: Ifg. ISO13407: " to ensure that the delivered product reaches a minimum required level of usability, to provide feedback during the design on the extent to which the objectives are being met, and to identify potential usability defects in the product". European Usability Support Centers

23 Brukbarhetslaboratoriet:

24 Ulike typer av brukbarhetstester Utforskende tester (kvalitativ) Brukes på et tidlig stadium for å vurdere effektiviteten av tidlige modeller (designets "høyere" nivå) Vurderingstester (kvalitativ og kvantitativ) Den vanligste formen for brukbarhetstester. Gjennomføres tidlig eller midtveis i designprosessen. Verifiseringstester (kvantitativ) Objektiv sertifisering av produktets brukbarhet

26 Logging av bruk Krever en installasjon med automatisk logging. Genererer anonymiserte loggdata. Krever analyseverktøy for å se sammenhenger. Kan gi viktig feedback på en tidlig versjon av et system.

27 Cultural probes - recruiting

28 Cultural probes the probe

29 Cultural probes - results

30 Cultural probes analysing results

31 Brukersentrerte metoder og teknikker Analyse og scenariebygging! Kravanalyse! Krav! Design and! Prototyping! Scenarier og personas! Lyd, bilde,! video, tekst! Hos utvikler! I felt eller lab! Prototyper! Papir, Flash,,! Testrapport! Feltstudier! og intervjuer! Brukbarhets-! testing!

32 Brukersentrerte metoder og teknikker Analyse og scenariebygging! Kravanalyse! Krav! Design and! Prototyping! Scenarier og personas! Lyd, bilde,! video, tekst! Hos utvikler! I felt eller lab! Prototyper! Papir, Flash,,! Testrapport! Feltstudier! og intervjuer! Brukbarhets-! testing!

33 Kriterier for valg av metode Fase i prosjektet (tidlig, midt, sent) Velkjent type prosjekt vs. nytt og uprøvd. Antall brukere og installasjoner. Kritiske grensesnitt? (for eksempel sykehus og romfart). Totalbudsjett for prosjekt og budsjett for evaluering. Tid tilgjengelig (kalendertid og persontid). Erfaringsnivå i utviklingsteamet.

34 Fase i prosjektet Tidlig, f.eks.: Feltstudier og spørreskjemaer Intervjuer og fokusgrupper Midt, f.eks.: Papirprototyper m/ Wizard of Oz tester Kjørende prototyper m/brukbarhetstester Ekspertgjennomganger Sent, f.eks.: Felttester Akseptansetest Logging av bruk, intervjuer, online hjelp.

35 Velkjent type prosjekt vs. nytt Velkjent: Standardiserte tester. Veletablert hvem som er brukere Ny type produkt Åpent i forhold til brukere og bruk Mer utforskende tester Mer intervju og feltstudier

36 Antall brukere og installasjoner. Mange brukere: Viktig å få oversikt over brukergruppene. Spørreskjemaer. Brukbarhetstest med representative brukere. Få brukere: Observasjon, fokusgrupper og tester. Direkte dialog med brukere, og større mulighet for å involvere de aktivt i utviklingsprosessen.

37 Kritiske grensesnitt Eksempler: Sykehus, Prosesser i industri, El. nettet, telenettet. Krever: Omfattende tester av kritiske deler av grensesnittet. Analyse av risiko ved operatørfeil, og allokering av ressurser tilsvarende. Dyp forståelse av arbeidsprosess og mulige feilsituasjoner. Utstrakt bruk av scenarie (daglig drift + worst case ).

38 Totalbudsjett for prosjekt og budsjett for evaluering. Mye penger: Kombiner mange metoder for å kunne få verifisert funn via mange kanaler (s.k. metodetriangulering ). Planlegg evalueringer som en integrert del av utviklingsprosessen. Lite penger: Sørg for et minimum av intervjuer, papairprototyping og wizard-of-oz tester. Fokuser på å identifisere brukersentrerte aktiviteter som gir mest uttelling i forhold til en risikoanalyse av prosjektet.

39 Tid tilgjengelig (kalendertid og Kalendertid: persontid) God tid: Planlegg inn flere iterasjoner og bruk flere metoder. Kort time-to-market : Gjør en risikoanalyse og planlegg deretter. Persontid: Mye ressurser: Gjør flere ting samtidig (intervjuer, observasjon, spørreskjemaer) Lite ressurser: Prioriter utifra prosjektets egenart.

40 Erfaringsnivå i utviklingsteamet Mye erfaring: Åpner for et spektrum av metoder. Lite erfaring: Bruk tid på å lære noen grunnleggende metoder som intervjuteknikk, observasjon med video, papirprototyping og enkel brukbarhetstesting.

41 Storebrand.no Eksempel på brukersentrert design Netlife Research 2007

42 Prototype under stadig endring

43 4 brukertester Arvid Arnøen Når jeg bare skal surfe rundt og sjekke pris så vil jeg ikke legge igjen fødselsnummeret mitt Dette er typisk bank og forsikring! Endringer underveis: 1. Fødselsnummer fjernes 2. Forsikringsspråket blir forenklet 3. Hjelpetekster legges inn 4. Spørsmål kuttes maksimalt Bente Riber Moe Dette var en veldig fin løsning det var nesten som et spill! Til meg som er så lite erfaring på internett så var dette veldig lett! Copyright NetLife Research

44 Prototype som arbeidsverktøy

45 Ikoner

46 Ikoner og funksjonalitet

47 RESULTATER

48 Det funker!

49 Resultat Mål for 2007: kunder ble nådd allerede 1.august 60% av salget skjer på via Internettsidene Brukersupport nesten lik 0 Flere online kunder over 90 år 40% av salget skjer utenfor normal kontortid (16:00) Konverteringsrate mer enn dobbelt så høy som andre sammenlignbare selskaper

50 Hei! Vil bare si at jeg akkurat byttet forsikring og det var jo utrolig enkel prosess. Nettsidene var kjempeoversiktlige og det hele tok kort tid. Kundene er kjempefornøyde Hei! Vil bare si meg 100% fornøyd med både dekninger, pris og teknisk løsning da jeg for 5 min. siden overførte mine skadeforsikringer til Deres selskap over nettet. Det tok meg 10 minutter, og jeg sparte ca 40% - slå den!!!!

51 Moot: En mobil P2P tjeneste Basert på WLAN på mobil I nært samarbeid med Ground Control Labs (Telenor offspring) Moot tilbyr: Liste over andre brukere Deling av musikk og bilder Tilpasning av grensesnitt Avspilling av musikk Hovedoppgave: Viktoria Gulliksen 2007.

52 Test 1: Desktop test Demografisk spørreskjema Tradisjonell brukbarhetstest SUS Semistrukturert intervju Spørreskjema om nytteverdi Test 2: Fullskala test Kafétest Fokusgruppe Forskningsplan

53 Desktop test 10 personer (studenter) 9 oppgaver i Moot Software speiling + video Funn: Gjennomsnittlig gjennomføringsgrad SUS score

54 Kafétest 8 testpersoner i en kafé setup: 8 Mobiltelefoner med Moot installert 7 av de speiler i sann tid 2 kameraer i taket, 1 DV-kamera plassert på hylle 3 mikrofoner limt fast til bordene Lekepenger 3 bord, 8 stoler og en bardisk Kopper, tallerkener, glass og stearinlys Kaffe, te, saft, smultringer og kjeks

55 Kafétest: Mikset video fra testen

56 Fokusgruppe: Temaer Temaer som dukket opp i fokusgruppen: Brukssammenheng Oppmerksomhet og tid Målgruppe Pris Rekkevidde Musikkrettigheter Sikkerhet og privatliv Personalisering Brukergrensesnitt

57 Suksessfaktorer Oppsummering av intervjuer og fokusgruppe: Oppfattet nytte Oppfattet brukervennlighet Gunstige forhold Oppfattet lovlighet Oppfattet trygghet Oppfattet kritisk masse Pris Personalisering

58 Kombiner desktop-tester og fullskalatester Desktop-tester gir detaljer om selve brukergrensensittet Fullskalatester gir mer detaljer om faktisk bruk.

59 Test av Healthcom Doctor Tjeneste på mobiltelefon for leger. Tilbyr mulighet for å lage journalnotater i felten. Integrert med journalsystemer på legekontor. Test i samarbeid med Healthcom Hovedoppgave: Ida Sørensen 2008

60 Test av Healthcom Doctor

61 Forskningsplan 1. Feltstudie Observasjon av leger som bruker systemet Semistrukturert intervju SUS Spørreskjema om nytteverdi 2. Brukertest Brukertest i NSEP lab SUS Semistrukturert intervju Spørreskjema om nytteverdi

62 Metodesammenligning

63 Metodesammenligning

64 Bruker-sentrert design og RUP RUP oversikt Use-case vs. scenarier Arkitektur vs. konseptuelle modeller Testing vs. Brukbarhetstesting

65 RUP oversikt Rational Unified Process (RUP)! Verktøystøtte! UML modeller! Implementasjon!

66 RUP arbeidsflyt og faser Arbeidsflyt:! Faser:! Inception Elaboration Construction Transition! Businessmodelling! Requirements! Analysis & Design! Implementation! Test! Iterative prosesser. Tilpasset hvert prosjekt.!

67 Use-case og flow-of-events Student! Registrere bruker! Brukerdatabase! Flow of events! Systemanvarlig! Lese mail! Slette bruker! Slette bruker:! 1. Logge inn.! 2. Hent fram bruker.! 3. Ta nødvendig backup! 4. Slette fra base! 5. Logge ut.!

68 Use-case vs. Scenarier Et use-case med flow of events kan utvides i detaljrikdom til å bli et scenarie med en storyboard. UML mangler kontekstinformasjon og mulighet til å være konkret. Scenarier med brukerkarakterer og storyboarding gjør use-casene lettere å kommunisere til bruker, og gir et rikere bilde. Teknikken lar seg greit integrere i RUP.

69 Arkitektur- vs. konseptuell modell Arkitekturer beskrives i RUP v.h.a UMLs klasser, objekter, etc. Denne formalismen lar seg benytte til å utrykke den modellen bruker skal behøve å forstå. En slik formalisert konseptuell modell har store likhettrekk med business modeller og domenemodeller. RUP har formelt apparat til å håndtere det meste av dette. Resten må skje med prosa.

70 Testing vs. brukbarhetstesting Test begrepet i RUP er knyttet til tekniske tester av funksjonalitet. RUP har i utgangspunktet ikke plass til iterative løkker tidlig som gjør brukbarhetstester direkte mot sluttbruker v.h.a. billige prototyper. Dette kan sees på som en del av teknikker som benyttes i requirements. RUP er svak på dette. Preges av Software Engineering, men er på vei mot User- Centered Design i RUP 2000.