Zadanie nie je zoznam obrazoviek
Väčšina projektov k nám príde ako výpočet: chceme prihlásenie, prehľad zákaziek, export do Excelu. To je zoznam funkcií, nie zadanie. Zadanie znie, čo má človek pri počítači zvládnuť urobiť a za ako dlho. Rozdiel sa spozná až v prevádzke, keď je oprava najdrahšia.
Prvé stretnutie preto vedieme ako rozhovor o dni toho človeka. Pri Waliu to bola otázka, čo robí obsluha za barom, keď má troch ľudí v rade. Pri Layered to bolo, ako sa dnes eviduje dochádzka na kurze. Odpoveď „v tlačenom zozname“ zmenila celý dátový model.
Kým nevieme, čo má človek urobiť, nemá zmysel kresliť obrazovky.
Štruktúra pred vizuálom
Druhý krok je mapa: aké stavy systém má, kto ich vidí a čo sa stane, keď niečo chýba. Bez nej vznikajú rozhrania, kde sú tri cesty k tomu istému a žiadna nie je úplná. Túto časť robíme v texte, nie v grafickom nástroji, pretože sa v nej ľahšie škrtá.
Čo v mape musí byť
- Zoznam rolí a toho, čo ktorá smie vidieť a meniť.
- Stavy záznamu od vzniku po archiváciu, vrátane tých nepríjemných: storno, duplicita, chýbajúci údaj.
- Miesta, kde sa pracuje s cudzím systémom, teda platby, fakturácia alebo sklad.
- Čo sa stane pri nulovom obsahu. Prázdna obrazovka je tiež stav.
Kľúčové správanie overujeme pred vývojom
Správanie rozhrania riešime skôr, než sa napíše kód: čo sa stane pri dlhom názve, ako sa to zlomí na mobile, čo ukáže prázdny zoznam alebo chýbajúci údaj. Keď sa tieto otázky odložia, vrátia sa vo chvíli, keď je ich riešenie najdrahšie.
Pri projektoch, ktoré sami vyvíjame, overujeme kľúčové obrazovky v náhľade v prehliadači. Keď pripravujeme samostatný UX/UI návrh pre váš vývojový tím, odovzdávame ho ako prezentáciu s obrazovkami, stavmi a mapou rolí. Rozdiel je v procese overenia, nie v tom, čo má návrh tímu odovzdať.
Keď sedí domovská a jedna vnútorná stránka, zvyšok je už opakovanie. Pri vlastnom vývoji kľúčové stránky overujeme v náhľade v prehliadači a pripomienky zbierame priamo v ňom. Pri samostatnom návrhu pripravujeme prezentáciu, ktorú s tímom spoločne prejdeme obrazovku po obrazovke. Rovnaký postup používame pri weboch na mieru aj pri interných aplikáciách.
Ako to dopadne na jednom kroku
Zoberme jedinú obrazovku z Layered: výber termínu a platba. V zozname funkcií by stálo „rezervácia kurzu s platbou kartou“ a dalo by sa to postaviť za deň. V mape stavov sa však objavila otázka, čo sa stane medzi kliknutím na „zaplatiť“ a potvrdením z banky.
Odpoveď „zatiaľ nič“ znamená, že pri poslednom voľnom mieste a dvoch ľuďoch v platobnej bráne sa miesto predá dvakrát. Klientka by to potom riešila telefónom a vracaním peňazí. Preto rezervácia beží v databázovej transakcii a rozrobená platba drží miesto pätnásť minút. Radšej nech zákazník uvidí obsadené.
To je celý rozdiel. Rozhodnutie zabralo desať minút rozhovoru a jeden riadok v mape stavov. Keby prišlo až po spustení, znamenalo by prepísať model rezervácií v systéme, ktorý už má zaplatené objednávky. Návrh dopredu nešetrí čas na vývoji; šetrí presne tieto situácie.
Čo sa tým ušetrí
Nejde o to, že by sa návrhom skrátil vývoj. Skráti sa prepisovanie. Na projektoch, kde sme začali štruktúrou, sme nemali ani jednu situáciu, keď sa hotová obrazovka zahodila. Tam, kde sme skôr začínali kódom, sa to stávalo pravidelne.
Vedľajší efekt: zadanie sa dá odovzdať ďalej. Keď sa o rok vracia klient s rozšírením, číta sa mapa stavov, nie cudzí kód. Tým sa drží cena rozvoja, nie len cena prvej verzie.
Kedy návrh dopredu nerobiť
Keď ide o jednu stránku s jasnou akciou alebo o drobnú úpravu hotového systému. Tam je rýchlejšie to postaviť a pozrieť sa. Návrh dopredu sa vypláca od chvíle, keď má rozhranie viac rolí, viac stavov alebo napojenie na ďalší nástroj.
