Gi bedre feilmeldinger
Ups, noe gikk galt!
Feilmelding er en vanskelig øvelse for å gi god brukeropplevelse
Feilmeldinger er en del av vårt daglige liv på internett og APP-er. Til og med begynner dette å bli en del av hverdagen i moderne biler. Men vi som utviklere, gir vi en god feilmelding til brukerne våre? Skylder vi på andre eller er feilmeldingen utformet slik at kun vi selv forstår den?
Vi omgir oss med feilmeldinger i det daglige. Noen av dem er subtile mens andre kan oppleves som svært så kritiske. Enten det er melding om at vi har glemt å fylle inn et felt i et skjema eller det eviglange KID-nummeret.
Hva er en dårlig feilmelding?
Ta en titt på feilmeldingen over. Den sier noe men langt ifra hva den burde fortelle brukeren.
Teknisk sjargong
Selv om meldingen er et hint til oss utviklere så er det svært få brukere som har noe anelse om hva API står for og hvorfor man ikke får koblet seg til det. Teknisk sjargong passer ikke til brukeren med mindre det faktisk gir brukeren den informasjonen den trenger.
Skylde på noen andre
Å gi noen andre skylden for feilen gir ikke brukeren noe. At tredjepart ikke kan svare er ikke noe brukeren kan endre på eller noe som gir brukeren noe verdi. Fokuser heller på problemet fremfor å gi noen andre skylden for feilen.
"Vennlig tone"
Ups, noe gikk galt! er ikke hva man vil høre når tannlegen borrer i tanna di. Hvis brukeren utfører en oppgave og opplever den som kritisk så er det ikke slik han ønsker å få overlevert en feilmelding. Takt og tone er viktig i en feilmelding. Spesielt hvis man har et system som er kritisk for brukeren.
Takt og tone bør også følge nettstedet ellers. Hvis uff, heisann, ops osv er en del av takt og tonen på nettstedet så kan det passe. Men i de fleste tilfeller bør tittelen heller være mer oppklarende enn dagligtale.
Hva er en god feilmelding?
Her kan vi nok være litt uenige. Men å ikke gå i fellene som jeg nevner over er nok en god ting. Å berolige brukeren med godt ordvalg er bedre enn å vise en feilkode. Det tror jeg vi alle kan være enige i.
Si hva og hvorfor
Fortell tydelig hva som hendte eller ikke hendte. Forklar brukerne hvorfor feilmeldingen oppsto. Her kan man droppe den tekniske sjargongen og heller forklare at det har oppstått en teknisk feil.
Hjelp brukeren med løsning
Hvis det er mulig så forklar hva brukeren kan gjøre for å rette problemet. Hvis ikke det er mulig så guide brukeren til hvor brukeren kan få tak i mer informasjon evt. hvordan brukeren kan ta kontakt for å løse problemet.
Forklar hva som ikke hendte
Eksempel er hvis feilen oppsto i et skjema så kan man berolige brukeren om at all data er tatt vare på som kladd og kan sendes inn senere. Hvis arbeidet brukeren har lagt ned i verktøyet ikke er borte så vil en slik beskjed berolige brukeren.
Gode feilmeldinger
Jeg er selv skyld i dårlige feilmeldinger og til og med console.log som ligger skjult i koden for å dumpe evt. feilkode fra f.eks. et API. Jeg er skyld i tekniske feilmeldinger som kun gir mening til andre utviklere og ikke brukeren. Dette er noe jeg i senere tid har blitt mer klar over og tydeligere på.
Selv om det er mer jobb så får man til syvende og sist levert et langt bedre produkt om man setter brukeren foran seg selv. Og den tiden er det verdt å legge ned i et prosjekt.
Som utvikler så ta gjerne med deg UX på en slik prosess for å lage gode feilmeldinger.
Kilde: Som inspirasjon til dette blogginnlegget leste jeg When life gives you lemons, write better error messages av Jenni Nadler hos Wix.com.