Co vyzkoušet před schválením redesignu firemní aplikace?
Než schválíte nové obrazovky firemní aplikace, sledujte, jak na nich někdo z budoucích uživatelů řeší důležitý úkol. Vyzkoušejte i situace, kdy se něco pokazí, a pak rozhodněte, co schválit, co upravit a co ještě ověřit ve fungující aplikaci.

Nové obrazovky vypadají dobře. Dodavatel vám ukáže, jak najít objednávku, upravit ji a uložit. Teď máte redesign schválit, aby mohl pokračovat vývoj.
Než souhlasíte, nechte někoho, kdo bude aplikaci skutečně používat, vyřešit důležitý úkol. Popište situaci a výsledek, kterého má dosáhnout, a pak sledujte, co udělá. Při prezentaci člověka vede předvádějící. Když ale řeší požadavek zákazníka, musí cestu najít sám.
Začněte prací, na které záleží
Vyberte úkol, který lidé dělají často, nebo při kterém by chyba způsobila potíže. Pokud výjimka mění další postup, zahrňte i ji. Vhodný rozsah závisí na vaší aplikaci a na rozhodnutí, které právě řešíte.
Představme si hypotetický příklad. Pracovník zpracovávající objednávky dostane od zákazníka žádost o změnu doručovací adresy před odesláním. Potřebuje najít správnou objednávku, adresu opravit a zjistit, zda se změna uložila.
Připravte ukázkové objednávky s vymyšlenými údaji zákazníků. Dejte pracovníkovi uvěřitelnou zprávu od zákazníka a dostatek informací k nalezení objednávky. Skutečné zákaznické ani firemní údaje do prototypu, který je neumí bezpečně chránit, nevkládejte.
Pak ho požádejte, aby žádost vyřídil. Nedávejte pokyny typu „otevřete Objednávky, zvolte Upravit a stiskněte Uložit“. Tím byste mu rovnou ukázali odpověď, kterou se snažíte zjistit.
Doporučení Marieke McCloskey k zadávání úkolových scénářů z 12. ledna 2014 vysvětluje rozdíl: lidem popište smysluplný kontext a cíl, ale neprozrazujte jim cestu aplikací.
Nechte to zkusit pravděpodobného uživatele
Požádejte někoho, kdo takovou práci dělá nebo ji pravděpodobně dělat bude. Pokud opravy objednávek řeší pracovníci, manažer, který už navržené obrazovky zná, je nemůže zastoupit. Zapojte i další role, pokud při své práci řeší jiné otázky.
Použijte podmínky, které odpovídají dané práci. Pracovník, který celý den sedí u stolu, může spoléhat na klávesnici. Člověk kontrolující objednávky na telefonu má jinou obrazovku i způsob ovládání. Pokud lidé používají asistivní technologie, připravte odpovídající prostředí a ověřte, zda je prototyp podporuje.
Pokyny GOV.UK k moderovanému testování použitelnosti popisují, jak sledovat skutečné nebo pravděpodobné uživatele při plnění uvěřitelných úkolů. Stejný princip můžete použít pro konkrétní práci, kterou potřebujete posoudit, aniž byste přebírali celý vládní výzkumný program.
Sledujte, kam se pracovník dívá, kde váhá, odbočí špatně nebo přehlédne informaci. Poslouchejte, co si myslí, že se stalo. Pokud musíte pomoci, zapište si kde a jak. Úspěšné dokončení s nápovědou vám říká něco jiného než dokončení bez ní.
„Líbí se mi rozvržení“ je užitečná zpětná vazba k osobní preferenci. „Myslel jsem, že se adresa uložila, ale pořád jsem ji upravoval“ ukazuje konkrétní problém, který stojí za prověření.
A teď si představte, že už objednávka odešla k expedici
Ve stejném hypotetickém příkladu zákazník požádá o změnu příliš pozdě na běžnou opravu. Dokáže pracovník pochopit aktuální stav objednávky a zjistit, co má udělat dál? Možná potřebuje souhlas manažera nebo musí kontaktovat expedici.
Domluvte se, jaký má být další krok ve vaší firmě, a nechte člověka, aby ho zkusil. Pokud to prototyp umožňuje, zahrňte příslušné obrazovky a možnosti. Hledejte jasný výsledek: ví pracovník, zda se adresa změnila, jestli musí jednat někdo další a co může odpovědět zákazníkovi?
Simulované upozornění může ukázat, zda je jeho text srozumitelný. Neprokáže však, že fungující aplikace zabrání neoprávněné změně nebo doručí zprávu expedici. Tyto otázky si nechte na ověření, které na ně dokáže skutečně odpovědět.
Vyberte prototyp, který odpoví na vaši otázku
Náčrt vám může pomoci probrat, co má být na obrazovce a zda návrh dává smysl. Klikací prototyp může člověku umožnit najít objednávku, přecházet mezi obrazovkami a pochopit potvrzení, pokud jsou tyto části skutečně vytvořené. Všem řekněte, které části fungují a které se pouze simulují.
Chcete-li zjistit, zda pracovník najde postup opravy, nechte ho tento postup vyzkoušet. Pokud rozhodujete, zda je upozornění srozumitelné, ukažte ho v situaci, kdy by se objevilo. Otázka, zda si člověk myslí, že by obrazovku zvládl, zachycuje jeho odhad. Pozorování pokusu ukáže, co skutečně udělá.
Katherine Alsop ve svém popisu práce s prototypy v GDS z 27. srpna 2014 vysvětlila rozdíl mezi stabilní prezentací pro zainteresované osoby a prototypy, které se během výzkumu mění. Upozornila také, že výzkum na živé službě může odhalit problémy s dobou odezvy a zpracováním chyb, které prototyp neukáže.
To je při schvalování důležité. Klikací zpráva „Uloženo“ může ověřit, zda pracovník rozumí výsledku. Ověření, že se uložila správná data, opakované požadavky probíhají bezpečně a změnu dostaly propojené systémy, vyžaduje odpovídající kontrolu implementace. Také zabezpečení, vynucená oprávnění a rychlost potřebují důkazy z příslušných fungujících částí aplikace.
Lidé používající své obvyklé asistivní technologie mohou odhalit praktické překážky. Jak vysvětlují pokyny W3C k zapojení uživatelů do hodnocení přístupnosti, toto hodnocení patří vedle posuzování podle standardů přístupnosti. Dokončení těchto úkolů nedokazuje, že aplikace standardy přístupnosti splňuje. Pokud prototyp potřebné prostředí nepodporuje, zaznamenejte toto omezení a naplánujte pozdější vhodné ověření.
Odcházejte ze schůzky s rozhodnutím, které umíte vysvětlit
Zapište si, co jste viděli, dokud to máte v čerstvé paměti. Záznam držte praktický:
- Kdo co zkoušel: role člověka, úkol, zařízení a způsob ovládání a části, které prototyp podporoval.
- Co se stalo: zda dosáhl zamýšleného výsledku, kde se trápil a jakou pomoc potřeboval. Pozorování oddělte od domněnek o příčině.
- Co změnit a zkusit znovu: pojmenujte matoucí označení, chybějící informaci nebo nejasný další krok. Po úpravě nechte někoho dotčenou práci znovu vyzkoušet.
- Co ještě vyžaduje fungující aplikaci: zaznamenejte otevřené otázky, kdo je ověří a kdy. V našem příkladu může jít o to, kdo smí schválit pozdní opravu a jak se změna dostane k expedici.
Pak můžete schválit směr, který pokusy podporují, požádat o úpravy tam, kde lidé narazili, nebo odložit konkrétní rozhodnutí do chvíle, kdy budou k dispozici správné důkazy. U různých částí redesignu můžete udělat všechny tři věci. Schválení obrazovek objednávek nemusí znamenat přijetí neotestovaného propojení s expedicí.
Pokud připravujete redesign firemní aplikace, naše designérská práce může být začátkem rozhovoru o tom, kdo aplikaci používá, co potřebuje dělat a s jakými rozhodnutími potřebujete pomoct.