Felförebyggande

Felförebyggande är designmetoden att strukturera ett gränssnitt så att misstag är svåra eller omöjliga att göra, snarare än att förlita sig på bra felmeddelanden i efterhand. Det är en av de äldsta principerna inom användbarhet, som förekommer i Nielsens heuristik och i tidigare litteratur om mänskliga faktorer, och den vilar på observationen att ett undviket misstag inte kostar något medan ett korrigerat misstag kostar tid, uppmärksamhet och ofta förtroende.

Teknikerna kan delas in i några få igenkännbara grupper. Begränsningar förhindrar helt ogiltig inmatning, som när en datumväljare gör ett omöjligt datum ovalbart eller ett numeriskt fält endast accepterar siffror. Förnuftiga standardvärden minskar antalet beslut där ett felaktigt val är möjligt. Tydliga formateringskrav som visas före inmatning, snarare än efter avslag, undviker frustrationen med att gissa vad ett fält vill ha. Bekräftelsesteg skyddar oåterkalleliga åtgärder. Ångra, där det kan erbjudas, är överlägset bekräftelse eftersom det inte avbryter det vanliga fallet där användaren har rätt.

Arbetet med mänskliga faktorer skiljer mellan felsteg och misstag, och skillnaden förändrar lösningen. Ett felsteg är ett utförandemisslyckande, där personen avsåg rätt sak och gjorde fel: felstavning, klickande på intilliggande kontroll, missande av ett litet mål. Dessa åtgärdas genom fysisk design, genom större mål, tillräckligt avstånd, separering av destruktiva och konstruktiva handlingar och förlåtande hantering av indata. Ett misstag är ett planeringsmisslyckande, där personen gjorde exakt vad de avsåg och deras avsikt var fel för situationen. Dessa kräver bättre information, tydligare modeller och mer informativ feedback, och ingen mängd målstorleksbestämning kommer att hjälpa.

Valideringstidpunkten är ett återkommande praktiskt beslut. Validering vid inlämning tvingar användaren att korrigera problem långt efter att de skapats, ur sitt sammanhang och ofta efter att sidan har återgivits och förlorat sina poster. Validering vid varje tangenttryckning flaggar fel innan inmatningen är klar och känns fientligt. Att validera när ett fält förlorar fokus, samtidigt som man bekräftar giltiga poster positivt, är det mönster som testas bäst i de flesta sammanhang, och att bevara all inmatad data vid fel är inte förhandlingsbart oavsett tidpunkt.

Felförebyggande åtgärder måste också ta hänsyn till vad som händer när själva systemet slutar fungera, eftersom inte alla fel härrör från användaren. Betalningsmisslyckanden, timeouts, utgångna sessioner och förlorade anslutningar är alla situationer där personen inte gjorde något fel och behöver en tydlig väg framåt snarare än ett meddelande som beskriver ett internt tillstånd. Att bevara arbete efter en sessions utgång, försöka igen transparent där det är säkert och förklara vad man ska göra härnäst är motsvarigheten till felförebyggande åtgärder för systemfel.

Felförebyggande åtgärder gäller även operativa beslut kring en produkt, inte bara gränssnittet. System som tillåter att ett konto stängs med ett utestående saldo, att en beställning görs på en vara som inte kan levereras till den adressen, eller att en tid bokas utanför öppettiderna skapar fel genom affärsregler snarare än genom interaktionsdesign, och de resulterande problemen dyker upp som kundklagomål snarare än som användbarhetsresultat. Att identifiera dessa kräver att man spårar begränsningarna för den faktiska operationen och bekräftar att gränssnittet tillämpar dem så snart informationen är tillgänglig, snarare än att acceptera inmatningen och misslyckas senare, vilket är det mönster som producerar det dyraste återställningsarbetet.

Kommersiellt sett är de flöden där förebyggande lönar sig bäst de som är högvärdiga och ofta övergivna: utcheckning, registrering, ansökningsblanketter och alla processer som en person slutför en gång och inte enkelt kan återuppta. Det är i dessa flöden som ett enda fel ofta avslutar sessionen helt. Att identifiera var fel faktiskt uppstår, med hjälp av formulärfältsanalys och sessionsinspelningar, är standarddiagnostiskt arbete i en UX revision, och de resulterande korrigeringarna är bland de mest pålitliga sakerna i en CRO-tjänst eftersläpning eftersom de adresserar ett dokumenterat misslyckande snarare än en hypotes om preferens.