För att diagnostisera en otydlig app granskar du dess skärmar, kontroller och svar medan någon försöker utföra en uppgift som appen stöder. Leta efter den första punkt där nästa åtgärd blir oklar. Jämför vad personen förväntar sig med vad appen gör och meddelar. En misslyckad sparning eller en saknad funktion kräver en annan lösning än en otydlig etikett eller väg.
Föreställ dig någon som försöker ändra en befintlig bokning. Personen öppnar flera menyer, återgår till startskärmen och frågar en kollega. Den sekvensen är en utgångspunkt för en observation. Den kan inte ensam förklara om personen senare avinstallerar appen eller vilken skärm som behöver utformas om.
Varför tappar människor bort nästa steg?
Människor kan förstå målet och ändå missa en otydlig åtgärd eller respons. Vi letar efter den första synliga avvikelsen mellan uppgiften de avser att utföra och skärmen de möter. Håll förklaringen öppen tills du har kontrollerat hur åtgärden utförs. Det som ser ut som ett navigeringsproblem kan också vara en misslyckad begäran eller ett resultat som produkten inte stöder.
Formuleringen antyder en annan åtgärd. En person kan förvänta sig ytterligare en granskningsskärm efter att ha tryckt på Fortsätt, medan appen omedelbart skickar en begäran. Apples vägledning för knappar rekommenderar att syftet görs tydligt. Jämför förväntningen med den faktiska effekten innan du väljer en ersättande etikett.
Resultatet förblir osäkert. Någon trycker igen eftersom personen inte kan avgöra om appen tog emot begäran. Granska vad som faktiskt sparades och vad skärmen meddelade. En saknad bekräftelse och en misslyckad åtgärd kräver olika lösningar.
Vägledning om inmatning kommer efter misstaget. Kontrollera om fältet förklarar vilket värde som behövs.
För webbinnehåll kräver W3C:s kriterium för etiketter eller instruktioner att sådana finns när innehållet kräver inmatning. Använd den referensen för webbskärmar inuti en app. Plattformsspecifika appar behöver en separat plattformsgranskning.
Vägen förlorar sitt sammanhang. Någon återgår från en detaljskärm och kan inte hitta objektet som personen höll på att ändra. Dokumentera utgångspunkten, den valda åtgärden och den resulterande skärmen. Beskriv den första förvirrande övergången tillräckligt precist för att den ska kunna reproduceras.
Hur diagnostiserar du en otydlig app?
Börja med ett resultat som stöds och ett jämförbart utgångstillstånd. Använd ett testkonto och säkra testdata för åtgärder som skickar, debiterar, raderar eller påverkar någon annan. Skriv målet utan att namnge menyn eller kontrollen som leder dit. Du vill ta reda på vad personen kan hitta och förstå innan du ger en förklaring.
- Definiera slutförandet. Är det avsedda resultatet av en bokningsändring en inskickad begäran eller en bekräftad ny bokning? Kontrollera vilket resultat den här versionen och det här kontot kan stödja.
- Dokumentera utgångstillståndet. Notera appversion, enhet, språk, behörigheter och om bokningen redan finns. En administratörs konto kan visa en annan väg än en kunds konto.
- Observera utan att namnge kontrollen. Be personen försöka nå målet. Dokumentera vilken skärm personen väljer, vilken etikett personen läser och vad personen förväntar sig. Om du hjälper till ska du notera hjälpen. Ett senare slutförande raderar den inte.
- Kontrollera resultatet separat. Jämför den synliga responsen med den sparade bokningen. Öppna den igen i testkontot eller kontrollera leverantörens testpost. Ett tryck eller en skärm som ser framgångsrik ut bevisar inte att den avsedda uppdateringen genomfördes.
Om du granskar appen ensam ska du dokumentera vad du kan reproducera och hålla den begränsningen synlig. Din kunskap om produkten förändrar uppgiften. En senare observation med någon som inte känner till den ger andra belägg.
Gå igenom denna fiktiva bokningsuppgift
Tänk dig en påhittad app för att boka kurspass där någon kan begära ett annat pass. Leverantören måste godkänna begäran innan bokningen ändras. Anteckningarna nedan illustrerar hur ett missförstånd kan undersökas. Vi har inte använt en verklig app, ett verkligt konto eller en verklig deltagare för exemplet, och vi har inte testat den föreslagna formuleringen.
| Observation | Anteckning |
|---|---|
| Avsedd uppgift | Flytta en befintlig bokning av ett kurspass till ett annat pass. |
| Åtgärd och exakt etikett | Personen trycker på Ändra bokning; knappen skickar en begäran. |
| Förväntat resultat | Personen tror att det nya passet redan är bokat. |
| Faktiskt tillstånd | Den ursprungliga bokningen kvarstår medan begäran väntar på godkännande. |
| Föreslagen kontroll | Prova Begär en ändring och ett meddelande som säger att begäran har skickats. |
Den observerade avvikelsen gäller vad åtgärden betyder. En annan etikett är en hypotes som ska prövas mot hur åtgärden faktiskt utförs. Om begäran aldrig når leverantören ska du även undersöka den misslyckade åtgärden. Om omedelbar bekräftelse är avgörande för produkten är det ett separat produktbeslut, inte något som en knappetikett kan tillhandahålla.
Skriv en observation före dess tolkning. “Öppnade bokningen, tryckte på Ändra bokning och förväntade sig en bekräftelse” beskriver ett beteende i den här fiktiva övningen. “Gränssnittet är dåligt” hoppar över frågan du fortfarande behöver besvara.
Gör den minsta ändringen som besvarar observationen
Välj en lösning som hanterar den dokumenterade avvikelsen och bevarar den avsedda åtgärden. Börja med formulering, instruktioner eller återkoppling när det är dessa delar som är osäkra. En ändrad navigeringsstruktur eller en större omdesign behöver ett skäl som grundar sig i uppgiften. Håll funktionsfel synliga så att en tydligare förklaring inte döljer en åtgärd som fortfarande misslyckas.
-
Prova ett fokuserat utkast. Visa en föreslagen åtgärdsetikett och det resulterande tillståndet i ett klickbart utkast för den fiktiva bokningen. Våra UX-granskningar och prototyper för appar följer den här sekvensen från uppgift till prototyp. Jämför vad personen förväntar sig före trycket med tillståndet personen känner igen efteråt. Beskriv inte den föreslagna etiketten som en bevisad förbättring.
-
Kontrollera en felväg. W3C:s kriterium för felidentifiering i webbinnehåll kräver att ett automatiskt upptäckt inmatningsfel identifierar det berörda objektet och beskriver felet i text. Enbart en färgad kontur lämnar den förklaringen ute. Plattformsspecifika kontroller och en fullständig tillgänglighetsgranskning kräver egna plattformskontroller.
-
Kontrollera responsen på skärmen och med hjälpmedelsteknik. För webbinnehåll behandlar W3C:s kriterium för statusmeddelanden hur definierade statusändringar görs tillgängliga för hjälpmedelsteknik utan att flytta fokus från den aktuella kontrollen. Kontrollera vad som visas på skärmen och vad hjälpmedel kan upptäcka. En skärmläsare är exempelvis programvara som kan läsa upp innehåll i gränssnittet. Det valda kriteriet certifierar inte appen, anger inget mål för svarstid och reparerar inte en långsam åtgärd.
-
Följ webbövergången. När samma konto eller bokningsväg går över till en webbsida ska den övergången ingå i testet. Utveckling av webbplatser och webbappar bör bevara uppgiftens formulering och faktiska tillstånd över den gränsen.
Vad bör du kontrollera efter ändringen?
Upprepa samma avsedda uppgift från ett jämförbart tillstånd och dokumentera vad som hände. Håll appversion, enhet, språk och hjälp synliga bredvid resultatet. En användbar jämförelse gäller uppgiften du observerade: om personen hittade åtgärden, förstod dess effekt och kände igen det faktiska resultatet. Lämna bredare affärsmässiga slutsatser öppna tills du har belägg för dem.
Dokumentera slutförande och hjälp tillsammans, den första felaktiga vägen, inmatningsfel som personen inte kunde tolka och om personen misstog en begäran för en bekräftelse. Upprepa relevanta kontroller med språket och tillgänglighetsinställningen som du granskar. Granska längre etiketter och den information som är tillgänglig genom den inställningen i stället för att anta att den engelska skärmen representerar alla versioner.
Om du redan registrerar appåtgärder, exempelvis att en begäran om bokningsändring startar eller når leverantören, ska du kontrollera att posterna motsvarar dessa faktiska tillstånd. Följ förändringar i supportfrågor för samma väg. Uteblivna appnedladdningar är ett separat problem med att nå nya användare. Vår guide till en app som inte får några nedladdningar börjar innan någon öppnar produkten.
En lyckad upprepning kan beskriva den observationen. Den kan inte fastställa varför människor avinstallerar appen eller tillskriva lösningen en förändring i hur många användare som stannar kvar. Dokumentera nästa olösta fråga tillsammans med personen som ansvarar för att kontrollera den.
Där kommer vi in
Vi börjar med uppgiften som stöds, den första otydliga övergången och de belägg som behövs för att välja en lösning. Vi kan omvandla detta till en prototyp, kontrollera den implementerade vägen och inkludera dess webbmotsvarighet. Ta med en beskrivning av uppgiften och den punkt där den stannade till ett projektsamtal. Ta bort kundnamn och andra personuppgifter från alla exempel du delar.
