Överlämningen från design till utveckling blir ofta ofullständig när den bara visar välfyllda skärmar. Den första användaren kanske inte har några projekt, nätverket kan vara långsamt och formuläret kan innehålla fel. Om dessa lägen lämnas öppna måste utvecklaren fatta produktbeslut under implementationen, utan att veta vilken information och återhämtning användaren faktiskt behöver.
I ett påhittat system för bokning av verkstadsutrustning visar designen en lista med lediga objekt. Men vad visas innan första objektet lagts in, när sökningen inte hittar något och när bokningstjänsten ligger nere? Exemplet är en tänkt designuppgift, inte ett kundcase. De tre tillstånden kan se tomma ut men kräver helt olika handlingar.
Beskriv orsaken bakom varje tom vy
Skilj på att inga data har skapats, att filtren inte ger träff och att användaren saknar behörighet. Skriv vilken förklaring som är tillåten att visa och vad personen kan göra. Ett förslag att skapa första objektet passar inte om rollen bara får läsa. Ett filter kan däremot återställas utan att användaren behöver kontakta supporten.
Bestäm vad som visas medan data laddas och när väntan blir ovanligt lång. En platshållare kan ge struktur men bör inte dölja ett permanent fel. Ange hur tidigare data märks om de ligger kvar under uppdatering. Ett tomt utrymme eller siffran noll ska inte användas som standard för alla tekniska problem, eftersom betydelsen då blir otydlig.
Skriv fel utifrån det användaren behöver göra
Felmeddelandet ska tala om vad som inte kunde genomföras och om något ändå sparades. Det kan handla om ett enskilt fält, hela formuläret eller en extern tjänst. Undvik att lägga ansvaret på användaren när felet ligger i systemet. Tekniska detaljer som behövs för support kan finnas som en avgränsad referens utan att ersätta förklaringen.
Nästa handling måste motsvara systemets verkliga förmåga. En knapp för nytt försök är bara användbar om operationen kan upprepas utan oönskad dubblering. Om resultatet är okänt kan en statuskontroll vara bättre än att skicka samma bokning igen. Beskriv sådana skillnader i överlämningen så att gränssnittet inte lovar en återhämtning som backend saknar.
Ange vilket arbete som ska finnas kvar
Vid ett misslyckat formulär bör korrekt inmatning normalt finnas kvar inom produktens regler för lokal lagring och åtkomst. Beskriv vad som händer med bilagor, stegvis navigering och utkast när sessionen går ut. Om personen behöver logga in igen ska återkomsten vara planerad. Att rensa hela formuläret är ett produktbeslut med konsekvenser, inte en neutral teknisk standard.
Tillgänglighet behöver vara konkret även i felstaten. Ange hur fälten kopplas till sina meddelanden, vart fokus går och hur en statusändring blir begriplig med hjälpmedel. Säkerställ läsbar text och tillräckliga tryckytor. Använd inte bara rött för fel eller grönt för framgång; text och struktur ska också bära innebörden.
Granska överlämningen genom en besvärlig resa
Låt en person söka utan träff, ändra filter, fylla i ett formulär och drabbas av ett avbrott vid inskickningen. Kontrollera vad som är sparat, vilken nästa handling som erbjuds och om resultatet blir rätt efter återhämtning. Prova samma flöde på en smal skärm och med tangentbord. Det visar luckor som separata tillståndsbilder lätt missar.
Brainbaby Labs kan hjälpa till med produktdesign och utveckling av webb- och mobilappar. Dela den viktigaste användarresan, nuvarande skisser och några kända felsituationer. Då går det att formulera en överlämning som omfattar både det önskade resultatet och vägen tillbaka när något avviker, med tydliga kriterier för implementation och granskning.