Při návrhu produktů jsem musel často věnovat mnoho času a sil na vytvoření prototypů. Byly to ale především finanční prostředky mé nebo klientů, kteří si web objednali.
Většina prototypů však sloužila pouze pro komunikaci mezi mnou a klientem, s lidmi při ověřování a s vývojáři nebo grafikem při dalším zpracování. Ve finále skončil prototyp v koši a s ním i všechny vynaložené prostředky, které často nebyly zanedbatelné.
Vše bylo způsobeno nevhodně zvoleným nástrojem, bez kterého by mohla být práce hotova rychleji a za méně peněz. Bohužel stále existuje mnoho lidí, kteří si pod pojmem design představí právě „naklikání“ prototypu a plýtvání prostředky jim nepřipadá významné.
Špatně zvolený software vede k plýtvání
Téměř dva roky jsem strávil prototypováním v Axure RP. Nějaký čas jsem používal Adobe Fireworks nebo Justinmind. Tyto a další podobné programy jsme si pro tvorbu prototypů nikdy příliš neoblíbil, především kvůli:
- Složitosti „výroby“ navržených interakcí.
- Nemožnosti zapojení nejnovějších trendů, např. dotyková ovládání, motion gestures nebo responsivní design.
- Nemožnosti vytvořený prototyp využít v dalších cyklech tvorby produktu.
Vytvořit v takovém programu interaktivní část aplikace, např. interaktivní sadu posuvníků měnících čísla podle aktuální hodnoty, je velice zdlouhavé nejen na samotné vytvoření, ale i případné změny.
A právě velká časová náročnost je jedním z největších negativů. Což je i nemožnost využít vytvořený prototyp v dalších fázích – ani pro web, natož pro jiný typ digitálního produktu. Nebudu jistě jediný, kdo vyexportovaný prototyp nemůže nazvat HTML prototypem – vzhledem ke struktuře kódu.
V GoodData používáme software Indigo Studio, který je skvělý pro rapid prototyping aplikací. Čas a prostředky tak investujeme hlavně do promýšlení návrhů na papír.
Papírové prototypy
Pro mě je prototypování přímá možnost komunikovat design konkrétní a efektivní formou. Ale také rychlý způsob ověřování hypotéz. Z toho důvodu je pro mě nejlepší skicování a tvorba papírových prototypů:
- Je to rychlý způsob, jak dát designovým nápadům konkrétní podobu.
- Lze je efektivně využít v raných fázích pro ověření s lidmi, především mentálních modelů a srozumitelnosti popisků, ikon, atp.
- Tvorba prototypu aplikace zabere mnohem méně času než u digitálních prototypů. A to i v případě změn.
Papírové prototypování lze dobře využít i pro experimenty. Přečtěte si v knize Playful Design, jak využívali papírové prototypy designeři hry Spore.
Přímý digitální prototyp
Situace někdy vyžaduje nutnost ověřit design na skutečných datech. Je totiž zásadní ověřit, zda design skutečně plní svou funkci a interakce fungují zcela přesně podle očekávání lidí. Efektivní možností je proto zpracovat design naprogramováním přímo v aplikaci. V GoodData takto postupujeme při návrhu nových funkcionalit nebo při úpravách stávajících.
Představte si, kolik času byste strávili simulováním „skutečných“ dat v prototypovacím softwaru. Já jsem si to mnohokrát vyzkoušel avvždy to byla naprostá ztráta času.
Ověřený design lze díky vytvořenému kódu téměř hned zapracovat do reálné aplikace. A tím se opět ušetří dost času a peněz.
Investujte raději svůj čas a prostředky do nápadů
Při práci v agentuře jsem se naučil vážit toho, kolik času mám na promýšlení designu – konceptů, konceptuálních modelů, informační architektury, atd.
Nesnažím se odradit od tvorby anotovaných wireframů, které svou úlohu plní dobře a nejsou náročné na vytvoření. Na základě vlastních zkušenosti však doporučuji věnovat čas, energii a peníze raději do promýšlení nápadů, tvorby konceptů a jejich finalizace.
Tvorbou prototypu bychom měli trávit nezbytně nutné množství času – vždy co nejméně. Využívejte proto prototypy k čemu jsou určené – k ověřování hypotéz. Ať se budeme snažit sebevíc, prototypy stejně skončí v koši. Určitě nechceme plýtvat omezenými prostředky, kterými jsou čas a peníze.
Hezký článek Michale, díky. V čem přesně spatřuješ výhody Indiga oproti Axure, který je celkem rozšířený a populární?
Osobně jsem dlouho používal Balsamiq, protože klienti si v mockupu lépe představí výsledný projekt. Ale udělat kvalitní výstup z Balsamiqu není otázka dvou hodin. Momentálně jsem nejrychlejší v Illustratoru, ve kterém mám vytvořenou vlastní knihovnu prvků. Ale přicházím o interaktivitu, kterou prototypy vynikají.
Chápu ten posun ke skicám, leč v rámci gooddata děláš na interním produktu v agilním prostředí s možností se rychle napojit na stávající produkt a data. Nekoná se tedy prodej myšlenek formou prototypu komisím manažerů ;-), absence čehokoliv co si nevydupeš ze země o datech nemluvě, ne?
Jinak mě osobně přijde axure na základní interakce jako rychlý nástroj, komplexnější raději popíšu a řeším je v rámci šablon.
Ale vidím výrazný rozdíl mezi prezentacemi a aplikacemi, takže mi článek v kontextu aplikaci přijde fajn.
Martin Valenta: vytvořit složitější interakce je v Axure velmi časově náročné a neudržitelné – hlavně pokud jde o používání proměnných, dynamických panelů, atp. Naprototypovat interakce bez chyb proto vyžaduje veliké množství času a co teprve v případě, kdy je potřeba něco změnit. Zažil jsem si to opravdu mnohokrát.
Naproti tomu Indigo nabízí mnohem jednodušší model. Nabízí možnost změnit stav stránky, propojit jednotlivé stránky mezi sebou a to celé nabízí v přehledném interaction flow / screen flow. Prototyp je tak přehledný a mnohem rychleji jej lze vytvořit.
Psal jsem to hlavně z pohledu aplikací, informační weby teoreticky prototypy nepotřebují a velice často pro ně stačí wireframy nebo mockupy. Pokud se testují s lidmi, je samozřejmě potřeba více detailu.
Jinak moc díky za komentář a za tvůj názor :).
Jan Řezáč: v GoodData jsme zodpovědní za kvalitu produktu a jsme tam právě od toho. A rychlost je stěžejní. Avšak je potřeba si samozřejmě některé věci obhájit a „vydupat“, ale na to není potřeba prototyp (což by bylo samozřejmě špatně, když by bylo potřeba prototypu).
Máš pravdu, že na jednoduché věci není Axure tak špatné – ale to asi každý nástroj. Komplexní věci bych vždy dělal raději přímo v kódu – od responsivního designu až po motion gestures (ale protože ne všichni kolegové uměli/umí kódovat, nepodařilo se mi to protlačit, protože spolupráce by pak byla teoreticky nemožná).
Ano, článek jsem psal v kontextu aplikací :-). A díky za komentář a za tvůj názor 🙂
Řekl bych, že jsi v článku trochu demagogicky shodil prototypy a nástroje na jejich tvorbu. Srovnáváš podle mne dvě odlišné situace. Práci v agentuře a práci jako in-house uxák, navíc ještě v poměrně inovativní společnosti. Těch rozdílností je tu obrovské množství a proto i vhodné nástroje se liší.
Nejde tak ani o web x aplikace. Tím nejsem nijak proti papíru (a už jsem to i zkoušel prezentovat klientovi :).
Ošklivý sup: souhlasím, že jsem některé nástroje docela shodil. Což byl ale na druhou stranu cíl. Po téměř dvou letech zkušeností s Axure bych jej už nikdy nechtěl používat a raději bych prototypoval papírově. Ideálně v jiném nástroji. A taky si myslím, že jsem to při práci v agentuře dával dost najevo :).
Samozřejmě je vždy na designerovi, aby si zvolil tu správnou cestu. Jen by měl vždy volit uvážlivě, aby byly jeho výstupy efektivní v komunikaci a iterování a hlavně to nestálo moc peněz.