Když se řekne "nový web" nebo "nová aplikace", první, co lidi chtějí vidět, jsou obrazovky. Je to pochopitelné — obrazovka se dá posoudit na první pohled, líbí se nebo ne. Jenže obrazovka je poslední věc, kterou bychom měli kreslit, ne první.
Wireframy odpovídají na špatnou otázku
Wireframe říká, jak něco vypadá. Neříká, jestli to vůbec dává smysl. Dá se nakreslit obrazovka "Detail objednávky" dřív, než někdo řekne, co objednávka vlastně je — jestli může mít víc dodacích adres, jestli se dá rozdělit na dvě zásilky, co se stane, když zákazník mezitím změní fakturační údaje. Bez odpovědi na tyhle otázky je obrazovka jen obrázek. Pěkný, ale prázdný.
Proto začínáme jinde: u dat. Ne u toho, jak systém vypadá, ale u toho, co v něm musí být pravda.
Tři otázky, které klademe jako první
Než padne první řádek kódu nebo první wireframe, projdeme s klientem tři otázky:
- Odkud data reálně přijdou? Ne odkud by měla přijít v ideálním světě — odkud fakticky přijdou. Excel od účetní, export ze starého systému, ruční zadání na recepci. Každý zdroj má svoje mezery a svůj formát a systém je musí umět přijmout, ne jen ten hezký.
- Co se stane, když si dva záznamy odporují? Dva zákazníci se stejným IČO. Objednávka bez přiřazeného skladu. Faktura vystavená dřív než smlouva. V reálném provozu se to stane vždycky — otázka je, jestli to systém odhalí, nebo si to potichu vyřeší po svém.
- Kdo v systému smí co vidět a co měnit? Ne jako dodatečná "role uživatele" v administraci, ale jako součást datového modelu od začátku. Přidávat oprávnění do hotového systému je vždycky bolestivější, než je do něj rovnou vestavět.
Co z toho vzejde
Výstupem první fáze není wireframe, ale datový model — seznam entit, jejich vztahů a toho, kdo je vlastní:
| Entita | Klíčové atributy | Kdo ji vlastní |
|---|---|---|
| Zákazník | IČO, fakturační adresa, kontaktní osoby | Obchod |
| Objednávka | stav, položky, termín dodání | Provoz |
| Faktura | číslo, splatnost, vazba na objednávku | Účetní |
Tahle tabulka vypadá nudně vedle barevného mockupu. Přesně to je ale ten rozdíl mezi projektem, který za rok pořád funguje, a tím, který se po pár měsících začne rozpadat na výjimky a záplaty.
Kdy se to promítne do praxe
Je to stejný postup, který popisujeme na úvodní stránce: nejdřív vaše data v nepořádku, pak model, který v nich najdeme, a teprve pak systém, který podle něj běží. Wireframy přijdou na řadu — ale až poté, co je jasné, co mají vlastně zobrazovat.
Obrazovka se dá předělat za odpoledne. Datový model, na kterém stojí, ne.
Není to proto, že bychom nechtěli mluvit o designu hned. Je to proto, že design, který sedí na špatném modelu, se stejně bude muset předělat — a to už s reálnými daty a reálnými uživateli, což je vždycky dražší.