„Potřebujeme nový formulář.“ „Web je nepřehledný.“ „Nešlo by to zautomatizovat?“ Právě podobnými větami začíná velká část digitálních projektů. Nejsou špatně. Jen ještě nepopisují řešení — ukazují, že někde vzniká tření.

Nejdřív potřebuji vidět situaci

Když někdo žádá formulář, zajímá mě člověk, který ho bude vyplňovat, ale také to, co se stane předtím a potom. Kdo data převezme? Podle čeho rozhodne? Co udělá, když něco chybí? A proč současný postup přestal stačit?

Nesnažím se hned vyrobit rozsáhlou analýzu. Začnu několika otázkami, které rozhovor vrátí od nápadu ke skutečné práci:

  • Co dnes člověk nedokáže dokončit nebo co ho zbytečně zdržuje?
  • Kdo problém zažívá a v jaké situaci?
  • Jak si lidé pomáhají nyní, když systém nestačí?
  • Podle čeho poznáme, že se situace opravdu zlepšila?

Výjimky řeknou víc než ideální průchod

Dokonalý scénář bývá jednoduchý. Data dorazí, uživatel ví, co má udělat, a navazující systém odpoví. Skutečná podoba projektu se ukáže až ve výjimkách: chybějící údaj, rozdílné oprávnění, návrat k rozpracované práci nebo dva lidé měnící stejnou věc současně.

Právě tady mě práce baví nejvíc. Z jednotlivých poznámek začíná vznikat mapa rozhodnutí. Často stačí jednoduchý diagram, několik scénářů a přehled otevřených otázek. Důležité není množství dokumentace, ale to, zda tým sdílí stejnou představu.

Co nejdřív ukazuji něco konkrétního

Jakmile rozumím toku informací, připravím strukturu, wireframe nebo malý funkční prototyp. Konkrétní výstup spolehlivě odhalí místa, která v rozhovoru zněla jasně, ale každý si je představoval jinak.

První kolo musí skončit rozhodnutím

Po úvodním pátrání nechci předat jen zápis z porady. Snažím se pojmenovat, co už víme, které předpoklady stále držíme jen pocitem a co je nejlevnější ověřit jako první. Tým tak dostane menší počet konkrétních rozhodnutí místo dlouhého seznamu nejasností.

Součástí výstupu může být mapa procesu, sada hlavních scénářů, jednoduchý prototyp nebo rozpad práce. Formát volím podle toho, co má následovat. Jiný podklad potřebuje vývojář před odhadem a jiný člověk z provozu, který má ověřit, zda navržený postup odpovídá realitě.

Zadání má týmu pomoci rozhodovat

Dobré zadání pro mě není soupis obrazovek. Obsahuje cíl, uživatele, scénáře, pravidla, nejasnosti a způsob ověření. Vývojář z něj má pochopit nejen co vzniká, ale proč. A když narazí na kompromis, musí mít dost kontextu, aby se mohl správně doptat.

U realizace proto nezmizím. Nové souvislosti přicházejí při vývoji, testování i v prvních dnech provozu. Teprve tam se ukáže, jestli jsme původní problém zjednodušili, nebo ho jen schovali za novou obrazovku.

Hotovo je až tehdy, když řešení obstojí v praxi

Nejdůležitější otázka nakonec nezní, zda výstup odpovídá původnímu obrázku. Zajímá mě, jestli lidé dokončí svou práci snáz, s menším počtem chyb a bez nových obcházek. Právě proto mě baví držet projekt od první neurčité věty až po chvíli, kdy se dá výsledek skutečně pozorovat.