Uklar app? Find stedet, hvor brugerne mister tråden

For at diagnosticere en uklar app skal du se på dens skærme, betjeningselementer og reaktioner, mens en person forsøger at udføre en opgave, som appen understøtter. Hold øje med det første sted, hvor den næste handling bliver uklar. Sammenlign personens forventning med det, appen gør og oplyser. En lagring, der fejler, eller en manglende funktion kræver en anden løsning end en uklar etiket eller rute.

Forestil dig en person, der prøver at ændre en eksisterende booking. Personen åbner flere menuer, vender tilbage til startskærmen og spørger en kollega. Det forløb er et udgangspunkt for en observation. Det kan ikke i sig selv forklare, om personen senere afinstallerer appen, eller hvilken skærm der kræver et redesign.

Hvorfor mister folk det næste trin?

Folk kan forstå målet og stadig overse en uklar handling eller reaktion. Vi leder efter den første synlige uoverensstemmelse mellem deres ønskede opgave og den skærm, de møder. Hold forklaringen åben, indtil du har kontrolleret, hvordan handlingen udføres. Det, der ligner et navigationsproblem, kan også være en mislykket anmodning eller et resultat, som produktet ikke understøtter.

Ordlyden antyder en anden handling. En person kan forvente endnu en kontrolskærm efter at have trykket på Fortsæt, mens appen straks sender en anmodning. Apples vejledning om knapper anbefaler, at formålet gøres tydeligt. Sammenlign forventningen med den faktiske virkning, før du vælger en ny etiket.

Resultatet forbliver usikkert. En person trykker igen, fordi vedkommende ikke kan se, om appen accepterede anmodningen. Undersøg, hvad der faktisk blev gemt, og hvad skærmen oplyste. En manglende bekræftelse og en handling, der fejlede, kræver forskellige løsninger.

Vejledningen om input kommer efter fejlen. Kontroller, om feltet forklarer, hvilken værdi det kræver.

For webindhold kræver W3C’s kriterium om etiketter eller instruktioner etiketter eller instruktioner, når indholdet kræver input. Brug denne reference til webskærme i en app. Native apps kræver en særskilt gennemgang efter platformens retningslinjer.

Ruten mister sin kontekst. En person vender tilbage fra en detaljeskærm og kan ikke finde det element igen, som vedkommende var ved at ændre. Registrer udgangspunktet, den valgte handling og den efterfølgende skærm. Beskriv den første uklare overgang præcist nok til, at den kan reproduceres.

Hvordan diagnosticerer du en uklar app?

Begynd med et understøttet resultat og en sammenlignelig starttilstand. Brug en testkonto og sikre testdata til handlinger, der sender, opkræver, sletter eller påvirker andre. Skriv målet uden at nævne den menu eller det betjeningselement, der fører dertil. Du vil finde ud af, hvad personen kan finde og forstå, før du giver en forklaring.

1. Definer fuldførelsen. Er det ønskede resultat af en bookingændring en indsendt anmodning eller en bekræftet ny booking? Kontroller, hvilket resultat denne version og konto understøtter.
2. Registrer starttilstanden. Noter appversion, enhed, sprog, tilladelser, og om bookingen allerede findes. En administrators konto kan vise en anden rute end en kundes konto.
3. Observer uden at navngive betjeningselementet. Bed personen om at forsøge at nå målet. Registrer den valgte skærm, den læste etiket og personens forventning. Hvis du hjælper, skal du notere hjælpen. En senere fuldførelse får den ikke til at forsvinde.
4. Kontroller resultatet separat. Sammenlign den synlige reaktion med den gemte booking. Åbn den igen på testkontoen, eller kontroller udbyderens testregistrering. Et tryk eller en skærm, der ser ud til at vise succes, fastslår ikke, at den ønskede opdatering skete.

Hvis du undersøger appen alene, skal du registrere det, du kan reproducere, og gøre begrænsningen synlig. Dit kendskab til produktet ændrer opgaven. En senere observation med en person, der ikke kender det, giver en anden type evidens.

Gennemgå denne fiktive bookingopgave

Forestil dig en opdigtet app til booking af undervisning, hvor en person kan anmode om en anden session. Udbyderen skal acceptere anmodningen, før bookingen ændres. Noterne nedenfor illustrerer, hvordan en misforståelse kan undersøges. Vi har ikke brugt en aktiv app, konto eller deltager til dette eksempel, og vi har ikke testet den foreslåede ordlyd.

Den observerede uoverensstemmelse handler om handlingens betydning. En anden etiket er en hypotese, der skal testes i forhold til den faktiske udførelse af handlingen. Hvis anmodningen aldrig når frem til udbyderen, skal den fejlede handling også undersøges. Hvis øjeblikkelig bekræftelse er afgørende for produktet, er det en særskilt produktbeslutning, ikke noget en knapetiket kan levere.

Skriv en observation før fortolkningen. “Åbnede bookingen, trykkede på Skift booking og forventede en bekræftelse” beskriver adfærd i denne fiktive øvelse. “Grænsefladen er dårlig” springer det spørgsmål over, som du stadig skal besvare.

Foretag den mindste ændring, der besvarer observationen

Vælg en løsning, der adresserer den registrerede uoverensstemmelse og bevarer den ønskede handling. Begynd med ordlyd, instruktioner eller feedback, når det er de usikre dele. En ændret navigationsstruktur eller et bredere redesign kræver en begrundelse med udgangspunkt i opgaven. Hold funktionsfejl synlige, så en tydeligere forklaring ikke skjuler en handling, der stadig fejler.

1. Prøv et fokuseret udkast. Vis til den fiktive booking en foreslået handlingsetiket og efterfølgende tilstand i et klikbart udkast. Vores app-UX-audits og prototyper følger denne rækkefølge fra opgave til prototype. Sammenlign personens forventning før trykket med den tilstand, vedkommende genkender bagefter. Beskriv ikke den foreslåede etiket som en dokumenteret forbedring.

2. Kontroller et fejlforløb. W3C’s kriterium om fejlidentifikation for webindhold kræver, at en automatisk registreret inputfejl identificerer det berørte element og beskriver fejlen med tekst. En farvet kant alene giver ikke denne forklaring. Native betjeningselementer og en fuldstændig tilgængelighedsgennemgang kræver særskilte kontroller efter platformens retningslinjer.

3. Kontroller reaktionen på skærmen og med kompenserende teknologi. For webindhold omhandler W3C’s kriterium om statusmeddelelser, at definerede statusændringer gøres tilgængelige for kompenserende teknologi uden at flytte fokus væk fra det aktuelle betjeningselement. Kontroller, hvad der vises på skærmen, og hvad hjælpemidler kan registrere. En skærmlæser er eksempelvis software, der kan læse indhold i en grænseflade højt. Dette udvalgte kriterium certificerer ikke appen, fastsætter ikke et mål for svartid og reparerer ikke en langsom handling.

4. Følg overgangen til web. Når den samme konto eller bookingrute fortsætter på en webside, skal overgangen indgå i testen. Udvikling af websites og webapps bør bevare opgavens ordlyd og faktiske tilstand på tværs af denne grænse.

Hvad bør du kontrollere efter ændringen?

Gentag den samme ønskede opgave fra en sammenlignelig tilstand, og registrer, hvad der skete. Vis appversion, enhed, sprog og hjælp sammen med resultatet. En nyttig sammenligning vedrører den opgave, du observerede: om personen fandt handlingen, forstod dens virkning og genkendte det faktiske resultat. Lad bredere forretningsmæssige konklusioner stå åbne, indtil du har evidens for dem.

Registrer fuldførelse og hjælp sammen, den første forkerte afstikker, inputfejl, som personen ikke kunne fortolke, og om en anmodning blev forvekslet med en bekræftelse. Gentag relevante kontroller med det sprog og den tilgængelighedsopsætning, du gennemgår. Undersøg længere etiketter og de oplysninger, som opsætningen stiller til rådighed, i stedet for at antage, at den engelske skærm repræsenterer alle versioner.

Hvis du allerede registrerer apphandlinger, såsom at en anmodning om bookingændring starter eller når frem til udbyderen, skal du kontrollere, at registreringerne svarer til de faktiske tilstande. Sammenhold ændringer i supportspørgsmål med den samme rute. Manglende appdownloads er et særskilt problem med at tiltrække brugere. Vores guide til en app, der ikke får downloads begynder, før nogen åbner produktet.

En vellykket gentagelse kan beskrive denne observation. Den kan ikke fastslå, hvorfor folk afinstallerer appen, eller tilskrive løsningen en ændring i fastholdelsen. Registrer det næste uafklarede spørgsmål sammen med den person, der er ansvarlig for at undersøge det.

Her kommer vi ind i billedet

Vi begynder med den understøttede opgave, den første uklare overgang og den evidens, der kræves for at vælge en løsning. Vi kan omsætte det til en prototype, kontrollere den implementerede rute og medtage dens webmodstykke. Medbring en beskrivelse af opgaven og stedet, hvor den gik i stå, til en projektsamtale. Fjern kundenavne og andre personoplysninger fra alle eksempler, du deler.

← Alle artikler