När någon stöter på ett fel i ditt formulär är hen ett ögonblick från att lämna. Studier visar att över 75 % av användarna överger formulär när fel dyker upp och de inte kan rätta dem direkt. Det är inget litet problem. Det är tre av fyra potentiella kunder, leads eller anmälningar som går sin väg. Skillnaden mellan att behålla dem och förlora dem handlar ofta om en enda sak: felmeddelandet. Ett förvirrande felmeddelande skickar iväg dem. Ett tydligt, hjälpsamt felmeddelande tar dem tillbaka och får dem att slutföra formuläret.
Ett felmeddelande är ditt formulärs chans att leda någon mot slutförande när hen gör fel. Ett dåligt felmeddelande (ett som är vagt, skuldbeläggande eller oanvändbart) gör att användaren känner sig förvirrad eller skyldig. Ett bra felmeddelande talar om exakt vad som gick fel, varför det spelar roll och hur det rättas, på enkelt språk. Den här artikeln går igenom hur du skriver felmeddelanden som fungerar, var du placerar dem så att de inte kan missas, vilken ton som faktiskt skapar förtroende och varför tydlighet är skillnaden mellan avhopp och slutförande.
Vad som gör ett felmeddelande effektivt
Ett effektivt felmeddelande gör tre saker. För det första anger det tydligt vad som gick fel. Inte "Ogiltig inmatning." I stället: "E-postadresser behöver ett @-tecken." För det andra förklarar det varför inmatningen avvisades, om det hjälper. "Lösenord måste vara minst 8 tecken eftersom kortare lösenord är lättare att knäcka." För det tredje talar det om exakt vad användaren ska göra härnäst. "Gå tillbaka till lösenordsfältet och lägg till minst 4 tecken till." Nu känner användaren till problemet, förstår varför det spelar roll och vet hur det rättas.
Tonen i ett felmeddelande spelar större roll än de flesta tror. Ett felmeddelande som låter arg eller nedlåtande får användaren att känna sig anklagad. "Du glömde @-tecknet" känns som användarens fel. "E-postadresser behöver ett @-tecken" är samma information men utan skuld. En hjälpsam ton erkänner misstaget utan att få personen att må dåligt över det.
Timing och placering av ett felmeddelande avgör om användaren ens ser det. Ett felmeddelande som dyker upp tre skärmbilder under det fält som orsakade det är lätt att missa. Ett felmeddelande som dyker upp bredvid det felaktiga fältet, i samma stund som användaren försöker gå vidare, tvingar hen att lägga märke till det och rätta det direkt.
Validering medan du fyller i eller vid inskick
Validering medan du fyller i visar ett felmeddelande i samma stund som någon fyller i ett fält fel, innan hen skickar formuläret. Ett lösenordsfält visar ett fel så fort hen skriver ett lösenord som är för kort. Ett e-postfält visar ett fel så fort hen lämnar fältet utan ett @-tecken. Återkoppling i realtid är kraftfull eftersom människor rättar misstag direkt i stället för att upptäcka dem efter att ha fyllt i hela formuläret.
Validering medan du fyller i gör en sak särskilt bra. Den skapar trygghet. När någon skriver en e-postadress och ser en grön bockmarkering dyka upp vet hen att det blev rätt. Hen går vidare utan tvivel. Utan den bekräftelsen undrar hen om inmatningen var rätt och tvivlar på sig själv.
Validering vid inskick är vad som händer när någon klickar på skicka och formuläret kontrollerar alla fält på en gång. Om något fält har ett fel visas en sammanfattning av valideringen med alla problem högst upp i formuläret, och varje fält med fel markeras. Validering vid inskick fångar fel som valideringen medan du fyller i missade och ger användare en fullständig bild av vad som behöver rättas.
Det bästa är att använda båda. Använd validering medan du fyller i för fält som kan kontrolleras direkt (e-postformat, lösenordslängd, format på postnummer). Använd validering vid inskick som ett sista skyddsnät. När någon klickar på skicka, och något fält fortfarande har ett fel, visa direkt vad som behöver rättas innan hen kan skicka.
Skriv felmeddelanden som är tydliga och går att agera på
Ett tydligt felmeddelande talar om exakt vad problemet är. Ett allmänt felmeddelande låter användaren gissa. Jämför de här två:
Allmänt: "Ogiltigt telefonnummer."
Tydligt: "Telefonnummer behöver 10 siffror. Du har skrivit 9. Lägg till en siffra till."
Det allmänna meddelandet talar om vad som är fel men inte varför eller hur det rättas. Det tydliga meddelandet talar om problemet, varför det uppstod och exakt vad användaren ska göra. Det tydliga meddelandet tar något längre tid att läsa men sparar användaren flera minuters irritation.
Ett felmeddelande som går att agera på innehåller instruktioner. "Lösenord måste innehålla minst en siffra" talar om vad som saknas. "Lösenord måste innehålla minst en siffra. Gå tillbaka till lösenordsfältet och lägg till en siffra." talar om vad användaren ska göra. I formulär är instruktionen oftast självklar (gå tillbaka till fältet), men att skriva ut den hjälper personer som inte är vana vid formulär eller som använder hjälpmedel.
Använd enkelt språk. Inte "Felaktigt format på postnummer." I stället: "Postnummer består av 5 siffror. Du har skrivit bokstäver." Inte "Ogiltigt e-postformat." I stället: "E-postadresser behöver ett @-tecken och en domän (exempel: namn@foretag.se)."
Placering som gör fel omöjliga att missa
Ett felmeddelande som placeras långt från fältet som orsakade det är lätt att missa. När någon fyller i ett formulär med många fält fokuserar hen på ett fält i taget. Ett felmeddelande som dyker upp längst ned i formuläret medan hen fortfarande tittar på överdelen blir osett.
Den bästa placeringen för ett felmeddelande är direkt under eller bredvid fältet med felet. När användaren går till nästa fält eller försöker skicka dyker ett felmeddelande upp direkt under det fält hen just fyllde i. Hen kan inte undvika att se det eftersom det visas där hen väntar sig nästa åtgärd.
För en sammanfattning av valideringen (som listar alla fel på en gång efter inskick) placerar du den högst upp i formuläret. Då får användaren en fullständig överblick över alla problem. När hen sedan rullar ned visas de enskilda felen igen vid varje fält som behöver rättas. Det här dubbla sättet tjänar två syften: det visar hela omfattningen av det som ska rättas, och det påminner användaren medan hen arbetar sig genom varje fält.
Använd aldrig toast-meddelanden för fel i formulär. En toast är en avisering som visas kort i hörnet av skärmen och sedan försvinner. För formulär är det den sämsta placeringen som finns. Felet visas långt från fältet som orsakade det. Det försvinner innan användaren hinner läsa det. Det skapar ett avbrott mellan problemet och platsen där det ska rättas. Om ett felmeddelande måste försvinna ska det ske först efter att användaren har rättat fältet.
Visuell design av felmeddelanden
Enbart färg räcker inte för att förmedla ett fel. Någon med färgblindhet kanske inte ser den röda färg som signalerar ett fel. En mycket liten felikon kan missas av någon med nedsatt syn. Lita på flera signaler: färg plus text plus ikon.
En röd kantlinje runt fältet. En röd eller orange ikon bredvid felmeddelandet. Text som tydligt anger problemet. Alla tre tillsammans skapar ett felläge som nästan alla kan känna igen.
Teckenstorleken spelar roll. Texten i felmeddelandet ska ha samma storlek som fältets etikett. Om felmeddelandet är mindre kan människor missa det eller tro att det är mindre viktigt än det är. Felmeddelandet förtjänar samma visuella vikt som etiketten.
Etiketten på det felaktiga fältet kan också ändras. Etiketttexten kan bli röd eller fet. Det skapar ännu en visuell signal som hjälper användaren att snabbt skumma formuläret och hitta fältet som behöver uppmärksamhet.
Ton och artighet i felmeddelanden
Felmeddelanden ska låta som att du hjälper någon, inte som att du skyller på hen. Undvik ord som låter hårda eller anklagande.
Hårt: "Du angav en ogiltig e-postadress."
Hjälpsamt: "E-postadresser behöver ett @-tecken. Kontrollera det du skrev och försök igen."
Hårt: "Lösenordet är för svagt."
Hjälpsamt: "Lösenord behöver minst 8 tecken. Längre lösenord är säkrare."
Hårt: "Du glömde fylla i det här fältet."
Hjälpsamt: "Det här fältet är obligatoriskt. Berätta vad du tycker."
En hjälpsam ton erkänner misstaget utan att få personen att må dåligt. Den förklarar varför regeln finns (när det hjälper). Den går vidare utan att älta felet.
Vanliga misstag i felmeddelanden
Det vanligaste misstaget är att vara för vag. "Ogiltig inmatning" säger användaren ingenting. "Något gick fel" är lika oanvändbart. Var tydlig med vad problemet är.
Ett andra misstag är att använda tekniskt språk. "Regex mismatch" eller "Validation failed" kan betyda något för tekniker, men vanliga människor har ingen aning om vad termerna betyder. Översätt tekniska fel till enkelt språk.
Ett tredje misstag är att visa för många fel på en gång. Om ett formulär har 20 fält och alla 20 visar fel blir användaren överväldigad. Prioritera vilka fel som är kritiska (som ett obligatoriskt fält som är tomt) och visa dem först. Sekundära fel (som ett fält med ett formatfel som är valfritt) kan visas i andra hand.
Ett fjärde misstag är felmeddelanden som upprepar etiketten utan att tillföra ny information. Etiketten säger "E-postadress." Felmeddelandet säger "E-postadressen är ogiltig." Användaren vet redan vilket fält som har problemet (hen ser den röda kantlinjen), men vet fortfarande inte varför det är ogiltigt. Felmeddelandet ska tillföra information, inte upprepa etiketten.
Ett femte misstag är att inte erbjuda en väg till rättelse. "Lösenordet uppfyller inte kraven" talar om att något är fel men inte vilka kraven är. "Lösenordet uppfyller inte kraven. Lösenord behöver minst 8 tecken och en siffra" talar om vad som ska rättas.
Så hjälper WEMASY dig att skapa tydliga felmeddelanden
WEMASY:s formulärbyggare har fördefinierade felmeddelanden för vanliga fälttyper. E-postfält visar "E-postadresser behöver ett @-tecken" när formatet är fel. Telefonfält visar "Telefonnummer behöver 10 siffror" när längden är fel. Lösenordsfält visar krav på lösenordsstyrka medan användaren skriver. De här meddelandena är tydliga, specifika och hjälpsamma som standard.
Du kan anpassa felmeddelanden efter ditt varumärkes ton. Ändra meddelandet från "E-postadresser behöver ett @-tecken" till "Hoppsan, det där ser inte ut som en e-postadress. Försök igen?" Tonen ändras men tydligheten finns kvar. Du styr hur meddelandet låter utan att offra klarheten.
För egen validering (fält med särskilda regler som är unika för ditt formulär) kan du skriva dina egna felmeddelanden direkt i formulärbyggaren. Systemet hjälper dig att placera meddelandet bredvid fältet, visa det vid rätt tidpunkt (medan du fyller i eller vid inskick) och formge det så att det passar din formulärdesign.
Validering i realtid är inbyggd, så felmeddelanden kan visas medan användare skriver, inte bara efter att de har skickat. Det fångar misstag tidigt och förhindrar irritationen i att fylla i ett helt formulär bara för att upptäcka problem i slutet.
Se vilka formulärfunktioner som ingår i din WEMASY-plan.