Wireframy a interaktivní prototypy: Jak ověřit nápad dřív než kódovat

01Začněte rozhodnutím, které dnes neumíte udělat

„Potřebujeme prototyp aplikace“ není dostatečné zadání. Neříká, kterou nejistotu má návrh odstranit ani co se po testu změní. Užitečnější věta zní: „Potřebujeme zjistit, jestli vedoucí dokáže vrátit neúplný nákupní požadavek zaměstnanci a pozná, kdo je potom na tahu.“ Podle výsledku buď upravíte postup, nebo připravíte tento průchod k implementaci.

Sepište jednu stránku: pro koho řešení vzniká, jaký úkol člověk právě vykonává, jak ho zvládá dnes a kde nastává problém. Připojte důkazy, například anonymizovaný popis skutečné situace od podpory. Odlište je od domněnek týmu. Dále určete vlastníka rozhodnutí, čas na ověření a výsledek, který by vás přiměl původní návrh změnit. Když nedokážete připustit jiný závěr než „jdeme vyvíjet“, připravujete spíše prezentaci.

GOV.UK doporučuje plánovat výzkum kolem konkrétních otázek a rozhodnutí. V našem pracovním příkladu proto nebudeme prototypovat kompletní nákupní systém. Zaměříme se na vrácení neúplného požadavku, jeho opravu a opětovné předání. Účetnictví a výběr dodavatele zatím zůstávají mimo tento experiment.

02Oddělte použitelnost, poptávku a proveditelnost

Člověk může bez potíží projít návrhem produktu, který nepotřebuje. Může o produkt stát, ale firma ho nedokáže dodat za přijatelných podmínek. A technicky funkční řešení může být pro uživatele nesrozumitelné. Tyto nejistoty potřebují rozdílné důkazy. V závěru testu proto nepoužívejte samotné označení „ověřeno“ bez vysvětlení, co přesně bylo předmětem ověření.

Rozhovor po ukázce může přinést užitečné otázky k hodnotě produktu. Nadšená reakce ale není objednávka. Pro obchodní ověření navazuje průvodce od nápadu k MVP a ověřování zájmu. Technické pochybnosti předejte vývojáři jako samostatný experiment, například ověření změny stavu v testovacím prostředí dodavatele.

03Co objednáváte: wireframe, prototyp, technický pokus, nebo MVP

Pojmy si s dodavatelem vyjasněte před naceněním. Za slovem prototyp se může skrývat několik obrázků, propojené obrazovky i funkční ukázka v prohlížeči. Rozhodující je, co účastník dokáže samostatně udělat a co jen předstíráte. Počet obrazovek sám o rozsahu práce vypovídá málo.

Do objednávky napište účel, průchody, podobu výstupních souborů a odpovědnost za nábor i testování. Zahrňte také analýzu, úpravu návrhu a předání otevřených otázek. Jinak můžete dostat působivou ukázku bez odpovědi na původní problém. Širší plánování navazujícího produktu řeší článek jak naplánovat vývoj SaaS.

04Podrobnost zvyšujte tam, kde mění výsledek testu

Podrobnost neboli fidelity není jediný posuvník od ošklivého k hezkému. NNGroup rozlišuje věrnost interakce, vizuálního zpracování a obsahu. Prototyp může mít jednoduché šedé plochy, ale přesné texty a realistické chování. Právě taková kombinace se může hodit při ověřování firemního schvalování.

Chcete zjistit, zda lidé rozumějí rozdílu mezi vrácením a zamítnutím? Potřebujete skutečná označení, důsledky obou akcí a navazující stavy. Barevný styl může být zatím základní. Chcete ověřit zadávání údajů klávesnicí nebo práci čtečky obrazovky? Obrázky propojené odkazy nejsou dostatečným prostředím. Zvolte funkční prvky odpovídající zkoumanému chování.

V zadání výslovně vyjmenujte omezení: žádné reálné odesílání, předem dané údaje, simulované čekání nebo pevný počet výsledků. Každé omezení porovnejte s výzkumnou otázkou. Pokud může změnit chování účastníka, musíte prototyp dopracovat nebo závěr zúžit. Větší vizuální detail sám tento nedostatek neopraví.

05Modelový příklad: dvě cesty vrácení nákupního požadavku

Následující příklad je autorský model, nikoli projekt, výzkum ani výsledek zákazníka LISTIFY. Firma v něm schvaluje nákup vybavení. Zaměstnanec zadá požadavek, vedoucí jej kontroluje a někdy vrátí k doplnění. Předpokládáme, že skutečné rozhovory teprve mají potvrdit problém: lidé údajně nevědí, kdo má po vrácení pokračovat.

Varianta A nabízí společné tlačítko „Změnit stav“ a dlouhou nabídku. Varianta B rozlišuje akce podle aktuální situace a při vrácení vyžádá vysvětlení pro zaměstnance. Nevyhlašujeme předem vítěze. Jednodušší nabídka může pomoci orientaci, ale může také skrýt méně častý legitimní postup. V první diskusi si proto kreslíme obě cesty včetně toho, jak zaměstnanec požadavek znovu předá.

Připravíme tři konkrétní otázky: rozpozná vedoucí vhodnou akci, pochopí zaměstnanec důvod vrácení a poznají oba, kdo je na tahu? Cílem není porovnat oblibu barev. Pokud chceme oba návrhy zkoušet se stejnými lidmi, počítáme s učením a vlivem pořadí. Lepší výsledek druhého průchodu nemusí způsobit samotná varianta. Při interpretaci uvedeme pořadí a předchozí zkušenost účastníka.

06Postavte celý úkol, včetně věrohodné výjimky

Pro každý průchod si nejdřív sepište výchozí situaci, dostupné informace, rozhodnutí a konečný stav. U vedoucího začíná náš model upozorněním na požadavek, pokračuje kontrolou detailu a končí předáním k opravě. Zaměstnanec pak najde důvod, doplní údaj a odešle požadavek znovu. Obě role potřebují jasnou návaznost, i když je testujete v oddělených sezeních.

Přidejte jednu výjimku, která souvisí s hlavním rizikem. Vedoucí například požadavek vrátí bez vysvětlení a rozhraní ho vyzve k doplnění. Co uvidí zaměstnanec? Co se zachová při návratu? Vyplnění všech ideálních údajů do jediné připravené cesty by tento problém neodhalilo. Naopak modelování každé vzácné situace zbytečně oddálí první užitečné pozorování.

Použijte smyšlené názvy, částky a osoby, ale zachovejte realistickou délku a složitost. Kontrolu jednotlivých prvků můžete projít pomocí 20 pravidel UX při návrhu prototypu. Tento článek na ně navazuje organizací experimentu: každý připravený stav musí mít důvod, který souvisí s otázkou testu.

07Vyberte účastníky podle skutečné práce a okolností

Dostupní kolegové jsou užiteční pro zkušební průchod, nemusí však zastupovat budoucí uživatele. Vedoucí, který denně schvaluje nákupy, má jiná očekávání než člověk zastupující jej jednou ročně. Zaměstnanec s prvním požadavkem zase nezná interní zkratky. Určete relevantní rozdíly a při náboru se ptejte na nedávnou zkušenost, ne pouze na pracovní pozici.

Zohledněte zařízení a podmínky práce. Schvalování v telefonu mezi schůzkami se liší od soustředěné práce na velkém monitoru. Účastníkům s potřebou podpůrných technologií připravte vhodnou podobu prototypu i sezení. Omezení nástroje neoznačujte za nedostatek člověka. Pokud dané chování nelze otestovat, uveďte je mezi otevřenými otázkami a naplánujte vhodnější ověření.

Počet sezení odvoďte od rozmanitosti rolí a nejistot. Neexistuje jedno univerzální číslo, které potvrdí celý produkt. Malé kolo může odhalit konkrétní problém a umožnit další iteraci. Nemůže samo spolehlivě odhadnout jeho četnost v celé populaci. Oddělte pilotní test s kolegou od hlavních pozorování, protože zná zadání a může autorovi nevědomě pomáhat.

08Zadávejte situaci a cíl bez názvů tlačítek

NNGroup doporučuje realistické a proveditelné scénáře bez nápovědy k ovládání. Slabé zadání našeho modelu zní: „Klikněte na Vrátit k doplnění a napište komentář.“ Tak ověříte především schopnost následovat pokyn. Silnější zadání popisuje, že u požadavku chybí účel nákupu a zaměstnanec jej má doplnit, než rozhodnete.

Účastník dostane potřebný kontext: jeho roli, ukázkový požadavek a informaci, kterou jako vedoucí potřebuje. Úkol zní: „Vyřešte tento požadavek tak, aby kolega doplnil chybějící účel. Nákup zatím nechcete schválit ani definitivně odmítnout.“ Sledujte, co udělá a jak si výsledek vysvětlí. Nepředčítejte mu v úvodu budoucí stavy systému.

Pro zaměstnance připravte navazující situaci: „Potřebujete dokončit žádost o vybavení. Vedoucí vás požádal o doplnění informací. Pokračujte, jak byste to udělali v práci.“ Předem určete podmínku dokončení, například opětovné předání s doplněným účelem. Scénáře nejdřív projděte nanečisto. Opravte chybějící kontext a technické slepé uličky, nikoli formulace jen proto, že lidé nevolí vaši oblíbenou cestu.

09Veďte sezení tak, aby autor návrhu nezachraňoval výsledek

Na začátku vysvětlete účel, omezení prototypu a průběh sezení. Domluvte nakládání s poznámkami a případným záznamem; nahrávání nemá být překvapením. Ujistěte účastníka, že zkoušíte návrh a nehledáte jeho chyby. GOV.UK při moderovaném testu doporučuje především pozorovat a naslouchat.

Po zadání nechte člověka jednat. Když řekne „asi je to hotové“, požádejte ho, aby popsal, co se podle něj stalo. Neříkejte „nechcete ještě kliknout sem?“. Pokud musí moderátor pomoci, zaznamenejte kdy a jak. Dokončení po vysvětlení má jinou vypovídací hodnotu než samostatný průchod. Pomoc může být vhodná pro pokračování výzkumu, nesmí však zmizet ze závěru.

Rozlišujte problém návrhu a problém připravené ukázky. Kliknutí na nefunkční, ale logickou cestu je informace o očekávání. Neoznačujte ji automaticky za uživatelskou chybu. Zapište očekávaný výsledek a omezení prototypu. Při opakovaném výskytu zvažte rozšíření další verze. Pozorovatelé mají sledovat domluvené otázky a nezasahovat do sezení vlastními návrhy.

10Z pozorování vytvořte nález, nikoli procento úspěchu produktu

Zápis musí umožnit dohledat, co se skutečně stalo. Uložte verzi prototypu, roli, úkol, pozorované chování, případnou pomoc a výsledek. Oddělte doslovné vyjádření od interpretace. GOV.UK při analýze rozlišuje pozorování, zjištění a navazující kroky. Díky tomu lze diskutovat o příčině bez přepisování původního důkazu.

Čistě modelový zápis: ve čtyřech sezeních s vedoucími dva lidé po vrácení požadavku nevěděli, kdo má pokračovat. Jeden požádal o pomoc. To není naměřený výsledek LISTIFY ani odhad pro celý trh. Je to ilustrace, jak zapisovat malý soubor pozorování. Výrok „polovina našich zákazníků neumí schvalovat“ by z takového testu nevyplýval.

Možné vysvětlení zní, že stav „Rozpracováno“ nevyjadřuje odpovědnost. Alternativou je chybějící potvrzení nebo neznalost firemního procesu. Navrhněte úpravu stavu a potvrzení a uveďte, jak ji prověříte. Pokud měníte více prvků současně, můžete ověřit zlepšení celého průchodu, ale hůře přisoudíte efekt jediné změně. Zapisujte také případy, které první interpretaci odporují.

11Rozhodněte: změnit, doplnit důkaz, pokračovat, nebo zastavit

Seřaďte nálezy podle dopadu na důležitý úkol, závažnosti omylu a síly dostupného důkazu. Modelové nechtěné schválení nákupu potřebuje přednost před kosmetickou preferencí ikony. Samotný počet zmínek není celá priorita. Jediný závažný omyl může odhalit problém, který stojí za okamžité prošetření, přestože zatím neznáte jeho četnost.

Pro každý vybraný nález určete úpravu nebo další ověření, odpovědnou osobu a termín rozhodnutí. Připojte podmínku, při které lze pokračovat. Například musí být srozumitelné, že vrácený požadavek čeká na zaměstnance; nevyřešenou integraci musí mezitím prověřit technický pokus. Neschovávejte zbývající rizika pod celkové zelené hodnocení.

Při dalším kole používejte zaznamenanou verzi a srovnatelný cíl. Zvažte nové účastníky, aby výsledek nestál jen na zapamatované cestě. I rozhodnutí návrh zjednodušit nebo zastavit je platný výsledek. Prototypování má cenu tehdy, když jeho poznatky mohou ovlivnit investici, ne pouze potvrdit předem slíbený rozsah.

12Předejte rozhodnutí a bezpečně oddělte ukázku od provozu

Vývojáři potřebují vedle obrazovek i pravidla a důvody. Předejte výchozí stavy, přechody, role, texty, chybové situace a výsledky testů. Vysvětlete, co je schválené, co je hypotéza a co se ještě netestovalo. Pro odhad rozsahu je cenné i rozhodnutí funkci odložit. Nenahrazujte otevřenou otázku přesným obrázkem, který pouze budí dojem hotového zadání.

GOV.UK upozorňuje, že prototypový kód není automaticky vhodný pro produkci. Sdílenou ukázku proto označte jako testovací, omezte přístup a používejte bezpečná data. Skutečné platby, e-maily nebo zápisy do klientských systémů do běžného testu nezapojujte. Po skončení rozhodněte, kdo materiály potřebuje a jak dlouho je uchováte.

• Je doložená otázka, cílová role a rozhodnutí, které test podporuje?
• Jsou oddělené závěry o použitelnosti, hodnotě a technice?
• Lze dohledat verzi, scénář, pozorování a poskytnutou pomoc?
• Má každý zásadní nález vlastníka a domluvený další krok?
• Jsou výjimky a netestované části viditelně označené?
• Převzal vývojář pravidla, stavy a technické otevřené otázky?
• Je domluvené ověření implementace, přístup k ukázce a správa záznamů?

Po implementaci ověřte skutečné chování znovu, protože napojení na data i nové omezení rozhraní mohou výsledek změnit. Pro návaznost na vývoj webových aplikací připravte hlavní úkol, dostupné důkazy a seznam nejistot. To je užitečnější podklad k prvnímu jednání než neurčité zadání „udělejte nám něco podobného“.

13Časté otázky o wireframech a prototypech