Om een onduidelijke app te diagnosticeren, bekijk je de schermen, bedieningselementen en reacties terwijl iemand een taak probeert uit te voeren die de app ondersteunt. Let op het eerste punt waarop de volgende actie onduidelijk wordt. Vergelijk wat de persoon verwacht met wat de app doet en meldt. Een mislukte opslagactie of een ontbrekende functie vraagt om een andere oplossing dan een onduidelijk label of pad.
Stel je voor dat iemand een bestaande boeking probeert te wijzigen. Diegene opent verschillende menu’s, keert terug naar het beginscherm en vraagt een collega om hulp. Die reeks is een startpunt voor een observatie. Op zichzelf kan ze niet verklaren of die persoon de app later verwijdert of welk scherm een herontwerp nodig heeft.
Waarom raken mensen de volgende stap kwijt?
Mensen kunnen het doel begrijpen en toch een onduidelijke actie of reactie missen. We zoeken naar de eerste zichtbare discrepantie tussen de taak die ze willen uitvoeren en het scherm dat ze tegenkomen. Houd de verklaring open totdat je de bewerking hebt gecontroleerd. Wat op een navigatieprobleem lijkt, kan ook een mislukt verzoek zijn of een resultaat dat het product niet ondersteunt.
De formulering suggereert een andere actie. Iemand kan na het tikken op Doorgaan nog een controlescherm verwachten, terwijl de app het verzoek meteen indient. De richtlijnen van Apple voor knoppen adviseren om het doel duidelijk te maken. Vergelijk de verwachting met het werkelijke effect voordat je een vervangend label kiest.
Het resultaat blijft onzeker. Iemand tikt opnieuw omdat diegene niet kan zien of de app het verzoek heeft geaccepteerd. Controleer wat werkelijk is opgeslagen en wat het scherm meldde. Een ontbrekende bevestiging en een mislukte bewerking vragen om verschillende oplossingen.
Invoerinstructies verschijnen pas na de fout. Controleer of het veld uitlegt welke waarde nodig is.
Voor webcontent vereist het criterium van W3C over labels of instructies labels of instructies wanneer content invoer vereist. Gebruik die referentie voor webschermen binnen een app. Native apps vereisen een afzonderlijke platformbeoordeling.
Het pad verliest zijn context. Iemand keert terug van een detailscherm en kan het item dat diegene wijzigde niet terugvinden. Leg dat startpunt, de gekozen actie en het resulterende scherm vast. Beschrijf de eerste verwarrende overgang precies genoeg om die te reproduceren.
Hoe diagnosticeer je een onduidelijke app?
Begin met een ondersteund resultaat en een vergelijkbare uitgangssituatie. Gebruik een testaccount en veilige testgegevens voor acties die iets verzenden, kosten in rekening brengen, verwijderen of iemand anders beïnvloeden. Beschrijf het doel zonder het menu of bedieningselement te noemen dat ernaartoe leidt. Je wilt ontdekken wat de persoon kan vinden en begrijpen voordat je uitleg geeft.
- Definieer voltooiing. Is bij een boekingswijziging het beoogde resultaat een ingediend verzoek of een bevestigde nieuwe boeking? Controleer welk resultaat deze versie en dit account kunnen ondersteunen.
- Leg de uitgangssituatie vast. Noteer de appversie, het apparaat, de taal, de machtigingen en of de boeking al bestaat. Het account van een beheerder kan een ander pad tonen dan het account van een klant.
- Observeer zonder het bedieningselement te noemen. Vraag de persoon te proberen het doel te bereiken. Leg vast welk scherm diegene kiest, welk label diegene leest en wat diegene verwacht. Als je helpt, noteer dan die hulp. Latere voltooiing maakt die hulp niet ongedaan.
- Controleer het resultaat afzonderlijk. Vergelijk de zichtbare reactie met de opgeslagen boeking. Open deze opnieuw in het testaccount of controleer het testrecord van de aanbieder. Een tik of een scherm dat op succes lijkt, bewijst niet dat de beoogde wijziging heeft plaatsgevonden.
Als je de app alleen inspecteert, leg dan vast wat je kunt reproduceren en houd die beperking zichtbaar. Je kennis van het product verandert de taak. Een latere observatie met iemand die het product niet kent, levert ander bewijs op.
Werk deze fictieve boekingstaak door
Denk aan een verzonnen app voor het boeken van lessen waarmee iemand om een andere sessie kan vragen. De aanbieder moet dat verzoek accepteren voordat de boeking verandert. De onderstaande notities illustreren hoe je een misverstand kunt onderzoeken. Voor dit voorbeeld hebben we geen echte app, account of deelnemer gebruikt en we hebben de voorgestelde formulering niet getest.
| Observatie | Notitie |
|---|---|
| Beoogde taak | Verplaats een bestaande boeking voor een les naar een andere sessie. |
| Actie en exact label | De persoon tikt op Boeking wijzigen; de knop verzendt een verzoek. |
| Verwacht resultaat | De persoon denkt dat de nieuwe sessie al is geboekt. |
| Werkelijke status | De oorspronkelijke boeking blijft staan terwijl het verzoek op acceptatie wacht. |
| Voorgestelde controle | Probeer Wijziging aanvragen en een bericht dat zegt dat het verzoek is verzonden. |
De waargenomen discrepantie betreft de betekenis van de actie. Een ander label is een hypothese die je tegenover de werkelijke bewerking moet toetsen. Als het verzoek de aanbieder nooit bereikt, onderzoek dan ook de mislukte bewerking. Als onmiddellijke bevestiging essentieel is voor het product, is dat een afzonderlijke productbeslissing en niet iets wat een knoplabel kan leveren.
Schrijf een observatie op vóór de interpretatie ervan. “Opende de boeking, tikte op Boeking wijzigen en verwachtte bevestiging” beschrijft gedrag in deze fictieve oefening. “De interface is slecht” slaat de vraag over die je nog moet beantwoorden.
Breng de kleinste wijziging aan die de observatie beantwoordt
Kies een oplossing die de vastgelegde discrepantie aanpakt en de beoogde bewerking intact laat. Begin met formulering, instructies of feedback wanneer daar de onzekerheid zit. Een gewijzigde navigatiestructuur of een breder herontwerp vereist een reden die in de taak is gefundeerd. Houd functionele fouten zichtbaar, zodat een duidelijkere uitleg een bewerking die nog steeds mislukt niet verbergt.
-
Probeer een gericht concept. Toon voor de fictieve boeking een voorgesteld actielabel en de resulterende status in een aanklikbaar concept. Onze app-UX-audits en prototypes volgen deze reeks van taak naar prototype. Vergelijk wat de persoon vóór het tikken verwacht met de status die diegene achteraf herkent. Beschrijf het voorgestelde label niet als een bewezen verbetering.
-
Controleer een foutpad. Het criterium van W3C voor foutidentificatie bij webcontent vereist dat een automatisch gedetecteerde invoerfout het betrokken item aanwijst en de fout in tekst beschrijft. Alleen een gekleurde omlijning laat die uitleg ontbreken. Native bedieningselementen en een volledige toegankelijkheidsbeoordeling vereisen hun eigen platformcontroles.
-
Controleer de reactie op het scherm en met ondersteunende technologie. Voor webcontent behandelt het criterium van W3C voor statusberichten hoe gedefinieerde statuswijzigingen beschikbaar worden gemaakt voor ondersteunende technologie zonder de focus van het huidige bedieningselement te verplaatsen. Controleer wat op het scherm verschijnt en wat ondersteunende hulpmiddelen kunnen detecteren. Een schermlezer is bijvoorbeeld software die interfacecontent kan voorlezen. Dit geselecteerde criterium certificeert de app niet, stelt geen doel voor de reactietijd vast en herstelt geen trage bewerking.
-
Volg de overgang naar het web. Wanneer hetzelfde account of boekingspad overgaat naar een webpagina, neem je die overgang in de test op. Ontwikkeling van websites en webapps moet de formulering en werkelijke status van de taak over die grens heen behouden.
Wat moet je na de wijziging controleren?
Herhaal dezelfde beoogde taak vanuit een vergelijkbare situatie en leg vast wat er gebeurde. Houd de appversie, het apparaat, de taal en de hulp zichtbaar naast het resultaat. Een bruikbare vergelijking gaat over de taak die je observeerde: of de persoon de actie vond, het effect ervan begreep en het werkelijke resultaat herkende. Laat bredere zakelijke conclusies open totdat je er bewijs voor hebt.
Leg voltooiing en hulp samen vast, evenals de eerste verkeerde afslag, invoerfouten die de persoon niet kon interpreteren en of diegene een verzoek voor een bevestiging aanzag. Herhaal relevante controles met de taal- en toegankelijkheidsinstellingen die je beoordeelt. Inspecteer langere labels en de informatie die via die instellingen beschikbaar is, in plaats van aan te nemen dat het Engelse scherm elke versie vertegenwoordigt.
Als je appacties al registreert, zoals het starten van een boekingswijzigingsverzoek of het bereiken van de aanbieder, controleer dan of die registraties overeenkomen met de werkelijke statussen. Houd veranderingen in ondersteuningsvragen bij hetzelfde pad. Ontbrekende appdownloads zijn een afzonderlijk acquisitieprobleem. Onze gids voor een app die geen downloads krijgt begint voordat iemand het product opent.
Een geslaagde herhaling kan die observatie beschrijven. Ze kan niet vaststellen waarom mensen de app verwijderen of een retentieverandering aan de oplossing toeschrijven. Leg de volgende onopgeloste vraag vast bij de persoon die verantwoordelijk is voor de controle ervan.
Waar wij in beeld komen
We beginnen met de ondersteunde taak, de eerste onduidelijke overgang en het bewijs dat nodig is om een oplossing te kiezen. We kunnen dit omzetten in een prototype, het geïmplementeerde pad controleren en de webtegenhanger ervan meenemen. Neem een beschrijving van de taak en het punt waarop deze stopte mee naar een projectbespreking. Verwijder klantnamen en andere persoonsgegevens uit elk voorbeeld dat je deelt.
