Chcete-li diagnostikovat nepřehlednou aplikaci, sledujte její obrazovky, ovládací prvky a odezvy, zatímco se někdo pokouší splnit úkol, který aplikace podporuje. Všímejte si prvního místa, kde přestane být další akce jasná. Porovnejte očekávání dané osoby s tím, co aplikace udělá a oznámí. Neúspěšné uložení nebo chybějící funkce vyžadují jinou opravu než nejasný popisek či cesta.

Představte si někoho, kdo se snaží změnit existující rezervaci. Otevře několik nabídek, vrátí se na domovskou obrazovku a zeptá se kolegy. Tato posloupnost je výchozím bodem pozorování. Sama nemůže vysvětlit, zda později aplikaci odinstaluje ani kterou obrazovku je třeba přepracovat.

Proč lidé ztrácejí další krok?

Lidé mohou chápat cíl, ale přesto přehlédnout nejasnou akci nebo odezvu. Hledáme první viditelný nesoulad mezi zamýšleným úkolem a obrazovkou, na kterou narazí. Dokud neověříte fungování operace, ponechte vysvětlení otevřené. Zdánlivý problém s navigací může být také neúspěšný požadavek nebo výsledek, který produkt nepodporuje.

Text naznačuje jinou akci. Po klepnutí na Pokračovat může člověk očekávat další obrazovku ke kontrole, zatímco aplikace požadavek okamžitě odešle. Pokyny společnosti Apple pro tlačítka doporučují jasně vyjádřit jejich účel. Než vyberete náhradní popisek, porovnejte očekávání se skutečným účinkem.

Výsledek zůstává nejistý. Někdo klepne znovu, protože nepozná, zda aplikace požadavek přijala. Prověřte, co se skutečně uložilo a co obrazovka oznámila. Chybějící potvrzení a selhání operace vyžadují odlišné opravy.

Pokyny pro zadání přijdou až po chybě. Zkontrolujte, zda pole vysvětluje, jakou hodnotu vyžaduje.

Kritérium W3C pro popisky nebo pokyny vyžaduje u webového obsahu popisky nebo pokyny, pokud obsah vyžaduje vstup. Tento zdroj používejte pro webové obrazovky uvnitř aplikace. Nativní aplikace vyžadují samostatnou kontrolu podle pokynů platformy.

Cesta ztrácí kontext. Člověk se vrátí z obrazovky s podrobnostmi a nedokáže znovu najít položku, kterou měnil. Zaznamenejte výchozí bod, zvolenou akci a výslednou obrazovku. První nejasný přechod popište natolik přesně, aby ho bylo možné zopakovat.

Příklad rezervačního úkolu se porovnává s pozorováním zaznamenaným v každé fázi.
Sledujte rezervační úkol od výchozího bodu k výsledku, který člověk rozpozná.

Jak diagnostikovat nepřehlednou aplikaci?

Začněte podporovaným výsledkem a srovnatelným výchozím stavem. Pro akce, které něco odesílají, účtují, mažou nebo ovlivňují někoho jiného, použijte testovací účet a bezpečná testovací data. Zapište cíl bez uvedení nabídky nebo ovládacího prvku, který k němu vede. Chcete zjistit, co člověk dokáže najít a pochopit, než mu poskytnete vysvětlení.

  1. Definujte dokončení. Je zamýšleným výsledkem změny rezervace odeslaný požadavek, nebo potvrzená nová rezervace? Ověřte, který výsledek tato verze a účet podporují.
  2. Zaznamenejte výchozí stav. Poznamenejte si verzi aplikace, zařízení, jazyk, oprávnění a to, zda rezervace již existuje. Účet správce může zpřístupnit jinou cestu než účet zákazníka.
  3. Pozorujte bez pojmenování ovládacího prvku. Požádejte člověka, aby se pokusil dosáhnout cíle. Zaznamenejte zvolenou obrazovku, přečtený popisek a jeho očekávání. Pokud mu pomůžete, pomoc poznamenejte. Pozdější dokončení ji nevymaže.
  4. Výsledek ověřte samostatně. Porovnejte viditelnou odezvu s uloženou rezervací. Znovu ji otevřete v testovacím účtu nebo zkontrolujte testovací záznam poskytovatele. Klepnutí ani obrazovka, která vypadá jako úspěšná, neprokazují, že došlo k zamýšlené aktualizaci.

Pokud aplikaci kontrolujete sami, zaznamenejte, co dokážete zopakovat, a toto omezení ponechte viditelné. Vaše znalost produktu úkol mění. Pozdější pozorování s člověkem, který produkt nezná, poskytne jiný druh důkazu.

Projděte tento fiktivní rezervační úkol

Představte si smyšlenou aplikaci k rezervaci lekcí, ve které může člověk požádat o jiný termín. Než se rezervace změní, musí poskytovatel požadavek přijmout. Následující poznámky ilustrují, jak prošetřit nedorozumění. Pro tento příklad jsme nepoužili živou aplikaci, účet ani účastníka a navržené texty jsme netestovali.

PozorováníPoznámka
Zamýšlený úkolPřesunout existující rezervaci lekce na jiný termín.
Akce a přesný popisekČlověk klepne na Změnit rezervaci. Tlačítko odešle požadavek.
Očekávaný výsledekČlověk se domnívá, že nový termín je již rezervován.
Skutečný stavPůvodní rezervace zůstává, zatímco požadavek čeká na přijetí.
Navržená kontrolaVyzkoušet Požádat o změnu a zprávu, že požadavek byl odeslán.

Pozorovaný nesoulad se týká významu akce. Jiný popisek je hypotéza, kterou je třeba otestovat vůči skutečnému fungování. Pokud požadavek k poskytovateli vůbec nedorazí, prošetřete také selhání operace. Pokud je pro produkt zásadní okamžité potvrzení, jde o samostatné produktové rozhodnutí, nikoli o něco, co může zajistit popisek tlačítka.

Pozorování zapište před jeho interpretací. “Otevřel rezervaci, klepl na Změnit rezervaci a očekával potvrzení” popisuje chování v tomto fiktivním cvičení. “Rozhraní je špatné” přeskakuje otázku, na kterou stále potřebujete odpovědět.

Proveďte nejmenší změnu, která reaguje na pozorování

Zvolte opravu, která řeší zaznamenaný nesoulad a zachová zamýšlenou operaci. Pokud jsou nejisté texty, pokyny nebo zpětná vazba, začněte u nich. Změna navigační struktury nebo rozsáhlejší redesign vyžadují důvod opřený o daný úkol. Funkční selhání ponechte viditelná, aby jasnější vysvětlení nezakrylo operaci, která stále selhává.

  1. Vyzkoušejte cílený návrh. Pro fiktivní rezervaci zobrazte navržený popisek akce a výsledný stav v interaktivním návrhu. Naše audity UX aplikací a prototypy dodržují tento postup od úkolu k prototypu. Porovnejte očekávání člověka před klepnutím se stavem, který rozpozná poté. Navržený popisek nepopisujte jako prokázané zlepšení.

  2. Prověřte chybovou cestu. Kritérium W3C pro identifikaci chyb u webového obsahu vyžaduje, aby automaticky zjištěná chyba vstupu označila dotčenou položku a textově ji popsala. Samotné barevné ohraničení takové vysvětlení neposkytuje. Nativní ovládací prvky a úplná kontrola přístupnosti vyžadují vlastní kontroly pro danou platformu.

  3. Ověřte odezvu na obrazovce i pomocí asistenční technologie. Kritérium W3C pro stavové zprávy u webového obsahu řeší zpřístupnění definovaných změn stavu asistenční technologii bez přesunutí zaměření z aktuálního ovládacího prvku. Zkontrolujte, co se zobrazí na obrazovce a co dokážou asistenční nástroje zjistit. Čtečka obrazovky je například software, který může nahlas číst obsah rozhraní. Toto vybrané kritérium aplikaci necertifikuje, nestanovuje cílovou dobu odezvy ani neopraví pomalou operaci.

  4. Sledujte přechod na web. Pokud cesta stejného účtu nebo rezervace přejde na webovou stránku, zahrňte tento přechod do testu. Vývoj webů a webových aplikací by měl přes tuto hranici zachovat znění úkolu a skutečný stav.

Diagnóza rezervačního úkolu se větví od hledání akce ke kontrole operace nebo její odezvy.
Podle první nejasné části rezervačního úkolu zvolte, co prověříte dále.

Co zkontrolovat po změně?

Zopakujte stejný zamýšlený úkol ze srovnatelného stavu a zaznamenejte, co se stalo. U výsledku uveďte verzi aplikace, zařízení, jazyk a poskytnutou pomoc. Užitečné srovnání se týká pozorovaného úkolu: zda člověk našel akci, pochopil její účinek a rozpoznal skutečný výsledek. Jakékoli širší obchodní závěry ponechte otevřené, dokud pro ně nebudete mít důkazy.

Zaznamenávejte dokončení společně s pomocí, první chybnou odbočku, chyby vstupu, kterým člověk nerozuměl, a zda si spletl požadavek s potvrzením. Příslušné kontroly zopakujte s prověřovaným jazykem a nastavením přístupnosti. Prověřte delší popisky a informace dostupné prostřednictvím daného nastavení, místo abyste předpokládali, že anglická obrazovka zastupuje všechny verze.

Pokud již zaznamenáváte akce v aplikaci, například zahájení požadavku na změnu rezervace nebo jeho doručení poskytovateli, ověřte, že záznamy odpovídají těmto skutečným stavům. Změny v dotazech na podporu sledujte společně se stejnou cestou. Nedostatek stažení aplikace je samostatný problém se získáváním uživatelů. Náš průvodce aplikací, kterou si nikdo nestahuje začíná ještě před otevřením produktu.

Úspěšné zopakování může popsat toto pozorování. Nemůže určit, proč lidé aplikaci odinstalují, ani připsat opravě změnu v udržení uživatelů. Zaznamenejte další nezodpovězenou otázku spolu s osobou, která odpovídá za její ověření.

Kde vám můžeme pomoci

Začínáme podporovaným úkolem, prvním nejasným přechodem a důkazy potřebnými k výběru opravy. Můžeme je převést do prototypu, zkontrolovat implementovanou cestu a zahrnout její webový protějšek. Přineste popis úkolu a místo, kde se zastavil, na konzultaci o projektu. Ze všech sdílených příkladů odstraňte jména zákazníků a další osobní údaje.

Časté otázky

Měli bychom nejdříve přidat úvodní prohlídku?
Než zvolíte prohlídku, zjistěte, kde úkol přestává být jasný. Neznámý pojem může vyžadovat vysvětlení, zatímco nejasná akce může potřebovat místní popisek nebo viditelný další krok. Prohlídka nemůže opravit operaci, která selhává.
Mohu aplikaci prověřit bez náboru zákazníků?
Úkol můžete projít sami a zaznamenat nejasné popisky, chybějící stavy nebo opakovatelné chyby. Vaše znalost aplikace omezuje, co tím lze prokázat o novém uživateli. Berte to jako úvodní kontrolu a případné pozdější pozorování jiné osoby uchovejte odděleně.
Co když uživatelé žádají funkci, kterou aplikace nemá?
Zaznamenejte požadovaný výsledek a ověřte, zda ho produkt v daném stavu účtu podporuje. Chybějící funkce vyžaduje produktové rozhodnutí. Nepopisujte ji jako problém se zněním textu a nesměrujte lidi k akci, která není dostupná.
Zabrání přehlednější rozhraní lidem v odinstalování aplikace?
Kontrola úkolu nemůže určit, proč lidé aplikaci odinstalují. Může ukázat, co se stalo ve sledovaném úkolu. Tvrzení o udržení uživatelů nebo odinstalování vyžadují relevantní produktová data a vhodné srovnání.

← Všechny články