Mer uenighet, takk! Det gir bedre sluttresultat. 4

Mer uenighet, takk! Det gir bedre resultat!

Det kommer et tidspunkt i prosjekter der ting har satt seg, man har fått flyten, og det går raskere å bli enige når interaksjonsdesignskissene kommer på bordet. Det er da det bør gå opp et rødt flagg.

Dersom man blir raskt enige kan det bety at man tenker for likt. Man jobber mye sammen, blir påvirket av hverandre og da er en slik utvikling nesten uunngåelig. Og litt for komfortabel. Løsningene blir enkle for oss som skal lage dem, men blir de enkle for sluttbrukerne?

Dette er et av mange argumenter for ulike typer brukerinvolvering (brukertesting, beta-testing, etc.). Men før du kommer dit, prøv denne enkle og billige teknikken for å kvalitetssikre i tidlige faser av prosjektet.

Slik gjør du

  1. Samle sammen 4-5 personer som ikke er “infisert” av prosjektet, men som har mye kunnskap om enten domenet, konseptutvikling, interaksjonsdesign eller brukeratferd. Og som ikke er redde for å kritisere. 
  2. Få med deg en person som kan notere, og som ikke skal komme med innspill samtidig.
  3. Gi deltakerne minimalt (akkurat nok) med bakgrunnsinformasjon og vis dem skisser til løsningen. La dem fyre løs en times tid, med spørsmål, kritikk og forslag til forbedringer. Og uten at du forsvarer deg.
  4. Ikke bruk mye tid på hvert innspill, bare akkurat nok til å forstå og notere innspillet. Gå så videre til neste innspill. Da får du utnyttet de kloke hodene til ekspertene du har der den timen på best mulig måte.

Erfaringer

Det er tøft å sitte der og ta imot kritikk, man har jo som regel gjort så godt man kan. Jeg merker at det er lett å skli over i (bort)forklaringer om hvorfor ting har blitt som de har blitt. Men tenk da på dette: de menneskene som skal bruke systemet til slutt kommer ikke til å ha deg ved siden av seg til å forklare hvorfor ting er som de er. Og ikke er de interesserte i forklaringene heller.

Det vil være gode grunner til ikke å ta hensyn til en del av innspillene, men vær da bevisst på hvorfor. Baker man inn alle gode innspill vokser løsningen ut av sitt gode skinn, så ha med i briefen til ekspertene at de gjerne kan se etter elementer som kan tas ut.

Hvorfor bare en time? Helt pragmatisk årsak. Det er ganske lett å få ekspertene til å bli med en time, men bare en halv time ekstra gjør det vanskeligere å få det til å passe inn i en travel arbeidag. Det hjelper også å reklamere med null forarbeid og etterarbeid, og at de bare kan lene seg tilbake og kritisere uimotsagt. Hvem kan motså det?

Mer om teknikken

For de som gjerne vil ha en metodisk tilhørighet for en slik gjennomgang, så regnes den som en av de gode gamle “usability inspection“-teknikkene, og kalles gjerne “pluralistic walkthrough”. Selv om jeg oftest kjører en slik gjennomgang med eksperter på interaksjonsdesign og brukskvalitet, evt. med observatører fra utviklingsteamet, så kan man også involvere brukere og andre domeneeksperter.

Innenfor programutvikling gjør man noe som minner om slike gjennomganger, “code review”, der en eller flere programmerere går gjennom en annen programmerers kode og sjekker at den er effektiv, godt strukturert, etc.

Give-away

Jeg har lagt ved en liten presentasjon som jeg bruker som innledning til gjennomgangene mine. Du er hjertelig velkommen til å bruke den som utgangspunkt hvis du skal gjøre noe liknende. Jeg vil anbefale deg å prøve det. Det er litt ubehagelig, men veldig nyttig.

Hvordan pleier du å kvalitetssikre i tidlige faser av prosjektet?

Last ned PPT-fil

Kari Hamnes

Flere artikler av Kari CV

4 kommentarer

  1. Moro at dere bruker pluralistic walkthrough. På SINTEF har vi gjort studier av “expert walkthroughs” der evaluatorene er brukere/domeneeksperter. Erfaringene våre fra disse er at domenekspertene gjerne finner andre problemer og forbedringsmuligheter enn usability-eksperter, og – interessant nok – at domeneekspertenes funn får vel så godt gjennomslag videre i utviklingsprosessen. Kunne vært moro å vite om dere har samme erfaringer.

  2. Veldig bra. Vil berre føya til at med litt trening eller mental førebuing eller kva ein vil kalla det, treng det ikkje bli så ubehageleg heller. Det går ikkje av seg sjølv, men om ein prøver å ha tilnærminga “Skulle ynskja nokon kunne hjelpa meg å finna ut kva som kan forbetrast her”, treng ikkje slaga i ansiktet bli så harde.

  3. @Asbjørn F: Ja, har nok tilsvarende erfaringer. Ekspertene gir jo innspill ut fra sin ekspertise. Sluttbrukere har ekspertise om hva de ønsker å gjøre (f.eks. jobben sin, kjøpe noe) og gir reaktiv respons på interaksjonsdesign ut fra det – “får det ikke til”, “finner ikke”, “forstår ikke”. Selv om andre typer eksperter til en viss grad kan sette seg i brukerens sted gir det ikke helt samme resultat. Brukertester med ulike grad av formalitet favner sluttbrukerinnspillene. Sluttbrukere gir i liten grad “generative” innspill, altså sier noe om hvordan ting bør designes. Det er i såfall små, relative kommentarer av typen “det burde heller stå der borte” eller “den teksten burde heller være …”.

    Domeneeksperter (f.eks. noen som jobber med “baksiden” av en nettbutikk) vil kunne gi innspill av typen “her mangler det informasjon – vi er pålagt å opplyse om angrerett”. De er eksperter på domenet – forretninglogikken – og gir gjerne innspill i forhold til det.

    Interaksjonsdesigneksperter gir mer designutløsende innspill fordi de er eksperter på hvordan man visualiserer informasjon, hvilke interaksjonsmekanismer som er lure å bruke til hvilke typer operasjoner, og også har kunnskap om brukererfaringer med ulike interaksjonsdesign.

    Så ja, innspill og funn av potensielle problemer er forskjellige for de ulike typer eksperter, som er et godt argument for å gjennomføre ulike typer kvalitetssikringstiltak.

    Når det gjelder hva som får gjennomslag videre, så har jeg erfaringer som går i flere retninger. Noen ganger er sluttbrukerinnspill mest slagkraftige (spesielt hvis beslutningstakerne har observert på brukertesten), andre ganger er det domeneekspertene, og noen ganger er det dessverre “HiPPO”-ene som får siste ord. Så det varierer.

    @Torstein: Takk for det. Ja, jeg har samme erfaring, det blir litt “go’ondt” etterhvert når man ser hvor mye bedre løsningene blir ved å ta imot innspillene med åpne armer :-)

  4. Takk for grundig svar, Kari!

Skriv en kommentar

  • *

XHTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>