Fejlmeddelelser, der hjælper i stedet for at irritere

Lær at skrive fejlmeddelelser i formularer, der får brugerne hurtigt videre. Se, hvilken placering, tone og tydelighed der mindsker afbrud.

Kladde

Når nogen møder en fejl i din formular, er de et øjeblik fra at forlade den. Undersøgelser viser, at over 75 % af brugerne dropper formularer, når der kommer fejl, og de ikke straks kan rette dem. Det er ikke et lille problem. Det er tre ud af fire mulige kunder, leads eller tilmeldinger, der går deres vej. Forskellen på at beholde dem og miste dem kommer ofte ned på én ting: fejlmeddelelsen. En forvirrende fejlmeddelelse sender dem væk. En tydelig, hjælpsom fejlmeddelelse får dem tilbage og får dem til at gennemføre formularen.

En fejlmeddelelse er din formulars chance for at lede nogen mod målet, når de laver en fejl. En dårlig fejlmeddelelse (en, der er upræcis, giver skylden eller ikke hjælper) gør brugeren forvirret eller får dem til at føle, at det er deres skyld. En god fejlmeddelelse fortæller præcis, hvad der gik galt, hvorfor det har betydning, og hvordan det rettes, i et almindeligt sprog. Denne artikel handler om, hvordan du skriver fejlmeddelelser, der virker, hvor du placerer dem, så de ikke kan overses, hvilken tone der skaber tillid, og hvorfor tydelighed er forskellen på afbrud og gennemførelse.

Hvad gør en fejlmeddelelse effektiv

En effektiv fejlmeddelelse gør tre ting. For det første siger den klart, hvad der gik galt. Ikke "Ugyldig indtastning." I stedet: "E-mailadresser skal have et @-tegn." For det andet forklarer den, hvorfor indtastningen blev afvist, hvis det hjælper. "Adgangskoder skal have mindst 8 tegn, fordi kortere er lettere at knække." For det tredje fortæller den brugeren præcis, hvad de skal gøre nu. "Gå tilbage til feltet med adgangskode og tilføj mindst 4 tegn mere." Nu kender brugeren problemet, forstår, hvorfor det har betydning, og ved, hvordan det rettes.

Tonen i en fejlmeddelelse betyder mere, end de fleste tror. En fejlmeddelelse, der lyder vred eller nedladende, får brugeren til at føle sig bebrejdet. "Du glemte @-tegnet" føles som deres skyld. "E-mailadresser skal have et @-tegn" er den samme oplysning, men uden skyld. En hjælpsom tone anerkender fejlen uden at få personen til at føle sig dårlig.

Timing og placering af en fejlmeddelelse afgør, om brugeren overhovedet ser den. En fejlmeddelelse, der står tre skærmbilleder under det felt, der gav fejlen, er let at overse. En fejlmeddelelse, der står ved siden af det problematiske felt i det øjeblik, de prøver at komme videre, tvinger dem til at lægge mærke til den og rette den med det samme.

Kontrol undervejs eller kontrol ved indsendelse

Kontrol undervejs viser en fejlmeddelelse i det øjeblik, nogen udfylder et felt forkert, før de sender formularen. Et felt til adgangskode viser en fejl, så snart de skriver en adgangskode, der er for kort. Et felt til e-mail viser en fejl, så snart de forlader feltet uden et @-tegn. Respons i realtid er stærk, fordi folk retter fejl med det samme i stedet for at opdage dem, efter de har udfyldt hele formularen.

Kontrol undervejs er især god til én ting. Den skaber tryghed. Når nogen skriver en e-mailadresse og ser et grønt flueben dukke op, ved de, at det er rigtigt. De går videre uden tvivl. Uden den bekræftelse undrer de sig over, om deres indtastning var rigtig, og tvivler på sig selv.

Kontrol ved indsendelse er det, der sker, når nogen klikker på send, og formularen tjekker alle felter på én gang. Hvis et felt har en fejl, kommer der et resumé øverst i formularen med alle problemer, og hvert felt med en fejl bliver fremhævet. Kontrol ved indsendelse fanger fejl, som kontrol undervejs missede, og giver brugerne et samlet billede af, hvad der skal rettes.

Den bedste måde er begge dele. Brug kontrol undervejs til felter, der kan tjekkes med det samme (format på e-mail, længde på adgangskode, format på postnummer). Brug kontrol ved indsendelse som sidste sikkerhedsnet. Når nogen klikker på send, og et felt stadig har en fejl, så vis dem med det samme, hvad der skal rettes, før de kan sende.

Sådan skriver du fejlmeddelelser, der er tydelige og kan handles på

En tydelig fejlmeddelelse fortæller brugeren præcis, hvad problemet er. En generisk fejlmeddelelse lader dem gætte. Sammenlign de to:

Generisk: "Ugyldigt telefonnummer."

Tydelig: "Telefonnumre skal have 10 cifre. Du har skrevet 9. Tilføj ét ciffer mere."

Den generiske besked fortæller brugeren, hvad der er galt, men ikke hvorfor eller hvordan det rettes. Den tydelige besked fortæller problemet, hvorfor det skete, og præcis hvad de skal gøre. Den tydelige besked tager lidt længere tid at læse, men sparer brugeren minutter med frustration.

En fejlmeddelelse, man kan handle på, indeholder en anvisning. "Adgangskoder skal indeholde mindst ét tal" fortæller, hvad der mangler. "Adgangskoder skal indeholde mindst ét tal. Gå tilbage til feltet med adgangskode og tilføj et tal." fortæller, hvad de skal gøre. I formularer er anvisningen som regel oplagt (gå tilbage til feltet), men at skrive det ud hjælper folk, der ikke er vant til formularer, eller som bruger hjælpemidler.

Brug et almindeligt sprog. Ikke "Format for postnummer forkert." I stedet: "Postnumre er 5 tal. Du har skrevet bogstaver." Ikke "Ugyldigt format for e-mail." I stedet: "E-mailadresser skal have et @-tegn og et domæne (eksempel: navn@firma.com)."

Placering, der gør fejl umulige at overse

En fejlmeddelelse, der står langt fra det felt, der gav fejlen, er let at overse. Når nogen udfylder en formular med mange felter, fokuserer de på ét felt ad gangen. En fejlmeddelelse, der dukker op nederst i formularen, mens de stadig kigger på toppen, bliver ikke set.

Den bedste placering til en fejlmeddelelse er lige under eller ved siden af det felt, der har fejlen. Når de går videre til næste felt eller prøver at sende, dukker en fejlmeddelelse op med det samme under det felt, de lige har udfyldt. De kan ikke undgå at se den, fordi den står, hvor de venter, at næste handling er.

Til et resumé af fejl (der viser alle fejl på én gang efter indsendelse) skal du placere det øverst i formularen. Det giver brugeren et samlet overblik over alle problemer. Når de så ruller ned, dukker de enkelte fejl op igen ved hvert felt, de skal rette. Den dobbelte metode har to formål: den viser dem hele omfanget af det, der skal rettes, og den minder dem om det, mens de arbejder sig gennem hvert felt.

Brug aldrig toast-beskeder til fejl i formularer. En toast er en besked, der kort dukker op i hjørnet af skærmen og så forsvinder. I formularer er det den værst mulige placering. Fejlen står langt fra det felt, der gav den. Den forsvinder, før brugeren når at læse den. Den skaber en kløft mellem problemet og stedet, hvor det skal rettes. Hvis en fejlmeddelelse skal forsvinde, må det først være, efter brugeren har rettet feltet.

Visuelt design af fejlmeddelelser

Farve alene er ikke nok til at vise en fejl. En person med farveblindhed ser måske ikke den røde farve, der viser en fejl. Et meget lille ikon kan overses af en med nedsat syn. Brug flere signaler: farve plus tekst plus ikon.

En rød kant om feltet. Et rødt eller orange ikon ved siden af fejlmeddelelsen. Tekst, der tydeligt siger, hvad problemet er. Alle tre sammen skaber en fejltilstand, som næsten alle kan genkende.

Skriftstørrelsen har betydning. Teksten i en fejlmeddelelse skal have samme størrelse som etiketten til feltet. Hvis fejlmeddelelsen er mindre, kan folk overse den eller tro, at den er mindre vigtig, end den er. Fejlmeddelelsen fortjener samme visuelle vægt som etiketten.

Etiketten til det problematiske felt kan også ændre sig. Teksten i etiketten kan blive rød eller fed. Det er endnu et visuelt signal, der hjælper brugeren med hurtigt at skimme formularen og finde det felt, der skal rettes.

Tone og høflighed i fejlmeddelelser

Fejlmeddelelser skal lyde, som om du hjælper nogen og ikke bebrejder dem. Undgå ord, der lyder hårde eller anklagende.

Hårdt: "Du har skrevet en ugyldig e-mailadresse."

Hjælpsomt: "E-mailadresser skal have et @-tegn. Tjek det, du har skrevet, og prøv igen."

Hårdt: "Adgangskoden er for svag."

Hjælpsomt: "Adgangskoder skal have mindst 8 tegn. Længere adgangskoder er mere sikre."

Hårdt: "Du glemte at udfylde dette felt."

Hjælpsomt: "Dette felt er obligatorisk. Fortæl os, hvad du synes."

En hjælpsom tone anerkender fejlen uden at få personen til at føle sig dårlig. Den forklarer, hvorfor reglen findes (når det hjælper). Den går videre uden at dvæle ved fejlen.

Almindelige fejl i fejlmeddelelser

Den mest almindelige fejl er at være for upræcis. "Ugyldig indtastning" fortæller brugeren ingenting. "Noget gik galt" hjælper lige så lidt. Vær tydelig om, hvad problemet er.

En anden fejl er at bruge teknisk sprog. "Regex mismatch" eller "Validation failed" kan betyde noget for ingeniører, men almindelige folk aner ikke, hvad udtrykkene betyder. Oversæt tekniske fejl til et almindeligt sprog.

En tredje fejl er at vise for mange fejl på én gang. Hvis en formular har 20 felter, og alle 20 viser fejl, føler brugeren sig overvældet. Prioritér, hvilke fejl der er kritiske (som et obligatorisk felt, der er tomt), og vis dem først. Mindre vigtige fejl (som et felt med et problem med formatet, men som er valgfrit) kan vises bagefter.

En fjerde fejl er fejlmeddelelser, der gentager etiketten uden at give ny information. Etiketten siger "E-mailadresse." Fejlmeddelelsen siger "E-mailadressen er ugyldig." Brugeren ved allerede, hvilket felt der har problemet (de kan se den røde kant), men de ved stadig ikke, hvorfor den er ugyldig. Fejlmeddelelsen skal tilføje information og ikke gentage etiketten.

En femte fejl er ikke at vise en vej til at rette problemet. "Adgangskoden opfylder ikke kravene" fortæller brugeren, at noget er galt, men ikke hvad kravene er. "Adgangskoden opfylder ikke kravene. Adgangskoder skal have mindst 8 tegn og ét tal" fortæller dem, hvad der skal rettes.

Sådan hjælper WEMASY dig med at lave tydelige fejlmeddelelser

WEMASYs formularbygger har færdige fejlmeddelelser til almindelige felttyper. Felter til e-mail viser "E-mailadresser skal have et @-tegn", når formatet er forkert. Felter til telefon viser "Telefonnumre skal have 10 cifre", når længden er forkert. Felter til adgangskode viser krav til styrken, mens brugeren skriver. Disse meddelelser er som standard tydelige, præcise og hjælpsomme.

Du kan tilpasse fejlmeddelelser, så de passer til dit brands tone. Skift beskeden fra "E-mailadresser skal have et @-tegn" til "Hov, det ligner ikke en e-mail. Prøv igen?" Tonen ændrer sig, men tydeligheden bliver. Du styrer, hvordan beskeden lyder, uden at ofre klarheden.

Til egen kontrol (felter med særlige regler, der kun gælder din formular) kan du skrive dine egne fejlmeddelelser direkte i formularbyggeren. Systemet hjælper dig med at placere beskeden ved feltet, vise den på det rigtige tidspunkt (undervejs eller ved indsendelse) og style den, så den passer til dit formulardesign.

Kontrol i realtid er indbygget, så fejlmeddelelser kan dukke op, mens brugerne skriver, og ikke kun efter de har sendt. Det fanger fejl tidligt og undgår frustrationen ved at udfylde en hel formular og så opdage problemer til sidst.

Se, hvilke funktioner til formularer der er med i din WEMASY-plan.

Ofte stillede spørgsmål

Skal fejlmeddelelser altid være røde?
Rød er standardfarven til fejl, fordi folk overalt forstår rød som "stop" eller "problem". At bruge rød til fejl er ikke tilfældigt. Det er et lært signal, der er blevet styrket på hele nettet. Brug ikke en anden farve i håb om, at den passer bedre til dit brand. Genkendelsen af rød som fejl er for værdifuld til at overskrive. Du kan bruge brandets farve i kanten af feltet eller i ændringen af etiketten, men hold tekst og ikoner til fejl røde. Med WEMASYs hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvor detaljerede skal fejlmeddelelser være?
Detaljerede nok til at løse problemet med det samme, men ikke så lange, at folk ikke læser dem. En fejl på ét ord som "Ugyldig" er for upræcis. En forklaring på et helt afsnit er for meget. Sigt efter en eller to sætninger. "E-mailadresser skal have et @-tegn" er tydeligt. "Sørg for, at den e-mailadresse, du har skrevet, følger standardformatet navn@domæne.com, hvor domænet skal være et gyldigt topdomæne" er overkill.
Skal jeg vise fejl, før brugeren prøver at sende?
Ja, hvis du kan kontrollere med det samme. Format på e-mail, længde på adgangskode og format på postnummer kan alle tjekkes, mens brugeren skriver. Vis fejl for dem med det samme. Vent ikke til indsendelsen. Til kontrol, der kræver et kald til serveren (tjekke om en e-mail allerede er registreret, kontrollere en adresse), skal du vente, til brugeren går videre til næste felt eller prøver at sende. At tjekke for tidligt føles langsomt. At tjekke for sent føles forsinket.
Hvilken tone skal fejlmeddelelser have?
Hjælpsom og uden at give skyld. Forestil dig, at du guider en ven gennem en formular. Du ville ikke sige "Du har lavet en fejl." Du ville sige "Her skal der være et tal." Brug "skal have", "kræver" eller "skal" i stedet for "du glemte" eller "du skrev forkert". Hold tonen varm og støttende og ikke mekanisk eller hård. En venlig tone hjælper brugerne med at se fejlen som respons og ikke som nederlag.
Skal jeg fremhæve hele formularen eller kun feltet med fejlen?
Fremhæv kun feltet med fejlen. At fremhæve hele formularen overvælder brugeren og gør det sværere at fokusere på det, der skal rettes. Brug en rød kant, rød etiket eller rødt ikon på det bestemte felt. Øverst i formularen kan du vise et resumé af alle fejl, så brugeren ser hele omfanget. Lad dem så rette fejl en ad gangen. Den balance mellem at vise det hele og at fokusere på ét problem ad gangen virker bedst.
Hvor længe skal fejlmeddelelser være synlige?
Indtil brugeren har rettet fejlen, eller formularen sendes igen. Luk aldrig fejlmeddelelser automatisk. Hvis en fejl forsvinder, før brugeren har læst den, ved de måske ikke, hvad der gik galt, og bliver frustrerede. Lad fejlmeddelelsen være synlig, til feltet er rettet. Fjern den først, når brugeren har rettet feltet og er gået videre eller har sendt formularen igen.

Brug det med det samme
på din egen hjemmeside.

Start gratis med WEMASY, og byg din side på få minutter.