Jak navrhujeme aplikace ve Figmě – a proč to zjednodušuje vývoj i komunikaci s klientem
Když dnes klientovi ukazujeme návrh nové aplikace, většinou si ji může rovnou „projít“. Kliká mezi obrazovkami, zkouší jednotlivé scénáře a poměrně dobře si představí, jak bude systém fungovat.
Takto jsme ale nepracovali vždy.
Na začátku jsme pracovali hlavně s nástrojem Balsamiq. Pro analytickou práci je velmi praktický – umožňuje rychle vytvořit wireframy, tedy jednoduché skici obrazovek, které zachytí strukturu aplikace. Je ideální pro přemýšlení nad tím, kde bude tabulka, formulář nebo filtr a jak na sebe jednotlivé obrazovky navazují.
Postupně jsme ale při práci s klienty zjistili jednu věc: pro analytika nebo vývojáře jsou tyto skici velmi srozumitelné, ale pro člověka mimo vývojový tým může být někdy těžší si z nich představit finální aplikaci.
A právě v tomto bodě jsme začali více využívat Figma.
Když návrh začne připomínat skutečnou aplikaci
Figma nám umožnila posunout návrhy o krok dál. Místo jednoduchých skic často vytváříme rovnou barevné obrazovky, které se už velmi podobají budoucímu systému.
U informačních systémů navíc většinou nejde o složitý vizuální design. Typicky pracujeme s poměrně standardní strukturou:
- tabulky se záznamy
- formuláře pro editaci
- filtry
- detail záznamu
Díky tomu můžeme návrh poměrně rychle poskládat tak, aby připomínal reálnou aplikaci. Pro klienta je pak mnohem jednodušší představit si, jak bude systém vypadat a jak se v něm bude pracovat.
Návrh, který se dá projít
Jedna z věcí, která se nám ve Figmě velmi osvědčila, je možnost propojit jednotlivé obrazovky. Návrh tak není jen sada obrázků, ale spíš jednoduchý model aplikace.
Klient si může například projít celý scénář:
- otevřít seznam záznamů
- otevřít detail
- upravit záznam nebo vytvořit nový
Teprve když si člověk aplikací skutečně „projde“, často se objeví drobnosti, které by při čtení dokumentace zůstaly skryté. Typicky jde o malé věci – chybějící tlačítko, nelogický krok nebo stav systému, který jsme při návrhu neřešili.
Právě tyto momenty jsou velmi cenné, protože se objevují ještě před zahájením vývoje.
Jeden společný pracovní prostor
Další věc, která se nám ve Figma osvědčila, je spolupráce.
Na jednom návrhu může současně pracovat analytik, vývojář i klient. Každý může přidat komentář přímo k místu, kterého se připomínka týká.
Místo dlouhých e-mailových vláken tak často stačí otevřít jeden návrh a během pár minut je jasné, o čem se bavíme.
Přínos pro vývoj
Z naší zkušenosti se Figma hodně osvědčila i ve chvíli, kdy se návrh dostane k vývojářům.
Dříve se často stávalo, že analytik něco popsal v dokumentaci a vývojář si musel část věcí domyslet. Někdy šlo o drobnosti – například jak přesně vypadá formulář, kde je filtr nebo jaké stavy může mít obrazovka. Nic dramatického, ale znamenalo to další dotazy a upřesňování během vývoje.
Když máme návrh připravený ve Figmě, vývojář si ho jednoduše otevře a většinu věcí vidí přímo v návrhu.
Vidí například: - jak jsou prvky na obrazovce rozložené, - jak vypadá struktura formuláře, - jak se chová tabulka nebo filtr, - jaké různé stavy může mít obrazovka (například prázdný stav, editace, chyba).Často to funguje tak, že si vývojář otevře konkrétní obrazovku a během pár minut má velmi jasnou představu, co se má implementovat. Nemusí si představovat, jak by to mohlo vypadat podle textového popisu.
Pro nás je to velké zjednodušení komunikace mezi analýzou a vývojem. Návrh ve Figmě vlastně funguje jako velmi konkrétní zadání, nad kterým se může celý tým bavit stejným jazykem.
Co to znamená pro klienta
Z pohledu klienta má tento způsob práce několik praktických výhod.
Aplikaci si může prohlédnout ještě před tím, než se začne programovat. Může si projít scénáře, které bude v systému řešit, a případně navrhnout úpravy.
Změny v této fázi jsou přitom velmi rychlé – často jde jen o úpravu návrhu. Jakmile je systém ve vývoji, bývají podobné úpravy složitější.
Shrnutí
Pro nás nebyl přechod z Balsamiq na Figma jen změnou nástroje. Změnil se hlavně způsob, jak o návrhu aplikací přemýšlíme a jak ho sdílíme s klienty.
Návrh už není jen analytický podklad pro vývoj. Je to místo, kde se postupně formuje celé řešení – společně s klientem i vývojovým týmem. A čím více věcí se podaří vyjasnit právě v této fázi, tím hladší bývá následný vývoj.

