1 / 48

Test af brugeroplevelsen

Test. Test. Test af brugeroplevelsen. Test. Formidling, projektarbejde og webdesign-E2011 Steen Filskov Andersen 25. oktober 2011. Hvorfor brugerteste?. Test. Er der et grundlag for at lave produktet? Hvordan skal produktet laves, så brugerne kan finde ud af at bruge det effektivt?

kaethe
Télécharger la présentation

Test af brugeroplevelsen

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Test Test Test af brugeroplevelsen Test Formidling, projektarbejde og webdesign-E2011 Steen Filskov Andersen 25. oktober 2011

  2. Hvorfor brugerteste? Test • Er der et grundlag for at lave produktet? • Hvordan skal produktet laves, så brugerne kan finde ud af at bruge det effektivt? • Hvad synes brugerne om produktet? Test Test

  3. ”Men jeg ved da godt, hvordan brugerne opfører sig og tænker!”

  4. Nej du gør ikke

  5. Få et realitetstjek

  6. Er det en god idé, at jeg plukker mine bryn væk og tegner nogle nye et sjovt sted? • Vil du ikke komme over og hjælpe mig med at tegne mine nye øjenbryn? • Hvad synes du om det færdige resultat?

  7. Uvildigheden og de friske øjne • Spørg alle! (undtagen din mor) • Hall tests, guerilla tests, spørg-en-ven/-kollega • Brug en ekstern leverandør af usability for at: • Få større gennemslagskraft på direktionsgangen • Spare tid • Teste med de rette brugere • Teste på neutral grund under optimale forhold • Garanteret uvildighed fra testleder under test såvel som undersøgelsesdesign

  8. Formativ eller summativ evaluering • Grundlæggende kan en evaluering have to funktioner, den kan enten være formativ eller summativ. • Formativ: • Evaluerer med henblik på, hvordan man kan videreudvikle produktet før det lanceres. • Man finder ud af, hvor produktet er lige nu. Ud fra resultatet kan man tilrettelægge det fremtidige forløb bedst muligt. • Summativ: • Evaluerer med henblik på at ”opsummere” resultatet af en designproces. • Der fokuseres på, hvad produktet rent faktisk kan i forhold til de mål, der er blevet sat for produktet.

  9. Adfærd og holdning • En ting er, hvad brugerne gør – en anden er hvad de siger. • Hvornår skal man kende brugernes adfærd? • Hvornår skal man kende brugernes holdning?

  10. Målsætning for et system • Kan brugerne løse de relevant opgaver? • Hvor lang tid bruger brugerne på opgaverne? • Hvor mange trin skal brugerne igennem for at løse opgaverne? • Hvor mange fejl laver brugerne undervejs? • Hvor tilfredse er brugerne med systemet?

  11. Koncepttest • Effektive metoder: • Fokusgrupper • 1-til-1 dybdeinterviews • Spørgeskemaer (i kombination med en af ovenstående metoder)

  12. Stimuli til koncepttest

  13. Eksempel på kvantitativ dataindsamling

  14. Prototypetest • Effektive metoder: • 1-til-1 dybdeinterviews • Spørgeskemaer (i kombination med ovenstående metode)

  15. Stimuli til prototypetest

  16. Test af færdigt system • Effektive metoder: • 1-til-1 dybdeinterviews • Spørgeskemaer (i kombination med ovenstående metode eller alene)

  17. www.bravotours.dk

  18. Hurtig øvelse • Scenario: Bravo Tours skal overbevises om, at det er på tide, at de får optimeret deres site for at gøre det mere brugervenligt. • Hvad gør man?

  19. Andre metoder • Kortsortering • Heuristisk inspektion • Eye-tracking test • Workshops

  20. Tænke-højt metoden • Få brugeren til at sætte ord på deres tanker. • Testlederen får derved indsigt i tankeprocesserne bag brugerens handlinger. Aaaargh!

  21. Hurtig øvelse • Løs en opgave på www.bravotours.dk mens du tænker højt. • Hvem har lyst til at prøve?

  22. Den gode spørgeguide 1 • Forklarer, hvad der skal ske. • Får brugeren til at slappe af. • Systemet testes – ikke dig. • Du er eksperten – jeg er her for at lære af dig. • Sætter brugeren i den rette kontekst. • State of mind • Scenario • Indeholder ikke mere end 5-6 opgaver, der skal løses (eller opgives) indenfor 45-60 min.

  23. Den gode spørgeguide 2 • Starter med en nem opgave. • Kan indeholde opfølgende spørgsmål til opgaverne. • Emner, som udviklerne gerne vil have brugernes holdning til • Bruger åbne hv-spørgsmål og et neutralt ordvalg. • Er blevet gennemprøvet ved en pilottest. • Afrunder testen med at brugeren opsummerer sin oplevelse.

  24. Eksempel på spørgeguide

  25. Læg en plan 1 ??? • Hvad skal formålet være med brugertesten? • Hvilken metode skal benyttes? • Hvilke type brugere, vil du benytte - og hvor mange? • Lav en screener til at udvælge brugerne med. • Kontakt evt. et rekrutteringsbureau og overdrag opgaven.

  26. Læg en plan 2 ??? • Hvor i verden skal der testes henne? • Lokalt eller remotely? • Definér et sæt opgaver og lav en spørgeguide. • Skal der indsamles kvantitative data? • Lav et spørgeskema • Kræves der et specielt test-setup? • Usability lab, computerudstyr, optageudstyr, betaling af deltagerne, forplejning, m.m.m.

  27. Læg en plan 3 ??? • Skal der samarbejdes med en eller flere eksterne testledere? • Få feedback på dit materiale fra dem. • Endnu bedre: Bed dem om at lave det hele baseret på dit input. • Afsæt tid i kalenderen til at udføre/overvære testene og sørg for at relevante stakeholders også er klar over tidsplanen. • Sørg for at der er indlagt tid i udviklingen til at rette eventuelle fejl fundet under testene.

  28. Find deltagerne… • Brug dit netværk. • Venner, venners venner • Sociale netværk (on- og offline) • Brug udviklerens netværk. • Der kan være meget specifikke krav • Udviklerens hjemmeside/nyhedsbrev • Rekrutteringsbureauer. • Gaderekruttering. • Vikarbureauer. • Stillingsopslag.

  29. … og beløn dem med • Kontanter (skattefrit) • Gavekort • Produkter fra udviklerens hylder • Vin, øl, pizza • Et knus • Find selv på flere I virkeligheden er det jo for deres eget bedste, så deltagelsen burde være belønning nok! 

  30. Eksempel på screener

  31. Antal testdeltagere • Kvalitativ eller kvantitativ dataindsamling? • Eller lidt af hvert? • 3-5 repræsentanter for hver målgruppe. • 12+ hvis der skal måles på dem. • Vælg kun de primære målgrupper, hvis tid og penge er et problem. • Afgør, hvad der kan have indflydelse på brugernes tilgang til systemet.

  32. Hvad skal du bruge til testen? • Systemet der skal testes • En spørgeguide • En bruger • En testleder (dig selv?) • Hvis nødvendigt: • Skærmoptagesoftware • Webcam og/eller mikrofon + optagefaciliteter • En referent – eller udstyr til at testleder tager noter.

  33. Den gode testleder under testen 1 • Er venlig og imødekommende overfor brugeren. • Forholder sig objektiv og distancerer sig fra brugeren. • Forklarer sin rolle som uvildig part (hvis det er tilfældet). • Stiller ikke-ledende spørgsmål – HV altid HV! • Spørger ind, hvis brugerens handling eller højt-tænkning ikke forstås. • Ved hvornår det er mest optimalt at hjælpe eller afbryde en opgave.

  34. Den gode testleder under testen 2 • Følger med ”bag spejlet” i pauserne og følger op med spørgsmål, som udviklerne diskuterer på baggrund af testene. • Minder brugeren om at blive ved med at tænke højt. • Forstår når brugeren har brug for en pause eller et par opmuntrende ord. • Tager noter med hovedkonklusioner og citater. • Er tålmodig – MEGET tålmodig! – og god til at holde mund.

  35. Gode opfølgende spørgsmål • Hvad tænker du lige nu? • Hvad tror du, at der skete her? • Hvad tror du, at der sker nu? • Hvad forventede du at se her? • Hvad er dit indtryk af…? • Hvorfor klikkede/kiggede/prøvede du…?

  36. Gode noter • Mængden bør svare til den tid, der er til rådighed til analysen af data. • Tydelig angivelse af hvilken session, hvilken bruger, hvilket land, etc. • Begyndende konklusioner formes allerede her. • Tydelig forskel på hvem der siger hvad, det sagte og det usagte og egne kommentarer. • Overvej at samle noter fra alle deltagerne under det relevante spørgsmål og den relevante opgave i spørgeguiden.

  37. FEP – FrequentlyExperienced Problems Som du ikke altid selv er herre over (heldigvis) • Ingen tid til pilottest. • Prototypen er fejlbehæftet. • Eller når ikke at blive færdig. • For korte pauser mellem testene. • Opgaverne der skal løses er ikke passende for de områder, der skal afdækkes i systemet. • Det tekniske udstyr driller. • Deltagerne kommer ikke (på det aftalte tidspunkt) • Deltagerne lever ikke op til kriterierne.

  38. Analysen og præsentationen af data • Brainstorm af positive og negative fund. • Med systemet ved hånden. • Gennemlæsning af noter for at supplere brainstorm. • Formulering af fund i et sprog, der taler til modtagerne og visning af fund på skærmdumps. • Understøt med brugercitater fra noter og/eller video/lydoptagelse. • Overvejelse af anbefalet løsningsforslag , formulering og evt. illustration af dette. • Graduering af problemer. • Kort opsummering til starten af rapporten (til direktionen).

  39. Alvorsgradsskala Katastrofaltbrugervenlighedsproblem – højeste prioritet Det er essentielt at problemet rettes. Stortbrugervenlighedsproblem – høj prioritet Påvirker i høj grad brugervenligheden negativt og forhindrer de fleste brugere i at anvende funktionerne. Moderatbrugervenlighedsproblem – mellem prioritet Påvirker brugervenligheden negativt og kræver en indsats af brugerne for at de kan tilpasse sig - nogle brugere vil ikke kunne. Mindrebrugervenlighedsproblem – lav prioritet Påvirker brugervenligheden negativt men brugerne vil sandsynligvis nemt tilpasse sig. Kosmetiskproblem, der ikke påvirker brugervenligheden Bør rettes hvis tiden tillader det. Positiv brugeroplevelse! Brugerne har en god oplevelse. SnitkerGroup

  40. Typisk indholdsfortegnelse

  41. Eksempel på to slides fra rapport

  42. Make map controls more visible • The majority of the users do not notice (or understand) nor usethe map controls. • The fact that they are in English in the prototype plays a minor rolein this problem. • Zooming in and out is hidden within a drop down menu. Using themouse’s scroll wheel for zooming do not come natural to these users. • The label “Automatic” is confusing for the users. • It is not clear what item is selected in the map control drop down lists. • Controls should be made more intuitive to use and they should standout from the rest of the map. • Labels should be in Danish. • Zoom level should be displayed at all times • Instead of showing the status eg. “Automatic” as a drop down list label considershowing the name of the function eg. “Viev mode”. • Items selected should be clearly highlighted using a check mark, radio button, or similar. • Items that are active and clickable do not convey this to the users when displayed on the map.Some users do not discover them and all users doubt if anything will happen if they click on them. • It is recommended to inspire the users to use the items on the map by the use ofmouse (hover) over text and change of the mouse cursor from a hand to a pointing hand. ”’Se alle’ – det har jeg ingen anelse om hvad er – det konflikter med at der heroppe står ’Vis flere klinikker’.” – Kim, 55 år SnitkerGroup

  43. ”Movia – den er god, fordi den kan man også bruge hvis man går.” – Lene, 60 år Optimize driving directions ”’Kørselsvejledning’ – jeg vil hellere med bussen!” – Kirsten, 65 år • In most cases the users find the driving directions to be confusing and even misleading – not taking the most obvious or direct route between the two points. • Users request that parking areas in near vicinity of the hearing centers are shown on the map. • Many users will prefer to go by bus from their home to ahearing center and this is not supported by the HCL. • Some users find that there are inconsistencies between theroute description and the route displayed on the map. • To some users the route on the map is not displayed at all. • Generally the route description is too detailed to be practical. • In some cases the routing engine is not able to calculate a route at all. • When supplying the users with a navigational tool it is a good idea to offer some of the possibilities available on other sites or devices with the same purpose. • Offer public transport guidelines. • Offer alternative routes. • Let the user chose between shortest, quickest or most economical route – or optimize for driving, biking, and walking. • Optimize the routing engine so it does not annoy the users with downright impractical directions. • Show parking areas in near vicinity of the hearing centers. ”Der mangler jo bussen her.” – Hans Erik, 67 år ”Hvor kan du parkere?” – Kenneth, 57 år ”Afgang fra Snerlevej mod Kløvervej er stærkt misvisende fordi det er en stikvej på en helt anden vej – det er helt i skoven. Den dumper! Og selve ruten den er også tåbelig.” – Kim, 55 år SnitkerGroup

  44. Øvelse – lav en brugertest af jeres portfolie • Opgaven løses i grupper à fire. • Individuelt: Lav en spørgeguide inklusiv en række opgaver, der skal løses på jeres site. • Brug de tre andre i din gruppe som testpersoner og test din portfolie med de tre ”brugere” – en ad gangen. • Brugeren tænker højt undervejs og du tager noter. • Du er selv testleder – det er vigtigt at man kan teste sit ”eget barn”. • Individuelt: Analysér dine noter og sammenfat resultatet af brugertestene i en kort rapport, der illustrerer problemer med brugeroplevelsen og giver forbedringsforslag. • Rapporten lægges ud på dit site (og fejlene på sitet udbedres naturligvis! )

More Related