Prototyp má pomôcť rozhodnúť
Pred návrhom obrazoviek si zapíšte, čo ešte neviete o budúcej aplikácii. Rozumie koordinátor navrhnutým stavom zákazky? Vie obchodník pripraviť ponuku bez pomoci kolegu? Sú pri odovzdaní prípadu viditeľné údaje, ktoré ďalší človek potrebuje? Takéto otázky určujú, čo má prototyp ukázať.
Klikateľný prototyp je model rozhrania, v ktorom sa dá prejsť pripraveným scenárom. Jeho hodnota pre firmu spočíva v rozhodnutiach, ktoré umožní urobiť pred implementáciou. Ak neviete pomenovať otázku, na ktorú má odpovedať, ľahko vznikne pekná prezentácia bez jasného ďalšieho kroku.
Vyberte jeden pracovný tok a jeho hranice
Začnite konkrétnym prípadom od vstupu po výsledok. Pri servisnej požiadavke môže ísť o prijatie, doplnenie údajov, priradenie technika a odovzdanie výsledku. Pri každom kroku určte, kto koná, aké podklady má k dispozícii a čo potrebuje vidieť pred rozhodnutím.
Nepotrebujete hneď nakresliť celé ERP. Do prvého overenia zahrňte obrazovky, ktoré pomôžu vyriešiť zvolenú neistotu, a označte pripravené skratky. Ak prototyp preskočí prihlásenie, výber zákazníka alebo samotný výpočet, zaznamenajte to. Pri odovzdaní potom bude jasné, čo používateľ skutočne vyskúšal.
Používateľovi dajte cieľ, nie návod na klikanie
Na skúšanie prizvite ľudí, ktorí danú prácu vykonávajú alebo ju budú vykonávať. Pripravte zrozumiteľnú úlohu bez prezradenia postupu. Sledujte, kde sa človek zastaví a čo si vysvetlí inak, než návrh predpokladal.
V našom modelovom scenári môže úloha znieť: „Zákazník potrebuje zásah tento týždeň. Nájdite vhodného technika a pripravte priradenie.“ Pokyn „otvorte záložku Technik a kliknite na Priradiť“ by už prezradil odpoveď. Do poznámok oddeľte to, čo účastník povedal, čo urobil a kedy potreboval pomoc.
Prejdite aj neúplný prípad
V pripravenom toku sa oplatí ukázať situáciu, keď chýba podklad alebo sa očakávaná možnosť nedá použiť. Napríklad požadovaný termín nie je dostupný, zákazník nemá doplnenú adresu alebo používateľ potrebuje vrátiť prípad kolegovi. Firma si tak môže ujasniť, aké rozhodnutie a informáciu v tej chvíli potrebuje.
Pri každej takejto vetve zapíšte, čo má používateľ pochopiť a čo môže urobiť ďalej. Nemusíte modelovať všetky chyby celého systému. Vyberte výnimky, ktoré menia návrh hlavného procesu, a ostatné nechajte v zozname na ďalšie preverenie.
- Je zrejmé, ktorý údaj chýba a kto ho doplní?
- Vie človek rozlíšiť rozpracovaný prípad od odovzdaného?
- Rozumie dôsledku potvrdenia alebo zrušenia?
- Dá sa úloha dokončiť aj pri dohodnutej výnimke?
Klikateľnosť nepotvrdzuje technickú pripravenosť
To, že prototyp zobrazí voľný termín alebo cenu, ešte neznamená, že sú údaje dostupné v existujúcich systémoch. Pri odovzdaní označte, ktoré hodnoty sú modelové, ktoré pravidlá sa iba simulujú a ktoré kroky sú pripravené len pre zvolený scenár.
Technický tím musí osobitne preveriť napríklad zdroj dostupnosti, možnosti integrácie, prístupové pravidlá a spracovanie súbežných zmien. Ak má otázka technický charakter, môže byť potrebný samostatný technický prototyp alebo test napojenia. Výsledok skúšania rozhrania preto neprezentujte ako dôkaz výkonu či bezpečnosti hotovej aplikácie.
Zistenia premeňte na konkrétne úpravy zadania
Po skúšaní vytvorte zoznam pozorovaní a rozhodnutí. Pri každom uveďte dotknutú úlohu, problém, navrhnutú zmenu a osobu, ktorá ju potvrdí. Rozlišujte medzi zmenou názvu tlačidla, chýbajúcim obchodným pravidlom a technickou otázkou; každá potrebuje iný ďalší krok.
Ak účastník nerozumel tomu, či už prípad odovzdal, výstupom nemá byť iba poznámka „zlepšiť UX“. Zapíšte požadovanú informáciu o stave a spôsob jej overenia v ďalšej verzii. Zistenia z pripravených úloh nepovažujte za dôkaz, že je overený celý produkt alebo všetky skupiny používateľov.
Čo má firma dostať na konci prototypovania
Dohodnutý výstup môže obsahovať odkaz na aktuálny prototyp, opis overených tokov, zoznam obmedzení a rozhodnutia pre prvú verziu. Pripojte otvorené otázky aj zodpovednosť za ich vyriešenie. Takýto balík pomôže vývojovému tímu pochopiť dôvody návrhu, nielen jeho vzhľad.
Ak pripravujete novú aplikáciu alebo meníte interný proces, prineste na konzultáciu jednu neistotu a konkrétnu pracovnú úlohu. V DAVOND môžeme prejsť, či ju najlepšie objasní návrh rozhrania, klikateľný prototyp alebo technické overenie, a podľa toho určiť rozsah ďalšieho kroku.