Brukervennlighet er ikke noe du bare kan lage mat i en hvilken som helst fase av design, men må utvikles og raffineres gjennom hele prosessen. Hvis du vil ha det beste sluttproduktet, må du forutse virkelige brukerscenarier fra prototypefasen. Usability testing bør være det siste stedet å begynne å tenke på brukervennlighet.
Hvorfor bekymre deg om brukervennlighetstesting så tidlig i prosessen når prototyping allerede har en stor nok oppgaveliste? Fordi med mindre din prototype er brukbar, vil alle testene fortelle deg at folk ikke liker forferdelige produkter.
med mindre din prototype er brukbar, vil alle testene fortelle deg at folk ikke liker forferdelige produkter
Det sier nesten selvsagt, men du designer produktet som skal brukes av ekte mennesker. For å forberede det på virkelige mennesker, bør det bli testet på ekte mennesker. Prototyper er bygget for eksperimentering, så det er bare fornuftig å teste dem på ekte brukere.
Med det i tankene, la oss se på hvordan du skal holde brukbarheten i bakhodet når du bygger prototypen, hvordan du tester brukervennlighet før du har en prototype og tips for testing med prototyper ...
Usability tester før prototypen
Usability testing trenger ikke å starte med prototyping - faktisk, hvis du har ressurser til å starte før, bør du. Mens det meste er konseptuelle, kan disse testerene finne den beste måten å strukturere prototypens navigasjons- og informasjonsarkitektur på. De vanligste pre-prototyping tester inkluderer:
- Kort sortering: enkel og pålitelig, denne testen avslører hvordan brukerne foretrekker produktets informasjonsarkitektur. Alle elementene i produktet er skrevet på kort, og testtakerne blir bedt om å organisere dem under forhåndsdefinerte kategorier ("lukket") eller under de de har tenkt opp ("åpne"). For detaljer, se Donna Spencer Kort sortering: En endelig guide.
- Tree Testing: "søster test" til kort sortering, tre tester evaluerer effektiviteten av eksisterende informasjon arkitekturer. Brukerne får et grunnleggende, avkortet kart over nettstedet / app / etc. og bedt om å klikke gjennom for å fullføre bestemte oppgaver. Testen overvåker om de velger den riktige ruten, og hvis ikke, hva fikk dem tapt. Grunnlegger av MeasuringU Jeff Sauro forklarer detaljene.
- Intervjuer: Noen ganger er den beste måten å forstå brukerne på, bare å spørre. Det høres enkelt nok ut, men nyanser og strategier for brukerintervjuer er uendelige. Kate Lawrence, UX-forsker ved EBSCO Publishing gir noen tips om hvordan du kjører disse spesielt for brukbarhetstesting.
Faste problemer tidligere er alltid bedre, og disse foreløpige tester vil sikre at konseptets grunnlag for prototypen er i god form før en enkelt linje trekkes.
De riktige brukerne og de rette oppgavene
Mens brukervennlighetstester er forskjellige, trenger alle brukere, og de fleste av dem involverer oppgaver. Siden disse to elementene er fremtredende i all brukbarhetstesting, vil vi kort forklare hvordan du best skal håndtere begge deler.
- Rekruttere brukere: Etter alt arbeidet med personas, bør du nå ha en klar ide om målbrukerne dine. Det bidrar også til å segmentere brukerne dine basert på atferd. Faktisk bør du ikke besatt over demografi. Den største differensiatoren vil trolig være om brukerne har tidligere erfaring eller er kunnskapsrik om domene eller bransjen - ikke kjønn, alder eller geografi.
Å vite hvem du skal rekruttere er bare det første trinnet. Jo mer involvert er å finne og rekruttere dem. Jeff Sauro skisserer de 7 beste måtene å Finn de ideelle brukerne for testing. - Skriveoppgaver: Oppgaver bestemmer hva brukeren egentlig gjør under testen, og bestemmer derfor hvilke bruksfaktorer som blir undersøkt. Tingting Zhao, Usability Specialist for Ubuntu , beskriver noen forskjeller å huske når du designer en oppgave. Det er to hovedavgjørelser:
en. Direkte mot scenario: En direkte oppgave er en som er strengt instruksjonsmessig (f.eks. "Søk på nettstedet for en Tandoori-kyllingrecept") mens en scenariooppgave kommer med kontekst ("Du er vert for et middagsfest for noen gamle venner, og du trenger en Tandoori kylling oppskrift "). Direkte oppgaver fungerer best hvis du tester tekniske data, mens scenariooppgaver er bedre i alle andre tilfeller.
b. Lukket vs åpen: En lukket oppgave har klart definerte suksesskriterier, mens en åpen oppgave kan fullføres på flere måter. Lukkede oppgaver kontrollerer bestemte funksjoner, mens åpne oppgaver er bedre for å forstå hvordan brukerens sinn fungerer. En lukket oppgave ville være: "Din venn har bursdag i helgen. Finn et morsomt sted for opptil 15 personer. "En åpen oppgave ville være:" Du hørte dine medarbeidere snakke om iWatch. Du vil lære hvordan det fungerer. "
Generelle råd for testing av prototype brukbarhet
Gitt den "ufullstendige" typen av prototyper ... vil brukerne ha spørsmål ... at en moderator må svare
En av de første spørsmålene om brukervennlighetstestere spør er om det skal modereres eller ikke. Mens det er en mange gode grunner For unmoderated tester, for prototype tester anbefaler vi moderering. Gitt den "ufullstendige" typen av prototyper, er det sjansen for at brukerne vil ha spørsmål om brukergrensesnittet som en moderator må svare på.
En annen vanlig feil i testingen er å stoppe eller endre testen hvis brukeren opplever problemer. Siden målet om brukervennlighetstesting er å finne og løse vanskeligheter, kan denne situasjonen faktisk gjøre testen til en suksess. Hvis brukeren for eksempel går av på veier som ikke er utviklet ennå i prototypen, kan du spørre dem hvorfor de gikk dit og hva de ville ha likt å oppnå. Noen få oppfølgingsspørsmål om hindringene kan gi mer verdifull tilbakemelding enn en bruker med en "perfekt runde".
Forskjellige troverdigheter for testing av prototyper
Mens noen tror på å teste tidlig med grove prototyper og andre talsmann for å teste høyere trofaste prototyper, tror vi at den beste tilnærmingen er å teste i hver troskap som er mulig - og så ofte som mulig. Chris Farnum, Senior Information Architect på Enlighten, forklarer fordeler og ulemper av hver type. Som vi vil beskrive nedenfor, er lavere troverdighetstester bedre for testing av konsepter, mens høyere troskapstester er mer egnet for testing av avanserte interaksjoner.
Den beste tilnærmingen er å teste ved enhver troskap som er mulig
- Lav troskap: brukervennlighetstester for lo-fi prototype, inkludert papirprototyper, kan fungere i de tidlige utviklingsstadiene, men blir upraktiske senere. Lo-fi prototyper oppfordrer også mer ærlig kritikk, siden det er umiddelbart klart at det bare er et arbeid pågår.
I de senere stadier, når brukervennlighetstestene sjekker avanserte funksjoner, stopper lo-fi prototyper imidlertid å være nyttige siden du har truffet troverdighetsgrensen. Dette gjelder spesielt for papirprototyper, siden du trenger en "menneskelig datamaskin" for å manipulere alle delene, og det kan bli ekstremt vanskelig når du legger til menyer, interaksjoner, sider og elementer. - Høy troskap: Hi-fi prototypingstest gir brukeren en nærrealistisk opplevelse av hva sluttproduktet vil bli. Hi-fi prototyper er ideelle for testing av komplekse interaksjoner og dine løsninger for bruksproblemer oppdaget i tidligere testrunder. Imidlertid er det i motsetning til lo-fi prototyper dyrere å lage.
- Middels troskap: kan ikke bestemme mellom høy eller lav troskap? Mid-fi prototyper fungerer best når du trenger en balanse mellom troskap og pris. Hvis du bare skal kjøre en runde brukervennlighetstester, må du gå på medium trofasthet.
Fire innholdsretningslinjer for testing av en prototype
Når du begynner å bygge prototypen, er det ikke bare akseptabelt å glosse over mindre detaljer i stedet for det viktigste, det anbefales til tider. Men når det kommer tid til å teste prototypen din, må du kontrollere at du har fylt ut noen av disse detaljene som kan overses i lavere troskap. I vår erfaring er disse de mest nyttige tipsene for å forberede prototypen til testing:
- Unngå lorem ipsum: distraherende, forvirrende og manglende mening, lorem ipsum tekst tar ikke fullt ut ditt produkts melding.
- Bruk generiske navn: tester kan være mer moro med dumt eller kjendis navn, men moro er ikke poenget. Eventuelle forstyrrelser vil forstyrre resultatene, så hold navnene generiske og realistiske.
- Ingen plassholderbilder eller ikoner: bokser med X s kan fungere under wireframing, men ikke i testing. Bilder og ikoner spiller en stor rolle i UX, så disse bør implementeres ved å teste tid, selv om det bare er med midlertidige skisser. Unntaket er om disse bildene er rent dekorative og ikke hjelper å forstå brukergrensesnittet.
- Bruk realistiske data - Ikke fyll data som telefonnumre eller adresser med X s eller vitser - dette er distraherende. Realistiske og troverdige data her vil gi din brukertest de mest nøyaktige resultatene.
Testdeltakere kan bli fikset på detaljer som du syntes var ubetydelig, så vær forsiktig med hva du ikke sier. Disse små trinnene for å redusere distraksjon og forvirring kan gå langt mot renere testdata.
Utvalgt bilde, brukervennlighetstesting via av K2_UX via Flickr.