Už jsem se jednou nad tématem prototypování zamyslel v článku Prototypování by nemělo být plýtvání časem a penězmi. Pokusím se na něj navázat další myšlenkou.
Prototypovat by měl umět snad každý designér. Spousta designérů si ale pod touto technikou představuje něco jiného. A bohužel příliš často pouze konkrétní formu pro vyjádření designu.
Design totiž není jen uživatelské rozhraní. Uživatelské rozhraní je vyústění designu – tedy řešení nějakého problému. A právě prototyp by měl posloužit jako nástroj pro jeho detailní prozkoumání. Nejen pro designéra, ale i pro vývojáře, stakeholdery a uživatele, kteří budou s produktem pracovat.
Není chybou designéra, že si hned neuvědomí všechny možné stavy a chování. Chybou designéra je, pokud design detailně neprozkoumá a neověří.
Prototyp nejsou jen našoupané boxíky
Vždy bychom si měli vybírat ty nejefektivnější metody, díky kterým vytvoříme co nejlepší řešení. Platí to i u prototypů, u kterých je potřeba navržené řešení prozkoumat do detailů. A případné problémy doladit ještě před implementací.
Nikdy jsem nebyl příliš velkým příznivcem programů typu Axure RP, Indigo Studio a dalších podobných. Tvorba prototypů trvá dlouho (i případné úpravy), nelze snadno použít reálná data, atp. O tvorbě responzivních rozhraní nebo dalším využití prototypů raději ani nemluvím.
Vždy jsem byl příznivcem především dvou způsobů:
- Papírové prototypy,
- Nakódované prototypy.
Cílem prototypů totiž není vizualizovat uživatelské rozhraní. Tedy takový „šedý“ komplement k Photoshopu. Je to nástroj pro zkoumání designového řešení z různých úhlů pohledu. Například:
- Jsou navržená flows logická a přímá?
- Dávají všechny interakce smysl?
- Nedostanou se lidé do slepých uliček, ze kterých nebude snadné cesty zpět?
- Používá se produkty „ergonomicky“, příjemně?
Z vlastních zkušeností vím, že „naklikat“ prototyp, který by umožnil odpovědět na výše zmíněné otázky, zabere opravdu hodně času a úsilí. Často se také designér uzavře pouze do omezené oblasti. Čímž vzniká riziko, že celkový výsledek nebude tak kvalitní.
Designér by si měl výsledek své práce vždy osahat a ujistit se, že vše navrhl správně. Protože prototyp je vyústěním práce designéra, případně celého produktového týmu.
Prototypy známých produktů
Vždy jsem se rád inspiroval u existujících produktů. Od raných nápadů až po komentáře lidí, kteří je používali.
Když Jeff Hawkins přišel s myšlenkou pro Palm Pilot (handheld zařízení nové generace, které se vejde do kapsy košile, kvalitně rozezná psaný text, atp.), prvně si jej vyřezal ze dřeva a nosil nějaký čas u sebe. A zkoušel, jak by se takové zařízení dalo používat.
Než byla prodána první počítačová myš, ve výzkumném oddělení PARC společnosti Xerox dlouho a vytrvale pracovali na co nejlepším řešení. Designeři přes noc upravovali návrhy a přes den je ověřovali s lidmi. Na funkčních prototypech, aby získali konkrétní zpětnou vazbu na používání, ergonomii, odezvu, atp.
Asi nejvíce mě zaujal vývoj produktu Microsoft Surface – interaktivní multi-touch desky. Která přinesla zcela nové prvky ovládání digitálních produktů.
V knize Brave NUI World designeři tohoto produktu popisují, jak na funkčním prototypu testovali nejen samotnou koncepci ovládání, ale i detailní interakce. Spousta nápadů je totiž revolučních. A designeři si je potřebovali osahat a ověřit s lidmi. Proto museli investovat do tvorby pokročilého interaktivního prototypu.
Tip Pokud by vás zajímaly další produkty, určitě si přečtěte knihu Designing Interactions.
Jak prototypuji v GoodData
Před pár týdny jsem začal spolupracovat na návrhu nové aplikace pro správu uživatelů. Návrhy jsem převzal od předchozího designéra, které tvořil ve spolupráci s Product Managerem.
Flows a koncepce byla rozkreslená. A protože jsem v nich neviděl žádné problémy, začal jsem návrhy více zkoumat a ověřovat s lidmi, kteří budou produkt používat.
Nejprve jsem tedy vytvořil klikatelný prototyp v Indigo Studio. Zjistil jsem, že lidé s pochopením koncepce nemají problém. Protože jsme chtěli dát lidem více volnosti a kontroly nad používáním, potřeboval jsem design „rozpohybovat“ a osahat si jej detailněji. A to i uživatelé.
S tím mi „naklikaný“ prototyp nemohl pomoci. Složitě bych vytvářel kombinace stavů, filtrů, atp. Proto jsem během jednoho dne nakódoval prototyp s veškerou funkcionalitou a téměř nad reálnými daty.
Začal jsem díky tomu zjišťovat, že je potřeba navrhnout další stavy a pár detailů upravit. Získali jsme ale také lepší odpovědi. Například:
- Více jsme rozkryli technická omezení.
- Přesnější odhady pracnosti od vývojářů.
Díky tomu mohl Product Manager tvorbu aplikace lépe zprioritizovat a vývojáři přesně viděli, co je cílem.
Přiznávám, že mám jednu obrovskou výhodu. Mnoho let jsem weby kódoval – od HTML, CSS až po JavaScript. Takže často prototyp rychleji nakóduji než naklikám.
I kolegové v GoodData většinu funkcionality prototypují přímo vkódu. Protože potřebují ověřit, že návrh skutečně vyřeší daný problém.
Zkoumejte svá řešení detailně
Ze svých zkušeností věřím, že jednoduché produkty není potřeba detailně prototypovat a zkoumat navržené řešení. U složitějších to naopak vidím jako nutnost.
Složitější digitální produkty vyžadují důkladné prozkoumání, aby byla zajištěna skutečná jednoduchost a přímost ovládání.
A vyplatí se tedy vytvořit prototyp přímo v kódu. Tvorba takového prototypu sice zabere nějaký čas, ale případné opravy se pak dělají mnohem snáz, při testování si lidé nemusí nic představovat a při interpretaci tak nedojde k omylu. A vy tak získáte přesnější odpovědi na své otázky.
Na papíře nebo wireframu nemusíte zachytit všechny stavy. Některé věci si prostě neuvědomíte, některé vás nenapadnou. A proto je důležité navrhované řešení více zkoumat a případné problémy dořešit.
Získáte tak lepší zpětnou vazbu od uživatelů, přesnější odhady vývojářů na pracnost a shodu s vedením společnosti nebo Product Managementu. A váš produkt díky tomu bude kvalitnější.