En av Don Normans seks designsprinsipper er prinsippet om tilbakemelding. Prinsippet går ut på at alle handlinger man gjør i et grensesnitt som fører til noe, bør gi en tilbakemelding når handlingen er gjort. Gode tilbakemeldinger i feilmeldinger bør gi en forklaring på hva som har skjedd, og skal aller helst tilby et forslag til hvordan man kan løse problemet.
Unngå feilmeldinger
Ingen liker feilmeldinger. Start derfor med å redusere sjansen for at feil oppstår i utgangspunktet. Det gjør du ved å la brukerne
- få all relevant informasjon før de starter å fylle ut noe
- mulighet til å endre svar i felt eller gå tilbake
- ta pause i utfyllingen eller avbryte den
- ha flere formater på datoer og telefonnummer
- få lov å ha ubetydelige feil, som ekstra mellomrom
En god feilmelding hjelper brukerne videre
Feilmeldingens viktigste funksjon er å hjelpe brukerne videre i en prosess. Feilmeldingen skal derfor gi spesifikk informasjon om hva problemet er. Hvis det er mulig skal løsningen foreslå konkrete korrigeringer, som ved feilstavinger eller ugyldige formater.
Gode feilmeldinger er:
- Konkrete. At «Noe gikk galt» gir ikke verdi utover akkurat den informasjonen. En konkret feilmelding sier noe om hvordan brukerne skal komme seg videre.
- Tilpasset ulike situasjoner som kan oppstå. One size does not fit all.
- Korte. Brukerne skal slippe å bruke mer tid enn nødvendig.
Plassering er viktig
Ikke vis alle feil øverst på siden som en liste — det er lett å glemme og vanskelig å lese. Plasser heller feilmeldingen rett under feltet det gjelder. Det gjør det lettere for brukeren å forstå hvilket felt feilmeldingen er knyttet til, og fikse feilen mens feilmeldingen er synlig.
Ikke vis feilmeldinger i modalvinduer eller dialogbokser. Sørg også for at feilmeldingen dukker opp med én gang feilen gjøres og i den konteksten feilen skjedde.
Gjør slik
Unngå
Gjør slik
Unngå
Stil og tone i feilmeldinger
Husk at brukerne er midt i å løse en oppgave, som kanskje betyr mye for dem. De kan også ha dårlig tid eller være frustrert over i det hele tatt å måtte bruke tid på dette. Bruk derfor et enkelt språk og ha aktive setninger. Har du en innholdsdesigner tilgjengelig, la hen ta en titt.
Tonen i feilmeldinger er viktig. Ikke legg skylden på brukeren, men du trenger ikke legge deg helt flat heller. Skyldes feilen en systemfeil, er det fint å skrive «beklager» eller «takk for tålmodigheten». Er det en brukerfeil, kan vi gå mer rett på sak og veilede.
Ingen liker å føle seg dumme. og en belærende eller lite hjelpsom tone kan føre til at brukerne ikke fullfører oppgaven, eller får hjelp andre steder.
Humor i digitale løsninger er i utgangspunktet vanskelig, og i feilmeldinger en nesten umulig oppgave. En feil er aldri morsom, og humor i feilmeldinger kan gi inntrykk av at vi bagatelliserer situasjonen.