Krav til brugervenlighed

Transkript

1 Sådan skriver du Krav til brugervenlighed Med eksempler fra Rejsekort 18 januar 2013 Udarbejdet af DialogDesign ved Rolf Molich, Skovkrogen 3, 3660 Stenløse, Danmark

2 Januar 2013 Udarbejdet af DialogDesign, Side 2

3 Indhold 1. Formålet med denne vejledning Baggrund Bidragydere Formålet med usability krav Udarbejdelse af en usability kravspecifikation Anvendelse af en usability kravspecifikation Typer af usability krav Andre typer af krav Krav til udviklingsproces Usability test Krav til produkt Krav til nytte Krav til effektivitet Krav til tilfredshed Gode råd Klassiske fejl Krav til usability kompetence Yderligere information Eksempler Grundlæggende model for brug af Rejsekort Anvendte konventioner Appendiks A. Eksempler på krav til udviklingsproces A.1. Planlægning A.2. Analyse A.3. Brugerkrav A.4. Design A.5. Vurdering Appendiks B. Eksempler på krav til produkt B.1. Eksempler på krav til nytte...33 B.2. Eksempler på krav til effektivitet B.3. Eksempler på krav til tilfredshed Appendiks C. Supplerende oplysninger C.1. Kerneopgaver C.2. Testdeltagere til usability test Januar 2013 Udarbejdet af DialogDesign, Side 3

4 Hvis du er ligeglad med kvalitet, så er dit arbejde trivielt -- Gerald M. Weinberg Januar 2013 Udarbejdet af DialogDesign, Side 4

5 1. Formålet med denne vejledning Denne vejledning forklarer, hvad en præcis kravspecifikation for usability (brugervenlighed) for et it-system bør indeholde. En usability kravspecifikation er normalt en del af en kravspecifikation for et it-system. Den komplette kravspecifikation for et produkt indeholder mange andre typer krav, f.eks. funktionelle krav, proceskrav, forretningsmæssige krav, sikkerhedskrav og kvalitetskrav. Vejledningen henvender sig til personer, som udarbejder kravspecifikationer for interaktive it-systemer. Usability kravspecifikationen kan anvendes i en vilkårlig brugercentreret udviklingsmetode. Vejledningen består af en generel vejledning i afsnit 2-7 efterfulgt af konkrete eksempler i afsnit 8 og appendiks A og B. Eksemplerne bygger på Rejsekort. Appendiks A viser konkrete krav, som kunne sikre at usability bliver tilgodeset i udviklingsprocessen for Rejsekort. Appendiks B viser konkrete usability krav, som rejsende kunne stille til Rejsekort. En usability kravspecifikation fastlægger krav til udviklingsprocessen og/eller krav til selve it-systemets brugergrænseflade i form af krav til nytte, effektivitet og tilfredshed for relevante brugere i en relevant sammenhæng. Tidlige diskussioner af kravene kan afsløre misforståelser og uoverensstemmelser tidligt i udviklingsforløbet, hvor problemerne er nemme at rette. En god usability kravspecifikation yder populært sagt en vis sikkerhed mod, at kunden kommer i kløerne på en leverandør, som ikke magter usability opgaven. Opfyldelse af kravspecifikationen bør være en forudsætning for, at leverandøren får den aftalte betaling for sin leverance. Derfor skal kravspecifikationen være præcis. For hvert krav skal en neutral person, f.eks. en dommer eller en voldgiftsmand, klart kunne afgøre, om kravet er opfyldt eller ej. En usability kravspecifikation kan naturligvis også anvendes internt i et firma til at synliggøre aftaler om usability mellem brugere og udviklingsteamet Baggrund Mine erfaringer fra mange års arbejde for kunder viser, at kendskabet til hvordan man opstiller præcise, målelige krav til usability (brugervenlighed) er begrænset. Mine erfaringer viser desuden, at det kræver indsigt at omsætte begrebet "usability" til præcise usability krav Bidragydere Jeg takker følgende personer for værdifulde kommentarer til tidligere udkast: Søren Lauesen (ITU), Anker Helms Jørgensen (ITU), Peter Carstensen (Alexandra Instituttet) og Jan Chr. Clausen (Nykredit). Ophavsretten til dette dokument tilhører DialogDesign, Du er velkommen til at kopiere dette dokument, også i uddrag. Ved kopiering skal du angive, at teksten stammer fra dokumentet "Usability kravspecifikation", som er udarbejdet af DialogDesign. Januar 2013 Udarbejdet af DialogDesign, Side 5

6 Din kravspecifikation skal være så robust, at du fortsat er situationens herre, hvis leverandøren mister lysten til at samarbejde konstruktivt efter at have fået ordren -- Rolf Molich Januar 2013 Udarbejdet af DialogDesign, Side 6

7 2. Formålet med usability krav Usability kravspecifikationen bruges som bilag til en udviklingskontrakt. Kontrakten indgås mellem to parter: en leverandør, som skal leve op til kravene, og en kunde, som ønsker en række usability krav opfyldt for at sikre, at brugere kan finde ud af at bruge itsystemet Udarbejdelse af en usability kravspecifikation Usability krav indgår normalt i en kravspecifikation, som også stiller krav til materiel, funktionalitet, pålidelighed, sikkerhed og meget andet. Usability kravene udarbejdes normalt af kunden sammen med de øvrige krav. I praksis er det kundens egne usability specialister, som udarbejder kravene, eller kunden benytter sig af ekstern konsulentbistand. Usability krav udarbejdes med henblik på bestemte målgrupper. Forskellige målgrupper kan have vidt forskellige krav til det samme system. Leverandøren tager hensyn til kravene, når han udarbejder tilbud. Kravene forhandles ofte mellem kunde og leverandør, indtil der er nået et kompromis mellem kvalitet og pris, som begge parter finder acceptabelt. Usability krav kan være ressourcekrævende at teste, fordi de ofte involverer et større antal typiske brugere, de såkaldte testdeltagere. F.eks. kan en test med 100 testdeltagere kræve mange ressourcer. En test med 10 testdeltagere er væsentlig billigere men øger risikoen for, at et par atypiske testdeltagere giver et ukorrekt resultat. Kunde og leverandør må på forhånd afgøre, om testen er pengene værd. En seriøs leverandør kan beregne et højt risikotillæg for at opfylde krav, som er kostbare at efterprøve, eller som leverandøren ikke er helt sikker på, at han kan opfylde Opstilling af usability krav Jeg anbefaler følgende fremgangsmåde for opstilling af konkrete usability krav: 1. Arranger en workshop med en varighed på 2-3 timer. 2. Indbyd op til 12 personer: a. Projektejeren b. Projektlederen og hans/hendes stedfortræder c. Et par repræsentative brugere d. Interessenter, dvs. repræsentanter for grupper, hvis daglige arbejde påvirkes af det nye it-system. For Rejsekort systemet kunne det være togførere, togrevisorer, billetsælgere og supportpersonale. e. En eller to udviklere f. En eller to usability specialister som har erfaring i opstilling af usability krav. De officielle titelbetegnelser er "usability engineer" og "usability requirements engineer" g. En ordstyrer, som ikke har nogen særlige interesser i projektet, dvs. hverken er interessent eller udvikler. Ordstyreren kan også være referent. 3. Start mødet med at lade en usability specialist forklare reglerne for usability krav 4. Brainstorm forslag til målgrupper. Januar 2013 Udarbejdet af DialogDesign, Side 7

8 5. Brainstorm forslag til de vigtigste arbejdsopgaver, de såkaldte kerneopgaver. Gør dette også selv om udviklerne allerede har opstillet en liste med kerneopgaver. 6. Brainstorm usability krav til hver kerneopgave og målgruppe. 7. Prioriter kravene under hensyntagen til at det næppe er realistisk at have mere end krav i usability delen af kravspecifikationen. 8. Efter workshoppen formulerer referenten de krav, som workshoppen nåede frem til, og udsender dem til workshopdeltagerne til kommentering. 9. Deltagerne kommenterer de nedskrevne krav. 10. Referenten reviderer kravene på grundlag af deltagernes kommentarer. Hvis der er væsentlig uenighed mellem workshopdeltagerne, træffer projektejeren en beslutning eller indkalder til et møde med henblik på at diskutere uenighederne og opnå større forståelse af problemerne. 11. Deltagerne godkender usability kravene Anvendelse af en usability kravspecifikation Kunden kan stille krav om en tidlig, forebyggende kontrol af, om usability kravene ser ud til at kunne opfyldes ("early proof of concept"). En tidlig kontrol er ofte knyttet til en mulighed for at opsige kontrakten. Når leverandøren mener, at systemet er færdigt, afholdes en afleveringsforretning, hvor kunden og leverandøren i fællesskab gennemgår systemet med udgangspunkt i de aftalte krav. For hvert krav undersøges, om kravet er opfyldt, delvis opfyldt eller ikke opfyldt. På baggrund af afleveringsforretningen afgør kunden, om han vil acceptere systemet. Hvis systemet ikke lever op til de aftalte krav, skal leverandøren ændre systemet, så det lever op til kravene. Det sker normalt for leverandørens egen regning. Hvis det efter forhandlinger og et rimeligt antal forsøg viser sig, at leverandøren ikke kan leve op til usability kravene, kan kunden opsige aftalen. Januar 2013 Udarbejdet af DialogDesign, Side 8

9 Januar 2013 Udarbejdet af DialogDesign, Side 9

10 Brugere mener, at brugergrænsefladen ER systemet. Hvis brugerne ikke kan finde ud af det, så virker det ikke -- Susan Dray Januar 2013 Udarbejdet af DialogDesign, Side 10

11 3. Typer af usability krav Der er følgende typer af usability krav: Krav til udviklingsproces Krav til udviklingsprocessen beskriver krav til en række milepæle undervejs i et udviklingsforløb. Ved hver milepæl skal leverandøren vise, at udviklingsprojektet er på rette spor, gennem en delleverance, der lever op til forud aftalte krav, og som kunden kan vurdere. Se afsnit 4 og eksemplerne i appendiks A. Krav til produkt Produktkrav beskriver præcise procedurer for hvordan kunde og leverandør afgør, om det færdige produkt lever op til usability krav, som er aftalt på forhånd. Se afsnit 5 og eksemplerne i appendiks B. Krav til usability kompetence Kompetencekrav beskriver, hvordan en kunde kan sikre, at leverandørens medarbejdere har de usability kompetencer, som er nødvendige for at levere et brugervenligt produkt, inden han skriver under på aftalen. Se afsnit Andre typer af krav Der findes en række andre typer krav, som lejlighedsvis forveksles med usability krav. Disse typer krav er kort omtalt i de følgende afsnit Forretningsmæssige krav Forretningsmæssige krav (engelsk: "business requirements") fastlægger overordnede, forretningsmæssige mål for hele systemet. De beskriver, hvad kunden ønsker at opnå med systemet. Eksempler på forretningsmæssige krav til Rejsekort: Rejsekort systemet skal efter 2 år medføre 5% flere rejser. [Begrundelse: Den nemme adgang til billetter vil medføre flere spontane rejser. Kommentar: Opfyldelse af dette krav er vanskelig at måle i praksis. Antallet af rejser påvirkes af mange andre forhold, f.eks. benzinpriser og takstpolitikken.] Rejsekort systemet skal efter 2 års drift medføre en besparelse på mindst 5% i omkostningerne til billethåndtering. [Begrundelse: Omkostningstunge billetsalgssteder kan nedlægges.] Rejsekort skal kunne anvendes til betaling af offentlig transport med bus og tog overalt i Danmark. Under normal drift skal Rejsekort systemet fungere uden at brugere behøver kontakte personale. Manuelt betjente salgs- eller servicesteder må ikke være nødvendige. Forretningsmæssige krav opstilles af ledelsen hos kunden. Januar 2013 Udarbejdet af DialogDesign, Side 11

12 Funktionelle krav Funktionelle krav (engelsk: "functional requirements") stiller overordnede krav til hvordan systemet skal implementeres for at opfylde de forretningsmæssige krav. Eksempler på funktionelle krav til Rejsekort: Rejsekort systemet skal være papirløst Rejsekortet skal fysisk ligne et betalingskort På hver station skal rejsende kunne se saldo på deres rejsekort og prisen for nylig foretagne rejser. Desuden skal de kunne overføre penge til deres rejsekort. På internettet skal rejsende kunne se saldo på deres rejsekort og prisen for nylig foretagne rejser. Desuden skal de kunne overføre penge til deres rejsekort. Rejsende skal tjekke ind, når de påbegynder en rejse. Rejsende skal tjekke ud, når de afslutter en rejse. Rejsekort systemet skal være brugervenligt. Det sidstnævnte krav er udmærket som funktionelt krav, men det er ikke et usability krav. Usability krav omsætter det overordnede krav om brugervenlighed til noget måleligt Brugerkrav Brugerkrav (engelsk: "user requirements") beskriver brugeres overordnede ønsker til hele systemet. Eksempler på brugerkrav til Rejsekort: Det må ikke koste mere at rejse med Rejsekort end at rejse med det nuværende klippekort. Det må ikke være mere besværligt at bruge Rejsekort end at bruge de nuværende klippekort. Det må ikke være dyrere at bruge Rejsekort end at bruge de nuværende klippekort. Det skal være mindst lige så sikkert at bruge Rejsekort som det er at bruge de nuværende klippekort. Rejsekort systemet skal være brugervenligt. Krav til nytte og effektivitet konkretiserer brugerkrav til noget måleligt. Som det fremgår af eksemplerne, kan funktionelle krav og brugerkrav være delvis sammenfaldende. Brugerkrav formuleres af usability specialister på grundlag af brugerbehov (engelsk: "user needs"). Brugerbehov afdækkes bl.a. ved hjælp af interview og spørgeskemaundersøgelser med typiske brugere af det kommende system. Januar 2013 Udarbejdet af DialogDesign, Side 12

13 Januar 2013 Udarbejdet af DialogDesign, Side 13

14 Du kan kun styre det, som du kan måle -- Tom DeMarco Januar 2013 Udarbejdet af DialogDesign, Side 14

15 4. Krav til udviklingsproces Krav til udviklingsprocessen formuleres som krav til en række milepæle undervejs i et udviklingsforløb. Ved hver milepæl skal leverandøren vise, at udviklingsprojektet er på rette spor, gennem en delleverance. Kunden har mulighed for at vurdere, om delleverancen lever op til forud aftalte usability krav. Milepæle og delleverancer kan tage udgangspunkt i udviklingsprocessen i ISO standard , Human-centred design for interactive systems: ISO aktivitet Opstil plan for brugercentreret design i udviklingsprojektet Forstå og beskriv de situationer, hvor systemet skal bruges: Brugere, arbejdsopgaver, kontekst og teknologi Specificér brugerkrav Design systemet i overensstemmelse med brugerkravene Vurdér designet i forhold til usability kravspecifikationen. Leverance til kunde 1. Plan, der beskriver milepæle, dvs. leverancer, som er af betydning for det brugercentrerede design. For hver leverance beskriver planen indhold og leveringstidspunkt. 2. Oversigt over målgrupper og interessenter 3. Beskrivelser af typiske brugere (personas) 4. Oversigt over vigtige arbejdsopgaver (kerneopgaver) 5. Use cases. Beskrivelser af alle arbejdsopgaver, som systemet skal kunne håndtere 6. Brugssituationer (scenarier med relevant kontekst) 7. Usability kravspecifikation 8. Kravspecifikation for usability test af prototype, herunder liste med kerneopgaver, som skal testes 9. Prototyper, der skitserer det planlagte design. Hver prototype skal være egnet til en usability test af udvalgte kerneopgaver. 10. Testrapport og videooptagelser fra usability test af prototype 11. Evt. gentagelse af ovenstående milepæl 8-10 for prototyper, som dækker andre kerneopgaver. 12. Designstandard og wireframes 13. Designspecifikation, herunder fejlmeddelelser og brugerstøtte 14. Jævnlige usability test af halvfærdige versioner af systemet under implementeringen. Hver test opbygges som trin Jævnlig kontrol af, at implementeringen nøje overholder designspecifikationen. 16. Kravspecifikation for usability test af færdigt system 17. Testrapport og videooptagelser fra usability test af færdigt system Januar 2013 Udarbejdet af DialogDesign, Side 15

16 Det er muligt at opstille præcise krav til hver af ovenstående leverancer. Præcise krav til leverance 7, 10, 14, 16 og 17 fremgår direkte eller indirekte af afsnit 4.1. Kunden vurderer hver leverance, evt. med sagkyndig bistand. Hvis vurderingen viser, at en leverance ikke opfylder kravene, skal leverandøren fortsætte udviklingen ved at genoptage en eller flere af de foregående aktiviteter. Udviklingsprocessen er derfor iterativ, dvs. gentagen. Brugssituationer kan være vanskelige at identificere tidligt. Derfor er det nødvendigt, at leverandøren udarbejder prototyper, som kan testes med repræsentative brugere. Testresultaterne bruges til at opstille detaljerede krav og detaljerede mål. Kunden kan stoppe samarbejdet, hvis kunde og leverandør ikke kan blive enige om væsentlige detaljer, eller hvis leverandøren ikke kan leve op til kundens minimumskrav. Du kan finde konkrete eksempler på krav til udviklingsproces i appendiks A Usability test Usability test indtager en central plads i vurderingen af et produkts usability og dermed også i en usability kravspecifikation. Derfor indeholder dette afsnit en nærmere beskrivelse af, hvad der forstås ved en "usability test". Du kan evt. kopiere de følgende 3 afsnit helt eller delvis til din kravspecifikation Definition En usability test eller en test af brugervenlighed (i det følgende også kaldet en test) udføres af en testleverandør for en kunde på grundlag af en kravspecifikation for usability test. En test består af en række testseancer. I hver testseance løser en testdeltager, som tilhører en forud aftalt målgruppe, en række testopgaver med et produkt under overvågning af en testleder. Forløbet af en testseance er beskrevet i en drejebog. Efter testen udarbejder testlederen en testrapport, som bruges til at kommunikere testresultaterne til kunden. De anvendte udtryk i ovenstående definition er forklaret bl.a. i Regler for standardtest af brugervenlighed, som er nærmere beskrevet i næste afsnit Regler for standardtest af brugervenlighed Usability test, som er foreskrevet i denne kravspecifikation, arrangeres og betales normalt af kunden. De skal udføres i overensstemmelse med Regler for standardtest af brugervenlighed version 09, dateret Reglerne findes på webstedet for Foreningen for interaktionsdesign i Danmark, SIGCHI.dk Usability testen skal udføres af en kompetent leverandør af usability test, som er uafhængig af kunde og leverandør. Usability testene skal videooptages. De ubearbejdede videooptagelser skal udleveres til kunden og leverandøren sammen med testrapporten Opfølgning på resultater fra usability test En usability test resulterer i en række usability testresultater. Principielt skal leverandøren rette alle påpegede usability problemer. Populært sagt: Det skal laves om til det virker. I praksis bør kunde og leverandør forhandle om usability problemer, hvor leverandøren Januar 2013 Udarbejdet af DialogDesign, Side 16

17 kan påvise, at omkostningerne ved at rette et problem ikke står i et rimeligt forhold til problemets betydning. Hvis testleverandøren klassificerer et eller flere usability problemer som "kritisk problem", jf. Regler for standardtest af brugervenlighed (se afsnit 4.1.2), skal leverandøren rette problemerne og derefter afholde en ny usability test uden omkostninger for kunden med henblik på at vise, at de kritiske problemer er løst. Januar 2013 Udarbejdet af DialogDesign, Side 17

18 Hvis dit system tvinger mennesker i stedet for at hjælpe dem, duer du ikke som datamatiker -- Chr. Andersen Januar 2013 Udarbejdet af DialogDesign, Side 18

19 5. Krav til produkt Produktkrav stiller konkrete usability krav til det færdige produkt. De kan opdeles i tre typer usability krav: Nytte Kan systemet løse de opgaver, som brugere ønsker løst? Effektivitet Kan brugere løse relevante opgaver inden for en rimelig tid? Tilfredshed Synes brugere at systemet er behageligt at bruge? Disse typer krav stammer fra definitionen af usability i ISO standarden. ISO s definition siger, at usability er The effectiveness, efficiency and satisfaction with which specified users achieve specified goals in particular environments. Effectiveness: the accuracy and completeness with which specified users can achieve specified goals in particular environments Efficiency: the resources expended in relation to the accuracy and completeness of goals achieved Satisfaction: the comfort and acceptability of the work system to its users and other people affected by its use ISO standarden er udgivet af International Organization for Standardization, Den er temmelig dyr, og indeholder ikke andre informationer, som er nødvendige for at skrive gode usability kravspecifikationer. Du kan finde konkrete eksempler på krav til produkt i appendiks B Krav til nytte Krav til nytte fastlægger, hvad systemet skal kunne. Eksempel på krav til nytte: Rejsekort skal kunne anvendes til betaling af offentlig transport med bus og tog overalt i Danmark. Kunden repræsenteret ved ledelsen eller projektejeren opstiller krav til nytte i samarbejde med brugere og andre interessenter. Nytte måles ved at undersøge, om systemet kan udføre de krævede arbejdsopgaver, som er af direkte relevans for brugere. Krav til nytte angiver ikke, hvem der skal være i stand til at udføre en arbejdsopgave, hvor lang tid det må tage, eller hvor behageligt det skal være. Sådanne krav hører under effektivitet, som er beskrevet i næste afsnit. Sat på spidsen kan krav til nytte altså være opfyldt, selv om f.eks. kun den udvikler, der har lavet systemet, kan finde ud af at udføre en arbejdsopgave. Januar 2013 Udarbejdet af DialogDesign, Side 19

20 5.2. Krav til effektivitet Krav til effektivitet fastlægger, hvor hurtigt brugere skal kunne løse opgaver korrekt med systemet. Eksempel på et krav til effektivitet: Udvælg tilfældigt 40 testdeltagere, som er over 18 år, jævnligt rejser med S- tog og ikke har et rejsekort. Bed hver af disse testdeltagere om at bestille et rejsekort på internettet, som passer til deres behov. 95% af testdeltagerne skal kunne løse opgaven på mindre end 10 minutter. Krav til effektivitet følger ofte denne skabelon: Udvælg tilfældigt <antal> testdeltagere, som opfylder følgende forudsætninger <beskrivelse af testdeltagernes forudsætninger>. Bed hver af disse testdeltagere om at <beskrivelse af opgave>. <Procentsats> af testdeltagerne skal kunne løse opgaven på mindre end <tid>. Testdeltagernes forudsætninger, som indgår i skabelonen, bør opdeles i Generelle forudsætninger, f.eks. alder, uddannelse, interesse for teknologi og viden om it. Specifikke forudsætninger med hensyn til det system, som skal vurderes. I det konkrete eksempel drejer det sig om viden om Rejsekort og praktisk erfaring med Rejsekorts komponenter. Den opgave, som indgår i skabelonen, skal være relevant for et væsentligt antal brugere. Opgaven skal være præcist beskrevet uden morsomheder. Den procentsats og tid, som indgår i et krav, skal være acceptabel både for kunde og leverandør. Der vil ofte være en sammenhæng mellem procentsats, tid til at løse opgaven og pris for systemet. Procentsats og tid fastlægges gennem interview og observationer af typiske brugere, der udfører sammenlignelige opgaver på tidligere versioner, konkurrerende produkter eller manuelt. Kravene fastlægges ofte af projektledelse og marketing. Kravene skal som minimum være så ambitiøse, at de sikrer, at produktet er betydeligt bedre end de eksisterende muligheder. En opgaveløsning tæller som en succes, hvis testdeltageren løser opgaven inden for det angivne tidsrum uden nogen form for menneskelig hjælp. Testdeltageren må gerne få hjælp fra systemet, f.eks. ved at benytte hjælpesystemet eller evt. dokumentation. Hvis testdeltageren giver op eller overskrider tidsgrænsen eller når frem til en løsning, som ikke er tilfredsstillende, er opgaveløsningen fejlet. I nogle tilfælde kan det være relevant med følgende tilføjelse til ovenstående skabelon: De resterende testdeltagere skal kunne løse opgaven på <tid 2>. Her vil tid 2 typisk være 2-5 gange tid. Januar 2013 Udarbejdet af DialogDesign, Side 20

21 5.3. Krav til tilfredshed Tilfredshed måles typisk med et spørgeskema, hvor typiske brugere angiver, hvor enige eller uenige de er i en række påstande, f.eks. Rejsekort er nemt at bruge. Krav til tilfredshed følger som oftest denne skabelon: Udvælg tilfældigt <antal> testdeltagere, som opfylder følgende forudsætninger <beskrivelse af deltagernes forudsætninger>. Bed hver af disse deltagere om at udfylde et spørgeskema med følgende påstande <liste med 5-15 påstande om systemet>. For hver påstand skal deltageren angive, hvor enig han er i påstanden på en skala fra 1 til 5: 1 - meget uenig, 2 - uenig, 3 - neutral, 4 - enig, 5 - meget enig Deltageren skal desuden have mulighed for at angive "ved ikke" eller "ønsker ikke at svare". Den gennemsnitlige vurdering af hver påstand skal være mindst <målværdi>. Målværdien for en positivt formuleret påstand skal typisk ligge lidt over middel, dvs. 3,5 til 4, da erfaringen viser, at brugere ofte har en positiv grundholdning til et produkt. Der findes standardiserede spørgeskemaer til måling af tilfredshed, f.eks. SUS og SUMI. Se henvisningerne i afsnit 7. Du kan finde yderligere konkrete eksempler på påstande i afsnit B Gode råd 1. Begræns dig Usability kravene bør fylde 5-8 sider. Den samlede kravspecifikation er meget længere, fordi den indeholder krav til mange andre områder. Usability kravene til Rejsekort i appendiks B er bevidst begrænset til 7 sider, selv om der kunne opstilles flere krav. 2. Nummerér alle krav entydigt Nummereringen gør det nemmere at henvise til et bestemt krav. Eksemplet i appendiks B viser hvordan det kan gøres. 3. Medtag det rigtige svar på en testopgave i kravspecifikationen Testdeltagerne må naturligvis ikke se svaret. 4. Vedligeholdelse Kravspecifikationen bør indeholde oplysninger som letter vedligeholdelse og forbedring af kravene. Disse oplysninger omfatter Kravspecifikationen bør have et versionsnummer, dato for aktuel udgave og navn på ansvarlig for aktuel udgave. Angiv gerne hvem læseren kan kontakte hvis der er tvivlsspørgsmål eller fejl. Ændringsoplysninger: Dato for ændring, beskrivelse af ændring, navn på ansvarlig for ændring, navn på person som har godkendt ændring. Januar 2013 Udarbejdet af DialogDesign, Side 21

22 5.5. Klassiske fejl Uvæsentlige krav Krav skal handle om mål, som er væsentlige for brugere. Undgå krav som ikke sikrer usability. Undgå også unødvendigt detaljerede designforskrifter, fordi de kan forhindre designeren i at lave en innovativ og brugervenlig løsning som den der stiller kravene, ikke har tænkt på. Eksempler på uvæsentlige krav: Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne skal foretage deres første handling på automaten inden for 8 sekunder fra de kommer hen til automaten. [Det er ligegyldigt hvor lang tid det tager brugere at komme i gang. Afgørende for effektivitet er, hvor lang tid det tager brugere at nå et korrekt resultat. Hvis en bruger løser en opgave hurtigere end designeren havde forestillet sig, men synes, at det tager for lang tid, vil det afspejle sig i måling af tilfredshed.] Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne må højst gå i stå én gang under brugen af rejsekortautomaten. [Afgørende for effektivitet er udelukkende den tid det tager at løse opgaven korrekt. Det er i denne sammenhæng ligegyldigt om en bruger går i stå f.eks. 10 gange, bare han løser opgaven hurtigt og korrekt. I øvrigt mangler kravet en beskrivelse af hvad det præcis vil sige at "gå i stå".] Rejsekortautomaten skal have en rød "Annuller" knap [Dette krav sikrer ikke, at brugere kan anvende Annuller knappen hensigtsmæssigt.] Det skal tage højst 30 sekunder at læse brugsvejledningen igennem [Dette krav er værdiløst, for enhver tekst, som kan læses på under 25 sekunder, opfylder kravet. Kravet sikrer, at brugsvejledningen er kort, men hverken at den er nem at få øje på, relevant eller forståelig.] Der skal være en Hjælp knap på hver side på webstedet. [Dette krav sikrer ikke, at brugere kan få øje på hjælp knappen, og det sikrer ikke, at hjælpen er relevant og forståelig.] Upræcise krav Hvert krav skal indeholde en præcis måleforskrift, som ikke kan give anledning til rimelig diskussion om hvordan man objektivt afgør, om kravet er opfyldt. Eksempler på upræcise krav: Systemet skal være grafikbaseret, intuitivt og brugervenligt [Dette krav og de to efterfølgende krav er generelle hensigtserklæringer, ikke præcise, målelige krav. Det hjælper ikke at skrive "Systemet SKAL være brugervenligt!".] Alle skal kunne bruge systemet Alle brugergrænsefladeelementer, f.eks. menuer, skal være nemme at forstå Standeren skal give information ved nedbrud [Tilsvarende, præcise krav findes i B g og B g.] Forskellen mellem standerens lyd for Tjek ind OK og Tjek ind afvist skal være tydelig [Tilsvarende, præcise krav findes i B e og B e.] Januar 2013 Udarbejdet af DialogDesign, Side 22

23 Det skal være muligt at få hjælp til betjening af automaten [Dette kan være et gyldigt krav til nytte. Det er uegnet som effektivitetsmål for hjælp. Kvaliteten af hjælp kan kun måles indirekte. Vi kan måle, om testdeltagere kan overholde de aftalte tidsfrister for arbejdsopgaver, fordi de får effektiv hjælp i situationer, hvor de ikke umiddelbart kan løse arbejdsopgaven.] Urealistiske krav Krav skal være realistiske, dvs. hverken for stramme eller for løse. Eksempler på urealistiske krav: Bed 30 testdeltagere, som ikke tidligere har anvendt rejsekortautomaten, om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 90% af testdeltagerne må højst være 30 sekunder om at indsætte pengene. [Dette krav er for stramt. 3 minutter er her et mere realistisk krav end 30 sekunder.] Bed 30 testdeltagere om at tjekke ind. Mindst 90% af testdeltagerne må højst være 30 sekunder om at tjekke ind. [Dette krav er ikke tilstrækkelig stramt. Et tjek ind, som tager f.eks. 20 sekunder, er uacceptabelt langsomt. 5 sekunder er her et mere realistisk krav end 30 sekunder.] Bed 30 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Ingen testdeltagere må være mere end 5 minutter om at indsætte pengene. [Undgå krav om at 100% eller alle testdeltagere skal kunne løse en bestemt opgave. Sådanne krav betyder, at blot en enkelt uheldig eller atypisk testdeltager gør, at kravet ikke er opfyldt.] Forkert procentangivelse Undgå procentangivelser, som ikke harmonerer med antallet af testdeltagere. Eksempler på forkert procentangivelse: Bed 10 testdeltagere om at indsætte 100 kr. på deres rejsekort ved hjælp af rejsekortautomaten. Mindst 95% af testdeltagerne må højst være 3 minutter om at indsætte pengene. [Krav om, at 95% af testdeltagere skal kunne gøre noget, betyder, at målingen skal gennemføres med mindst 20 testdeltagere, fordi hver testdeltager svarer til 5 procentpoint. Med 10 testdeltagere skal kravet være enten 90% eller 100% (et krav om 100% er uheldigt af de grunde, som blev omtalt i foregående afsnit).] Tvetydige påstande Undgå påstande som omtaler "mine forventninger". Eksempel på tvetydig påstand i spørgeskema: Systemet lever op til mine forventninger. [Meningen med denne påstand er vel noget i retning af "Systemet er godt". Men svaret afhænger af brugerens forventninger, som vi ikke kender. Hvis brugeren har høje forventninger, kan han svare "uenig", selv om han faktisk synes at systemet er ganske godt det lever bare ikke helt op til hans høje forventninger. Hvis brugeren har lave forventninger, kan han svare "Enig", hvilket her betyder "Jeg forventede at det ville være ubrugeligt, og det viste sig at være tilfældet."] Januar 2013 Udarbejdet af DialogDesign, Side 23