Zadání není seznam obrazovek
Většina projektů k nám přijde jako výčet: chceme přihlášení, přehled zakázek, export do Excelu. To je seznam funkcí, ne zadání. Zadání zní, co má člověk u počítače zvládnout udělat a za jak dlouho. Rozdíl se pozná až v provozu, kdy je oprava nejdražší.
První schůzku proto vedeme jako rozhovor o dni toho člověka. U Walia to byla otázka, co dělá obsluha za barem, když má tři lidi ve frontě. U Layered to bylo, jak se dnes eviduje docházka na kurzu. Odpověď „v tištěném seznamu“ změnila celý datový model.
Dokud nevíme, co má člověk udělat, nemá cenu kreslit obrazovky.
Struktura před vizuálem
Druhý krok je mapa: jaké stavy systém má, kdo je vidí a co se stane, když něco chybí. Bez ní vznikají rozhraní, kde jsou tři cesty k témuž a žádná není úplná. Tuhle část děláme v textu, ne v grafickém nástroji, protože se v ní snadněji škrtá.
Co v mapě musí být
- Seznam rolí a toho, co která smí vidět a měnit.
- Stavy záznamu od vzniku po archivaci, včetně těch nepříjemných: storno, duplicita, chybějící údaj.
- Místa, kde se pracuje s cizím systémem, tedy platby, fakturace nebo sklad.
- Co se stane při nulovém obsahu. Prázdná obrazovka je taky stav.
Klíčové chování ověřujeme před vývojem
Chování rozhraní řešíme dřív, než se napíše kód: co se stane při dlouhém názvu, jak se to zlomí na mobilu, co ukáže prázdný seznam nebo chybějící údaj. Když se tyhle otázky odloží, vrátí se ve chvíli, kdy je jejich řešení nejdražší.
U projektů, které sami vyvíjíme, ověřujeme klíčové obrazovky v náhledu v prohlížeči. Když připravujeme samostatný UX/UI návrh pro váš vývojový tým, předáváme ho jako prezentaci s obrazovkami, stavy a mapou rolí. Rozdíl je v procesu ověření, ne v tom, co má návrh týmu předat.
Když sedí domovská a jedna vnitřní stránka, zbytek už je opakování. U vlastního vývoje klíčové stránky ověřujeme v náhledu v prohlížeči a připomínky sbíráme přímo v něm. U samostatného návrhu připravujeme prezentaci, kterou s týmem společně projdeme obrazovku po obrazovce. Stejný postup používáme u webů na míru i u interních aplikací.
Jak to dopadne na jednom kroku
Vezměme jedinou obrazovku z Layered: výběr termínu a platba. V seznamu funkcí by stálo „rezervace kurzu s platbou kartou“ a dalo by se to postavit za den. V mapě stavů se ale objevila otázka, co se stane mezi kliknutím na „zaplatit“ a potvrzením z banky.
Odpověď „zatím nic“ znamená, že při posledním volném místě a dvou lidech v platební bráně se místo prodá dvakrát. Klientka by to pak řešila telefonem a vracením peněz. Proto rezervace běží v databázové transakci a rozdělaná platba drží místo patnáct minut. Radši ať zákazník uvidí obsazeno.
Tohle je celý rozdíl. Rozhodnutí zabralo deset minut rozhovoru a jeden řádek v mapě stavů. Kdyby přišlo až po spuštění, znamenalo by přepsat model rezervací v systému, který už má zaplacené objednávky. Návrh dopředu nešetří čas na vývoji; šetří přesně tyhle situace.
Co se tím ušetří
Nejde o to, že by se návrhem zkrátil vývoj. Zkrátí se přepisování. Na projektech, kde jsme začali strukturou, jsme neměli ani jednu situaci, kdy se hotová obrazovka zahodila. Tam, kde jsme dřív začínali kódem, se to stávalo pravidelně.
Vedlejší efekt: zadání se dá předat dál. Když se za rok vrací klient s rozšířením, čte se mapa stavů, ne cizí kód. Tím se drží cena rozvoje, ne jen cena první verze.
Kdy návrh dopředu nedělat
Když jde o jednu stránku s jasnou akcí nebo o drobnou úpravu hotového systému. Tam je rychlejší to postavit a podívat se. Návrh dopředu se vyplácí od chvíle, kdy má rozhraní víc rolí, víc stavů nebo napojení na další nástroj.
