• 15.8.2017
• Jan Menčík
• Analýza a návrh SW systémů

Zapojte uživatele do hry, aneb proč je prototyp lepší než kdejaká specifikace!

Nedávno jsem se pustil do analýzy nové aplikace (modulu) pro jednu českou banku a řešení vzniká téměř od nuly. To už se dneska málokdy poštěstí, aby se něco stavělo na zelené louce ;).

Po prvních schůzkách s „businessem“ jsem zpracoval koncept řešení, nahodil pár mockupů a nakreslil hlavní procesy v UML. Z několika (5) původních business lidí se po necelém měsíci vyklubal doslova dav budoucích uživatelů - každý se svojí představou o řešení. Najednou jsem stál před rozhodnutím, kudy se vlastně ta analýza bude ubírat a jak dospět ke konsenzu. Čekalo mě psaní rozsáhlé specifikace a X schvalovacích koleček, nebo ne? Co takhle zkusit prototypování? Proč ne, řekl jsem si. A po krátké ukázce několika narychlo sesmolených oken budoucí aplikace jsem, až nečekaně, upoutal pozornost jinak vášnivě diskutujících stran zástupců z řad hypotečních specialistů, credit risku a dalších business lidí.

Postupně vzniká celkem obstojný prototyp, který ve velkém detailu vystihuje funkční stránky budoucího řešení.A specifikace? No ta se samozřejmě napsat musí, ale její tvorba, a především schvalování je opravdu už jen formalita, navíc se téměř nikdo nestydí přiznat, že by to „stejně nečetl“.

Mockup, wireframe, prototyp?

Každý, kdo se pohybuje v IT, už minimálně jeden z těchto pojmů zaslechl. Nějaký čas jsem žil v představě, že je to v zásadě to samé, možná ten prototyp jsem si spojoval s nějakým fyzickým výtvorem, a ne až tak s IT produktem (např. prototyp nějaké zbraně nebo stroje). Naopak mockup a wireframe (nákresy) jsem znal dobře z prostředí vývoje webových aplikací. Tak jak to tedy je „správně“? 

Hlavní rozdíl spočívá v tom, že mockup a wireframe jsou statické návrhy a prototyp je dynamický návrh (něco jako simulace). U prototypů můžeme jít jako návrháři do různé hloubky detailu (od základních přechodů mezi obrazovkami, až po „programování“ proměnných, jejich předávání, grafické animace, či tvorbu vlastních knihoven pro další cykly vývoje aplikace). A právě absence dynamičnosti u mockupů/wireframů je jejich hlavním úskalím – nedokáží vyjádřit fungování tak, aby bylo všem zainteresovaným stranám zřejmé (každý si to může vyložit jinak), a to se vám u kvalitního prototypu nestane!

Kdy se hodí použít prototyp?

První případ jsem naznačil v úvodu článku, ale když bych to měl zobecnit, tak je vhodné (a dokonce žádoucí) použít prototyp vždy, když potřebujeme zapojit budoucí uživatele aktivně do analýzy a zároveň chceme, aby se nad analýzou (prototypem) důsledně diskutovalo a doladilo se maximum možných detailů, které textová specifikace sama o sobě nikdy nemůže postihnout. Ale pozor, to, že uděláme prototyp neznamená, že se můžeme na specifikaci (ať už tu business nebo funkční) vybodnout, to ne, jen její sepsání a následné odsouhlasení zabere zlomek času (analytik, pokud má dobrý a odladěný prototyp, jen popíše chování prototypu a business po ujištění, že specifikace obsahuje popis chování prototypu rád „bezpracně“ podepíše finální dokumentaci).

Další využití prototypu je v každé situaci, kdy potřebujeme někomu aplikaci ukázat po funkční stránce, ale aplikace ještě neexistuje. Prototyp budoucím uživatelům (a vývojářům, testerům…) odpovídá na otázky jako „A co se stane, když kliknu na to tlačítko?“ nebo „Jak bude vypadat výsledek vyhledávání?“ nebo „Jak se bude obrazovka chovat v různých stavech/rolích?“. I zdánlivě jednoduché úlohy (vyhledávání, rozbalovací menu, role) vnášejí mezi uživatele nejistotu, když jsou pouze popsané nebo v lepším případě staticky nakreslené – tuto nejistotu prototyp odstraní během pár minut.

Posledním benefitem, který v tomto článku zmíním, je uspokojení prosté uživatelské potřeby „chci si to hned vyzkoušet“. Prototyp totiž poměrně rychle umožňuje uživatelům dát „na hraní“ částečně funkční produkt, který si mohou sami vyzkoušet a okomentovat. Zároveň to podpoří jejich fantazii a sami pak dokáží upřesnit své požadavky na základě své „User Experience“ a vyhnete se alespoň části změn v již hotové aplikaci (a změna v prototypu/analýze je samozřejmě řádově levnější).

Kroky prototypování

Prototypování má své kroky (kategorie), obvykle se uvádějí 4:

·        konceptuální,

·        nízká preciznost,

·        střední preciznost,

·        vysoká preciznost;

Na konceptuální úrovni je důležité vytvořit základní interakce a pokrýt hlavní procesy (v e-shopu by to byl třeba proces objednávky). Není třeba se zdržovat detaily, jako je super design, vedlejší procesy apod. Nejde tu o formu, ale o fungování. Možná vás to překvapí, ale konceptuální prototyp se tvoří zásadně v ruce, většinou na flipchart nebo whiteboard, který se následně nafotí a hodí do powerpointové prezentace.

Následující 3 kategorie prototypů se již tvoří s využitím nějakého SW nástroje (např. Axure, Marvel App, Proto.io a další). U prototypu s nízkou precizností začínáme brát v úvahu layout obrazovek, barvičky, tlačítka a další prvky. Postupně s přechodem na prototyp se střední až vysokou precizností přidáváme prototypu na reálnosti (hlavně po vizuální stránce). Nutně nemusíme vždy dojít až do poslední úrovně, zvláště u jednoduchých a uživatelsky nenáročných aplikací nám stačí nižší úroveň detailu. Naopak u uživatelsky náročných (klientských) aplikací je pro výsledný produkt velmi důležité vytvořit a také odzkoušet do detailu propracované prototypy, téměř k nerozeznání od finální aplikace.

Ještě váháte?

Neváhejte, vyzkoušejte a napište nám, jak se na prototypování koukáte vy, jaké máte zkušenosti. Ty nejzajímavější posty zveřejníme na našem Facebooku!

A na konec jedna klasická ukázka toho, jak by to nemělo dopadnout :)