Pentru a diagnostica o interfață de aplicație confuză, analizați ecranele, comenzile și răspunsurile sale în timp ce cineva încearcă o sarcină pe care aplicația o permite. Urmăriți primul punct în care următoarea acțiune devine neclară. Comparați ceea ce se așteaptă persoana să se întâmple cu ceea ce face și raportează aplicația. O salvare eșuată sau o funcție lipsă necesită o remediere diferită de cea pentru o etichetă ori un traseu neclar.
Imaginați-vă că cineva încearcă să modifice o rezervare deja existentă. Persoana deschide mai multe meniuri, revine la ecranul principal și întreabă un coleg. Această succesiune este un punct de plecare pentru o observație. Ea singură nu poate explica dacă persoana dezinstalează ulterior aplicația sau ce ecran trebuie reproiectat.
De ce pierd oamenii următorul pas?
Oamenii pot înțelege obiectivul și totuși pot rata o acțiune sau un răspuns neclar. Căutăm prima neconcordanță vizibilă dintre sarcina intenționată și ecranul întâlnit. Nu fixați explicația înainte de a verifica operațiunea. Ceea ce pare o problemă de navigare poate fi și o solicitare eșuată sau un rezultat pe care produsul nu îl permite.
Formularea sugerează altă acțiune. O persoană se poate aștepta la încă un ecran de verificare după ce apasă Continuați, deși aplicația trimite imediat o solicitare. Îndrumările Apple privind butoanele recomandă ca scopul să fie clar. Comparați așteptarea cu efectul real înainte de a alege o etichetă înlocuitoare.
Rezultatul rămâne incert. Cineva apasă din nou pentru că nu își poate da seama dacă aplicația a acceptat solicitarea. Verificați ce s-a salvat efectiv și ce a raportat ecranul. O confirmare lipsă și o operațiune eșuată necesită remedieri diferite.
Îndrumarea pentru introducerea datelor apare după greșeală. Verificați dacă acel câmp explică valoarea de care are nevoie.
Pentru conținutul web, criteriul W3C privind etichetele sau instrucțiunile impune etichete ori instrucțiuni atunci când conținutul necesită introducerea datelor. Folosiți această referință pentru ecranele web dintr-o aplicație. Aplicațiile native necesită o evaluare separată pentru platformă.
Traseul își pierde contextul. Cineva revine de la un ecran cu detalii și nu mai poate găsi elementul pe care îl modifica. Înregistrați acel punct de plecare, acțiunea aleasă și ecranul rezultat. Descrieți prima tranziție derutantă suficient de precis pentru a putea fi reprodusă.
Cum diagnosticați o interfață de aplicație confuză?
Începeți cu un rezultat pe care produsul îl permite și o stare inițială comparabilă. Folosiți un cont de test și date de test sigure pentru acțiunile care trimit, taxează, șterg sau afectează pe altcineva. Formulați obiectivul fără să numiți meniul sau comanda care duce la el. Doriți să aflați ce poate găsi și înțelege persoana înainte să îi oferiți o explicație.
- Definiți finalizarea. Pentru modificarea unei rezervări, rezultatul intenționat este o solicitare trimisă sau o rezervare nouă confirmată? Verificați ce rezultat pot permite această versiune și acest cont.
- Înregistrați starea inițială. Notați versiunea aplicației, dispozitivul, limba, permisiunile și dacă rezervarea există deja. Contul unui administrator poate afișa un traseu diferit de cel al contului unui client.
- Observați fără să numiți comanda. Cereți-i persoanei să încerce să atingă obiectivul. Înregistrați ecranul ales, eticheta citită și așteptarea persoanei. Dacă o ajutați, notați ajutorul; finalizarea ulterioară nu îl șterge.
- Verificați separat rezultatul. Comparați răspunsul vizibil cu rezervarea salvată. Redeschideți-o în contul de test sau verificați înregistrarea de test a furnizorului. O apăsare sau un ecran care pare să indice succesul nu demonstrează că actualizarea intenționată a avut loc.
Dacă inspectați singur aplicația, înregistrați ce puteți reproduce și mențineți vizibilă această limitare. Cunoașterea produsului schimbă sarcina. O observație ulterioară cu o persoană nefamiliarizată cu produsul oferă dovezi diferite.
Parcurgeți această sarcină fictivă de rezervare
Luați în considerare o aplicație inventată pentru rezervarea cursurilor, care permite unei persoane să solicite o altă sesiune. Furnizorul trebuie să accepte solicitarea înainte ca rezervarea să se modifice. Notele de mai jos ilustrează cum poate fi investigată o neînțelegere. Nu am folosit o aplicație, un cont sau un participant real pentru acest exemplu și nu am testat formularea propusă.
| Observație | Notă |
|---|---|
| Sarcina intenționată | Mutarea rezervării existente pentru un curs la altă sesiune. |
| Acțiune și etichetă exactă | Persoana apasă Schimbați rezervarea; butonul trimite o solicitare. |
| Rezultat așteptat | Persoana crede că noua sesiune este deja rezervată. |
| Stare reală | Rezervarea inițială rămâne valabilă cât timp solicitarea așteaptă acceptarea. |
| Verificare propusă | Încercați Solicitați o modificare și un mesaj care spune că solicitarea a fost trimisă. |
Neconcordanța observată privește semnificația acțiunii. O etichetă diferită este o ipoteză care trebuie testată în raport cu operațiunea reală. Dacă solicitarea nu ajunge niciodată la furnizor, investigați și operațiunea eșuată. Dacă confirmarea imediată este esențială pentru produs, aceasta este o decizie de produs separată, nu ceva ce poate furniza eticheta unui buton.
Scrieți o observație înaintea interpretării sale. “A deschis rezervarea, a apăsat Schimbați rezervarea și se aștepta la confirmare” descrie comportamentul din acest exercițiu fictiv. “Interfața este slabă” omite întrebarea la care încă trebuie să răspundeți.
Faceți cea mai mică schimbare care răspunde observației
Alegeți o remediere care abordează neconcordanța înregistrată și păstrează operațiunea intenționată. Începeți cu formularea, instrucțiunile sau feedbackul atunci când acestea sunt aspectele incerte. O structură de navigare modificată sau o reproiectare mai amplă necesită un motiv fundamentat în sarcină. Mențineți vizibile defecțiunile funcționale, astfel încât o explicație mai clară să nu ascundă o operațiune care continuă să eșueze.
-
Încercați o schiță precisă. Pentru rezervarea fictivă, afișați într-o schiță interactivă o etichetă propusă pentru acțiune și starea rezultată. Serviciile noastre de audituri UX și prototipuri pentru aplicații urmează această succesiune de la sarcină la prototip. Comparați așteptarea persoanei dinaintea apăsării cu starea pe care o recunoaște ulterior; nu descrieți eticheta propusă drept o îmbunătățire dovedită.
-
Verificați un traseu de eroare. Criteriul W3C de identificare a erorilor pentru conținutul web impune ca o eroare de introducere detectată automat să identifice elementul afectat și să descrie eroarea prin text. Doar un contur colorat lasă acea explicație absentă. Comenzile native și o evaluare completă a accesibilității necesită propriile verificări specifice platformei.
-
Verificați răspunsul pe ecran și cu tehnologie asistivă. Pentru conținutul web, criteriul W3C privind mesajele de stare se referă la punerea schimbărilor de stare definite la dispoziția tehnologiei asistive fără a muta focalizarea de la comanda curentă. Verificați ce apare pe ecran și ce pot detecta instrumentele asistive. Un cititor de ecran, de exemplu, este un program care poate citi cu voce tare conținutul interfeței. Acest criteriu selectat nu certifică aplicația, nu stabilește un obiectiv pentru timpul de răspuns și nu remediază o operațiune lentă.
-
Urmăriți tranziția web. Când traseul aceluiași cont sau al aceleiași rezervări trece într-o pagină web, includeți tranziția în test. Dezvoltarea de site-uri și aplicații web trebuie să păstreze formularea sarcinii și starea reală dincolo de această limită.
Ce trebuie să verificați după schimbare?
Reluați aceeași sarcină intenționată dintr-o stare comparabilă și înregistrați ce s-a întâmplat. Păstrați vizibile lângă rezultat versiunea aplicației, dispozitivul, limba și ajutorul oferit. O comparație utilă privește sarcina observată: dacă persoana a găsit acțiunea, i-a înțeles efectul și a recunoscut rezultatul real. Nu trageți o concluzie comercială mai amplă până când nu aveți dovezi pentru aceasta.
Înregistrați împreună finalizarea și ajutorul, prima abatere, erorile de introducere pe care persoana nu le-a putut interpreta și dacă a confundat o solicitare cu o confirmare. Repetați verificările relevante cu limba și configurația de accesibilitate pe care le evaluați. Inspectați etichetele mai lungi și informațiile disponibile prin configurația respectivă, în loc să presupuneți că ecranul în engleză reprezintă fiecare versiune.
Dacă înregistrați deja acțiunile din aplicație, cum ar fi începerea unei solicitări de modificare a rezervării sau ajungerea ei la furnizor, verificați dacă înregistrările corespund acelor stări reale. Urmăriți schimbările din întrebările adresate serviciului de asistență pentru același traseu. Descărcările lipsă ale aplicației reprezintă o problemă separată de atragere a utilizatorilor; ghidul nostru despre o aplicație care nu primește descărcări începe înainte ca cineva să deschidă produsul.
O reluare reușită poate descrie observația respectivă. Nu poate stabili de ce oamenii dezinstalează aplicația și nici nu poate atribui remedierii o schimbare a retenției. Înregistrați următoarea întrebare nerezolvată împreună cu persoana responsabilă pentru verificarea ei.
Cum putem ajuta
Începem cu sarcina pe care aplicația o permite, prima tranziție neclară și dovezile necesare pentru alegerea unei remedieri. Putem transforma aceste elemente într-un prototip, putem verifica traseul implementat și putem include corespondentul său web. Aduceți descrierea sarcinii și punctul în care s-a oprit la o discuție despre proiect. Eliminați numele clienților și alte informații personale din orice exemplu pe care îl transmiteți.
