For ordens skyld
Jon Gunnar Wold, en av forfatterne av boken Praktisk brukertesting, etterlyste bokanmeldere via Twitter. Jeg er interessert i temaet og meldte meg frivillig til å teste boken. Dette er dermed en sponset bloggpost, men jeg har ikke mottatt annen kompensasjon enn selve boken for å skrive om den.
Om meg
Jeg har tidvis skrevet om jobb her på bloggen, men en god del av leserne har antakelig ikke helt klart for seg hva jeg jobber med. Jeg er testleder og teknisk tester i Vizrt, som (blant annet) utvikler kontrollsystemer for tv-grafikk. Vi lager altså ikke selve grafikken, men verktøyene som brukes for å lage den og få den spilt ut på luften. Jeg bruker mye av tiden min på å planlegge test og grave fram nødvendig teknisk informasjon om kommende systemer og funksjonalitet, men får også leke med morsomme duppeditter. Teamet mitt fokuserer mest på funksjonell testing, men har lav terskel for å rapportere om ting som går på ren brukervennlighet. I tillegg har noen utviklere på avdelingen eksperimentert med brukertesting og oppnådd gode resultater med svært enkle midler.
Om boken
Til poenget. Boken heter altså “Praktisk brukertesting”, og den er akkurat det den gir seg ut for å være. Jeg kom meg greit gjennom hele boken på en halv arbeidsdag. For de som har enda mindre tid å avse åpner boken med en presentasjon av ulike roller som kan tenkes å ha nytte av boken, med tips om hvilke kapitler de bør se spesielt på. Det er et gjennomgående fokus på nytteverdi i arbeidslivet, og en god balanse mellom det ideelle og det oppnåelige.
Før jeg åpnet boken hadde jeg en konkret liste av spørsmål jeg håpet å finne forslag til løsninger på:
- Hva skjer med resultatene av brukertest når deadline nærmer seg og kunden skal på luften med den nye funksjonaliteten på tirsdag?
- Hvordan håndterer man brukertesting med en målgruppe som er vanskelig å definere og ikke minst vanskelig tilgjengelig?
- Hvordan kan man praktisk gjennomføre brukertest av svært komplekse systemer?
Min personlige dom over boken blir dermed avhengig av i hvilken grad jeg fikk nyttige svar på disse spørsmålene. Det skal jeg komme tilbake til.
Først litt mer generelt om boken. Dette er ikke den første teksten jeg leser om brukertesting, selv om jeg på ingen måte er ekspert på området. Det de fleste tekster om brukertesting har til felles er at de er fokusert på metode. I så måte ble jeg svært positivt overrasket over Praktisk brukertesting.
Det er riktignok et kapittel om metode, og det kapittelet sier bare en brøkdel av det det kunne ha sagt. Mesteparten av boken dreier seg om andre ting: Ren praktisk gjennomføring av brukertester, ned til detaljnivå med forslag til sjekklister. Hvordan logge og analysere resultatene, og ikke minst – hvordan få gjennomslag for å gjøre endringer basert på resultatene. En fornuftig prioritering, spør du meg. Metodikk finnes det hauger av annen tilgjengelig litteratur på, og den store bøygen er ikke egentlig å finne ut av metodene, men å få noen konkrete resultater av testingen, i form av bedre produkter.
Boken er tydelig skrevet av folk med mye praktisk erfaring, og bruker flittig sitater fra og referanser til andre erfarne kilder. Den er konkret og behagelig kortfattet, men samtidig fleksibel, og fokuserer gjennomgående på praksis framfor teori – learning by doing. Det dukker likevel opp en påminnelse mot slutten om at brukertesting ikke erstatter interaksjonsdesignere.
En ekstra styrke er at boken er skrevet på norsk, med det norske arbeidsmarkedet som utgangspunkt. Du skal ikke forbi mange landegrenser før du finner store forskjeller i bedriftskultur og brukerkultur. Rådene som gis er fornuftige i forhold til norsk kultur, og eksemplene er hovedsakelig fra norske bedrifter. Dermed er de lett omsettelige i praksis, for ferske brukertestere som tester systemer utviklet i Norge for norske brukere.
Dette er som sagt en styrke, men samtidig en svakhet. Jeg savner et avsnitt eller to om det internasjonale aspektet, både med tanke på brukermassen (i hvilken grad kan man generalisere brukertest gjort i ett land til brukere i et annet?) og med tanke på forankring av brukertesting innad i en internasjonal organisasjon med utviklere i mange land. Kanskje i neste utgave?
Så tilbake til utgangspunktet. Spørsmålene mine var ikke enkle, og de har ikke enkle svar. Boken behandler temaet om tidsfrister på realistisk vis. Noen ganger er det rett og slett ikke tid – prøv igjen neste gang, og planlegg bedre fra start av. Det forutsetter riktignok at den som er interessert i å kjøre brukertesting er med ganske tidlig i prosjektet, og ikke minst at prosjektet er veldefinert. Som så mange andre bøker om test og prosess bærer Praktisk brukertesting preg av konsulentbransje og prosjektbasert utvikling, der man har en plan, en kravspesifikasjon, en prosjektleder og en gruppe mennesker som jobber på et bestemt prosjekt i en bestemt periode. I min bedrift er ikke dette alltid (eller ofte) tilfelle. Spørsmål to og tre blir ikke egentlig besvart.
Vil jeg nå hoppe til verket og sette i gang brukertester på jobben?
Tja.
Produktene jeg jobber med har en del aspekter som gjør at brukertesting ikke er helt rett fram. Som nevnt innledningsvis:
- Målgruppen er vanskelig tilgjengelig. Brukerne er ulike yrkesgrupper hos TV-stasjoner rundt omkring i verden. For de spesifikke produktene jeg har testansvar for er det mest relevant å kjøre brukertest på journalister og operatører – det vil si de som legger informasjonen inn i systemet, og de som sørger for at den blir spilt ut på luften til rett tid. Det er ikke praktisk og ressursmessig mulig å få brukerne til å komme til oss – vi må komme til dem. Selv da kan det være vanskelig å få tilgang til testpersonene vi trenger.
- Testmiljøet er komplekst og kostbart. En ren oppgavebasert test vil ikke være god nok for oss, ettersom en viktig faktor er hvordan systemet fungerer under tidspress med mange beskjeder som flyr fram og tilbake og ting som må endres på sekunders varsel. TV-seere ville bli overrasket over hvor kaotisk situasjonen i kontrollrommet kan framstå under sending, selv om de som sitter der har full kontroll. Noen sekunders forsinkelse som ingen ville lagt merke til i en veldefinert test i rolig setting vil være et stort problem under sending. Å sette opp en egen, realistisk lab er for dyrt og uansett nesten umulig (se neste punkt), og å få tilgang til tv-selskapenes egne kontrollrom er heller ikke rett fram.
- Målgruppen er vanskelig å definere. Systemene våre integrerer tett med øvrig programvare og hardware hos kunden, og det er milevise forskjeller i oppsett og konfigurasjon fra kunde til kunde. Det er tildels store forskjeller i både brukergrensesnittet og arbeidsflyten. Dermed er vi på gyngende grunn når vi skal prøve å generalisere testresultater og ikke minst prioritere hva som er viktigst å endre. Endringer gjort for å tilpasse produktet til arbeidsflyten til en kunde fører ikke sjelden til at en annen kunde roper opp i protest fordi det kompliserer arbeidsflyten hos dem. Det betyr ikke at brukertest er umulig, men det betyr at vi trenger et mye bredere datagrunnlag enn de 3-5 testpersonene boken legger opp til – og fra kunder over hele verden.
At brukertesting kunne være nyttig for oss er det liten tvil om. Vi, som alle andre, har utfordringer på brukergrensesnittfronten, og de spede forsøkene som har vært gjort har vist at det er mye å hente. Likevel nøler jeg med å sette i gang brukertest av annet enn enkelte, begrensede prosjekter og funksjoner. For de fleste produktene tror jeg kost/nytte vil være større med andre tiltak, i alle fall der vi er nå. For eksempel:
- Det er vedkjent at verken utviklerne og testerne har tilgang på nok domenekunnskap. Det kan vi gjøre noe med, på ulike måter. Økt domenekunnskap gir ikke automatisk gode brukergrensesnitt, men det øker sannsynligheten for at man utvikler det kunden egentlig trenger for å utføre arbeidsoppgavene sine.
- Fattigmanns brukertest: Ren observasjon av brukere i deres eget miljø, mens de utfører sitt vanlige arbeid. Denne metoden har vi i testavdelingen allerede tatt i bruk, men arbeidet kan og bør både systematiseres mer og følges bedre opp – og deretter utvides. Selv om dette ikke kan regnes som en brukertest, har Praktisk brukertesting mange nyttige råd som kan brukes også på denne metoden, spesielt med tanke på analyse og bruk av resultatene
Konklusjon
Hvis du snuser på brukertesting og trenger en dytt for å komme i gang, er dette boken for deg. Hvis du allerede har litt erfaring og kunne tenke deg gode tips for å forbedre måten du jobber på, er det også boken for deg.
Verdi for pengene er ikke så relevant som mål, en bedrift som har råd til å kjøre brukertester har uansett råd til de få kronene denne boken koster. Viktigere er at den er verd arbeidstiden som går med til å lese den. Den er både kort nok, tydelig nok og nyttig nok.
Ikke ta deg nær av at jeg er vrang – jeg mener at brukertesting er en verdifull arbeidsmetode og bør brukes overalt der det er praktisk og ressursmessig gjennomførbart. For de aller fleste IT-prosjekter er det det.