Prototypování není o nástroji

Na mnoha webech často čtu srovnání různých nástrojů na tvorbu digitálních prototypů. Mnohokrát jsem se také účastnil diskuzí o tom, který nástroj je nejlepší a proč. I v GoodData jsme se o tom několikrát bavili.

Jeden čas jsem také hledal jeden „ultimátní“ nástroj na prototypování. Díky čemuž jsem jich vyzkoušel poměrně hodně. Ať už byly výsledkem propojené mockupy, naklikané interaktivní stránky a nebo přímo nakódované prototypy.

Myslím si ale, že některé nástroje nejsou vždy vhodné. A designér by si měl vždy vybrat takový nástroj, díky kterému bude efektivní. Protože prototypování není o nástroji, ale o tom vyzkoušet a ověřit daný návrh.

Proč tvořit prototypy

Nad prototypováním jsem se už párkrát zamýšlel, například v článku Prototyp jako nástroj ke zkoumání designového řešení. Ale stejně se opět zeptám – proč vlastně potřebuji vytvořit nějaký prototyp?

Dříve jsem bral prototyp jako opravdu do detailu vypracovaný návrh. Dnes se na to ale dívám jinak – prototyp je pro mě designový nástroj, na kterém chci určité věci ověřit a díky tomu tak navrhnout kvalitní řešení.

K prototypování mě tedy typicky dovede několik důvodů, například:

  • Chci si ověřit konkrétní hypotézy.
  • Chci si vyzkoušet, zda vůbec bude nápad na řešení fungovat (jako experiment).
  • Chci ukázat, jak bude řešení fungovat.

Nejdůležitější pro mě ale je, abych na prototypu ověřil, zda návrh řešení dává vůbec smysl.

A právě samotná potřeba prototypovat často přichází během návrhu několikrát. Typicky, když:

  • Zkoumám různé možnosti řešení.
  • Rozpracovávám koncept více do detailu.

Podle toho vždy volím formu a nástroj. Protože potřebuji v různých fázích ověřit jiné hypotézy. A protože potřebuji využít různou míru detailu.

Jak může vypadat tvorba návrhu řešení a kdy se může hodit prototyp.
Jak může vypadat tvorba návrhu řešení a kdy se může hodit prototyp.

Pro mě tvorba prototypu rozhodně není forma designu (bohužel to tak vnímá spousta lidí). Ale jak jsem již zmínil, je to pro mě designový nástroj, pomocí kterého hledám to nejlepší řešení.

A než s prototypováním začnu, snažím si ujasnit, jaké mám možnosti a co budu potřebovat. Například:

  • Kolik času mám na návrh řešení.
  • Co přesně potřebuji ověřit.
  • Co budu s prototypem dál dělat.

Podle toho se pak rozhoduji, jak prototypovat (a zda vůbec). Pro což mám pár jednoduchých pravidel. Ale klíčové je snadno získat odpovědi a příliš se s tím nepárat.

Který prototyp je ten nejlepší

Je hrozně těžké říct, který nástroj je ten nejlepší. Hodně záleží na tom, co chceme zjistit a jestli jsme schopni to zjistit. (A určitě znáte dva možné přístupy – low-fihi-fi prototypy.)

Myslím si, že nejlepší prototyp je takový, pomocí kterého snadno a efektivně ověříme, že řešení dává smysl. A je jedno, jestli to bude papírový prototyp, naklikaný prototyp v Axure nebo naprogramovaná aplikace.

Vždy bychom se totiž měli snažit o to, abychom:

  • Prototyp co nejrychleji vytvořili.
  • Byli schopni v něm rychle dělat změny.
  • Díky prototypu snadno ověřili, co potřebujeme.

Jak už jsem párkrát zmiňoval, nechci se s tím příliš párat. Je to jen nástroj a nejdůležitější je finální výsledek.

Například když jsem v GoodData navrhoval první věc, bylo pro mě nejrychlejší udělat papírový prototyp, než jej naklikat v Indigo Studio (nástroj, který používáme). Protože jsem jej ještě neuměl správně uchopit.

U jedné z aplikací jsem zase prototyp v podstatě nakódoval. Protože jsem potřeboval ověřit snadnost a přímočarost interakce. S čímž by mi jiná forma prototypu nepomohla (vše bych musel složitě namodelovat – což by mi trvalo hodně dlouho).

Někdy prototyp naklikám, někdy flow vytvořím spojením pár obrazovek a někdy celou interakci přímo nakóduji.
Někdy prototyp naklikám, někdy flow vytvořím spojením pár obrazovek a někdy celou interakci přímo nakóduji.

Několikrát jsem prototyp vytvořil také proto, že jsem si potřeboval vyzkoušet a zhodnotit konkrétní nápad. Protože ten často vypadá dobře na papíře, ale ve skutečnosti to už tak dobré být nemusí.

Například jsem toho využil, když jsem hledal animaci pro zlepšení percepce výkonu aplikace určité části UI. A nebo animaci, která pomáhala navigaci a vedení pozornosti.

Vidím rozdíl také v tom, co potřebujeme prototypovat. Například u webů budeme typicky potřebovat něco jiného, než u aplikací. Například:

  • U webu jde především o informační architekturu, přechody mezi stránkami, layout, typografii, atp.
  • Zatímco u aplikací nám půjde o celkový koncepční model, návaznost a přímočarost interakcí a flow, atp.

A například pro aplikace vidím prototypování v nástrojích jako je Axure, Indigo Studio, Justinmind, Invision App, atp, jako trochu problematické. Protože v podstatě „namodelujem“ omezené flow. A párkrát jsem zažil, že to mírně zkreslilo výsledek a že designér zapomněl na některé stavy a detaily.

Zároveň jsem toho názoru, že bychom za prototyp mohli považovat i produkt, který už někdo používá. Mnoho společností to dělá v rámci svých beta programů nebo postupného uvolňování lidem.

Nemyslím si tedy, že nějaký nástroj je nejlepší. Každý nabízí něco jiného. A vyzkoušel jsem si, že se dá hodně získat jejich kombinací.

Nebojte se nástroje kombinovat

Dříve jsem se také snažil mít na všechno ideálně jeden nástroj. Což mě často vedlo k poměrně zdlouhavé přípravě úvodních konceptů. A složitými úpravami v průběhu. Postupem doby jsem ale zjistil, že mi vlastně žádný nástroj neposkytuje vše, co v daný moment potřebuji.

Jak jsem již zmínil, potřeba prototypovat přichází v rámci projektu několikrát. Protože potřebuji ověřit různé věci. Například:

  • Způsob řešení,
  • Visuální hierarchie a priority,
  • Dílčí interakce a mikrointerakce.

A tak podobně.

Snažím se vše udělat co nejrychleji. A byl tak schopen rychleji iterovat. Takže podle toho volím formu a nesnažím se ověřit vše najednou, ale spíš získat nápady do dalších fází.

Prototyp usnadní cestu od problému k jeho řešení. Protože si na něm můžete ověřit, zda vše dává smysl.
Prototyp usnadní cestu od problému k jeho řešení. Protože si na něm můžete ověřit, zda vše dává smysl.

Začínám tedy s minimem v podobě hlavní myšlenky. A dílčí detaily zatím neřeším. Ty rozpracuji až v průběhu. Takže není vůbec neobvyklé, že v rámci projektu využiji klidně 3 různé nástroje. Například:

  • U jednoho z posledních projektů jsem hlavní myšlenku nakódoval, protože jsem jí potřeboval vidět funkční (měl jsem pár skic a potřeboval jsem vidět a ověřit danou interakci). Díky čemuž jsem jí poté také ověřil s lidmi.
  • U dalšího projektu jsem nápad na řešení jedné větší části jsem rozpracoval v Keynote. Šlo totiž především o vizualizaci a informační architekturu.
  • V jiném projektu jsem začal pracovat na konceptu přímo v kódu. Protože jsem potřeboval promyslet responzivní řešení. Dílčí části jsem ale naklikal v Indigo Studio.

Když jednotlivé věci ověřím a dávají smysl, pokračuji dál a návrh rozpracovávám. A pokud je potřeba, opět využiji prototyp – ale ne nutně v daném nástroji.

Jak jsem již říkal, snažím se myšlenky a nápady efektivně ověřit. A podle toho vybírám nástroj. Protože i samotné prototypování je především nástroj poznání a ne samotný design.

Důležité je být efektivní

Už dávno jsem přestal hledat jeden „ultimátní“ nástroj. A místo toho kombinuji různé nástroje a formy. Chci totiž co nejrychleji získat odpovědi na otázky, které mám v průběhu návrhu řešení. A s tím mi pouze jeden nástroj nikdy nepomohl.

Vždy zvažuji, k čemu prototyp potřebuji a zda jej vůbec potřebuji. Podle čehož se poté rozhodnu, jaký nástroj zvolit. On je pro mě totiž prototyp „pouze“ další designový nástrojem a tak s ním zacházím. Nemám problém jej kompletně zahodit a předělat. Pokud je to potřeba.

Vyzkoušel jsem si, že kombinace různých nástrojů vede k efektivnější práci. Důležité totiž je, aby prototyp splnil svůj účel – tedy pomohl ověřit hypotézy, které designér má. A ten by tak neměl zbytečně zápolit s nástrojem, ale soustředit se na samotný design.

Napsat komentář