Allikevel glemmes feilmeldinger i de fleste webprosjekter. I dette innlegget skal beskrive prinsippene for gode feilmeldinger, samt vise relevante eksempler .
4 prinsipper for gode feilmeldinger:
- Løs problemene før de oppstår
- Fortell kunden på en høflig måte at det har skjedd noe feil
- Fortell kunden hvor feilen har oppstått
- Fortell kunden hvordan de kommer seg videre
1. Løs problemene før de oppstår
Hvis du klarer å identifisere potensielt farlige situasjoner i trafikken før de oppstår, så unngår du ulykker. Dette gjelder også på nett. Skjemaer bør lages på en måte som forhindrer kunden å gjøre feil. Gi brukeren visuelle hint på hva de skal legge inn i tekstboksene. Eksempler på slike visuelle hint er størrelsen på input bokser og knapper som «deaktiviseres» når noen klikker på dem for å unngå dobbeltklikking. I tillegg kan hjelpetekster ved siden av input bokser eller i tilknytning til «action knapper» gjøre susen.
I eksempelet nedenfor ser du hvordan Storebrand forhindrer brukeren i å bestille forsikring hvis de ikke er kvalifisert til å tegne forsikring. Storebrand behandler stort sett på en utmerket måte(noen dårlige unntak finnes hos Storebrand).
Storebrand svarer på relevante spørsmål i skjemaet
Eksempel 1: God håndtering. Se hjelpetekstene. Hentet fra Storebrand.no
En av mine største tabber da jeg jobbet i Norwegian var avgjørelsen knyttet til brukernavn/passord. I eksempelet nedenfor er det ekstremt vanskelig å vite hva Norwegian legger i «brukernavn-begrepet». For de av oss som jobbet med bestillingsløsningen i 2004, så vet vi at brukernavn hos Norwegian alltid er e-postadresse for personer som registrerte seg etter oktober 2004. Istedenfor å tvinge folk til å bruke «glemt brukernavn-lenken», så bør Norwegian heller løse problemet før det oppstår!
Hva er et brukernavn hos Norwegian?
Eksempel 2: Dårlig håndtering. Hva er "brukernavn"? Hentet fra Norwegian.no
2. Fortell kunden at det har skjedd noe feil
Hvis en feil oppstår, så må du på en høflig og forsiktig måte fortelle kunden at en feil har oppstått. Ikke skrem kunden med skumle feilmeldinger og ikke legg skylden på kunden. Norwegian forteller kunden at en feil har oppstått øverst på siden når man har glemt å fylle ut påkrevd information (selv om jeg er noe usikker på hvilke felter som er påkrevd. Noen felter er tomme og hvite). Når en feil oppstår, så hjelper det også hvis markøren automatisk går til feltet hvor det kreves en endring.
Tydelig oversikt over feil fra Norwegian
Eksempel 3: God håndtering. Høflig melding om at en feil har oppstått. Hentet fra Norwegian.no
Hos Expert, så er det vanskelig å se at det har oppstått en feil med mindre man ser nederst i skjemaet og legger merke til den lille ekstra rammen rundt feltet der feilen oppstår.
Har det skjedd noe feil hos Expert?
Eksempel 4: Dårlig håndtering. Har det oppstått en feil? Hentet fra Expert.no
3. Fortell kunden hvor feilen har oppstått
Yahoo er dyktige på feilmeldinger og skjemaene deres kan i mange tilfeller regnes som best practice. I eksempelet nedenfor ser du at Yahoo forteller brukeren når noe er riktig utfylt (grønn markør) og når noe er galt(rød markør). De viser hvor hver feil er, og hvorfor feilen har oppstått.
Best practice fra Yahoo!
Eksempel 5: God håndtering. Det er tydelig hvor feilene har oppstått. Hentet fra Yahoo.no
Haugenbok har solgt mye bøker opp gjennom tidene, men de bryter mot prinsipp 3. De forteller brukeren at en feil har oppstått, men det er ingen visuelle hint i selve skjemaet om hvor feilen har hendt.
Ingen visuelle signaler i skjemaet hos Haugenbok
Eksempel 6: Dårlig håndtering. Det har skjedd en feil, men det finnes ingen visuelle hint på hvor feilen har oppstått. Hentet fra Haugenbok
4. Fortell kunden hvordan de kommer seg videre
Eksempelet nedenfor er i overkant «rødt», men Lands’ End forteller tydelig at noe har skjedd, hvor feilene har skjedd og hva kunden må gjøre for å komme videre. I tillegg tilbyr Landsend online chat og en Call me funksjon. Undersøkelser viser at 76% ønsker å chatte når problemer oppstår i en bestillingsprosess, hvorfor ikke tilby kunden litt chattehjelp før de blir frustrerte?
Genialt fra Landsend
Eksempel 3. Høflige meldinger og online chat. Hentet fra Landsend.com
Hvem har ansvaret for gode feilmeldinger?
Feilmeldinger er et delt ansvar. Designeren må designe dem, utvikler må implementere dem og prosjektleder/prosjekteier må sørge for at feilmeldingene blir implementert korrekt. I tillegg må noen som ser helhetsbildet, skrive kundevennlige og forstålige tekster. Hvis ingen stiller krav, så blir feilmeldinger glemt. Det har jeg erfart i flere prosjekter. Jeg oppfordrer derfor folk til å stille krav. Ta ansvar – gjør noe med det!
Fremtiden & avanserte verktøy
I fremtiden ser jeg for meg at smarte webskjemaer også vil inkludere lyd og bilde på samme måte som feilmeldinger i bilen varsles med en lampe som lyser og en pipelyd. I det øyeblikket et problem oppstår vil bedrifter kunne velge mellom en rekke hjelpemidler, f.eks. automatisk oppkobling mot telefon eller chat. Evt. kan man velge å vise en kort introduksjonsvideo av hvordan man kan løse feilen.
På webanalyse-fronten finnes en rekke verktøy som gjør det enkelt å forbedre både skjemaer og feilmeldinger. De mest kjente er Tealeaf, Clicktale og Userfly. Disse verktøyene gjør det mulig å se hvordan kunder faktisk fyller ut skjemaer og hvordan feil oppstår. Med disse verktøyene dukker også personvern diskusjonen opp. I hvilken grad bør det være lov å overvåke kunders atferd på nettet?
Kilder:
Defensive Design for the Web (37 Signals)
Punktliste med gode og dårlige eksempler på feilmeldinger (Retail: Shaken not stirred)
Mange eksempler på presentasjon av feilmeldinger (Smileycat)
Best practice for form design (PDF av Luke Wroblewski)
Best practice for form validation (Smashing Magazine)
10 nyttige web applikasjonsdesignteknikker (Smashing Magazine)
12 nyttige tips for god interaksjonsdesign (Smashing Magazine)
12 tips for design av bestillingsløsninger (Smashing Magazine)
12 tips som forbedrer konverteringsraten din (Smashing Magazine)
Form design (Smashing Magazine)
En sjekkliste for skjemadesign (A list apart)
En annen sjekkliste for skjemadesign (Webdesign.org)
Web form usability (About.com)
Skjemavalidering kan skape problemer (Iallenkelhet)
Brukervennlige feilmeldinger: 7 tips (The Web usability blog)
Mange eksempler på hvordan nettsteder håndterer feilmeldinger (Uipatterns)
Presentasjon om feilmeldinger (PeakUsability)
Meget bra artikkel om feilmeldinger (Complete Usability)
Hvordan skrive gode feilmeldinger (Complete Usability)
6 konkrete tips på hvordan skrive effektive feilmeldinger (Flow Interactive)
5 showstoppers i betalingsprosessen (Complete Usability)
Tomt på lageret (Complete Usability)
10 konkrete tips om hvordan skrive feilmeldinger (Carsonified)
Hei og takk for matnyttig innlegg 🙂
Med tanke på webanalyse:
Kjenner ikke Clicktale og Userfly, men om de har samme prismodell som Tealeafe er det vel ingen i Norge som har råd til dem?
For «vanlige» nettsteder er det vel fortsatt fokusgrupper + analytics med mål og funnel som er det realistiske verktøyet for analyse?
Hva mener du?
Clicktale og Userfly er rimeligere enn Tealeaf.
Jeg liker best å snakke med og observere faktiske kunder. Verktøyene ovenfor kommer også i større grad.
Takk! Svært bra oversikt. Denne er bokmerket 🙂
bare hyggelig. Spe gjerne på.
Utmerket artikkel – alt for mange nettsider er alt for dårlige på dette området.
Flott gjennomgang, KP. Helt klart et felt der mange har mye å lære.
Kanskje man bør slutte å misbruket begrepet feilmeldinger, og heller kalle det «tilbakemeldinger når brukeren misforstår». Dermed kan man skille mellom tekniske feilmeldinger («siden er nede for vedlikehold», «en feil i databasen gjorde at vi ikke kunne…»), og interaksjonsfeilmeldinger («du glemte å fylle ut addressefeltet», «brukernavnet og/eller passordet du skrev inn er feil»), og det blir lettere å prioritere sistnevnte under utviklingen.
@augustl Absolutt et godt forslag.
– Tekniske feilmeldinger
– Interaksjonsfeilmeldinger
– Andre tilbakemeldinger