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.
Sånn kan en god feilmelding bygges opp.

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

Vis feilmeldingen under feltet det gjelder.

Unngå

Ikke vis alle feil øverst på siden som en liste.

Gjør slik

Vis feilmeldingen med én gang feilen gjøres og i den konteksten feilen skjedde. Her kommer feilmeldingen i det brukeren forlater feltet for E-postadresse.

Unngå

Ikke vis feilmeldinger i modalvinduer eller dialogbokser.

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.


Gjør slik

Anerkjenn situasjonen uten å overforklare eller legge skyld på brukeren.

Unngå

Unngå feilmeldinger som kan oppfattes som useriøse.

Gjør slik

Forklar hva som er galt og hva brukeren kan gjøre for å komme videre.

Unngå

Unngå utydelige feilmeldinger som ikke veileder brukeren til en løsning.

Les mer