Wireframy a interaktívne prototypy: Ako overiť nápad skôr než začnete programovať

01Začnite rozhodnutím, ktoré dnes neviete urobiť

„Potrebujeme prototyp aplikácie“ nie je dostatočné zadanie. Nehovorí, ktorú neistotu má návrh odstrániť ani čo sa po teste zmení. Užitočnejšia veta znie: „Potrebujeme zistiť, či vedúci dokáže vrátiť neúplnú nákupnú požiadavku zamestnancovi a rozpozná, kto má potom pokračovať.“ Podľa výsledku buď upravíte postup, alebo pripravíte tento priechod na implementáciu.

Spíšte jednu stranu: pre koho riešenie vzniká, akú úlohu človek práve vykonáva, ako ju zvláda dnes a kde nastáva problém. Pripojte dôkazy, napríklad anonymizovaný opis skutočnej situácie od podpory. Odlíšte ich od domnienok tímu. Ďalej určte vlastníka rozhodnutia, čas na overenie a výsledok, ktorý by vás prinútil pôvodný návrh zmeniť. Keď neviete pripustiť iný záver než „ideme vyvíjať“, pripravujete skôr prezentáciu.

GOV.UK odporúča plánovať výskum okolo konkrétnych otázok a rozhodnutí. V našom pracovnom príklade preto nebudeme prototypovať kompletný nákupný systém. Zameriame sa na vrátenie neúplnej požiadavky, jej opravu a opätovné odovzdanie. Účtovníctvo a výber dodávateľa zatiaľ zostávajú mimo tohto experimentu.

02Oddeľte použiteľnosť, dopyt a uskutočniteľnosť

Človek môže bez ťažkostí prejsť návrhom produktu, ktorý nepotrebuje. Môže o produkt stáť, ale firma ho nedokáže dodať za prijateľných podmienok. A technicky funkčné riešenie môže byť pre používateľa nezrozumiteľné. Tieto neistoty potrebujú rozdielne dôkazy. V závere testu preto nepoužívajte samotné označenie „overené“ bez vysvetlenia, čo presne bolo predmetom overenia.

Rozhovor po ukážke môže priniesť užitočné otázky k hodnote produktu. Nadšená reakcia však nie je objednávka. Na obchodné overenie nadväzuje sprievodca od nápadu k MVP a overovaniu záujmu. Technické pochybnosti odovzdajte vývojárovi ako samostatný experiment, napríklad overenie zmeny stavu v testovacom prostredí dodávateľa.

03Čo objednávate: wireframe, prototyp, technický pokus alebo MVP

Pojmy si s dodávateľom vyjasnite pred nacenením. Za slovom prototyp sa môže skrývať niekoľko obrázkov, prepojené obrazovky aj funkčná ukážka v prehliadači. Rozhodujúce je, čo účastník dokáže samostatne urobiť a čo iba predstierate. Počet obrazoviek sám o rozsahu práce vypovedá málo.

Do objednávky napíšte účel, priechody, podobu výstupných súborov a zodpovednosť za nábor aj testovanie. Zahrňte tiež analýzu, úpravu návrhu a odovzdanie otvorených otázok. Inak môžete dostať pôsobivú ukážku bez odpovede na pôvodný problém. Širšie plánovanie nadväzujúceho produktu rieši článok ako naplánovať vývoj SaaS.

04Podrobnosť zvyšujte tam, kde mení výsledok testu

Podrobnosť alebo fidelity nie je jediný posuvník od škaredého k peknému. NNGroup rozlišuje vernosť interakcie, vizuálneho spracovania a obsahu. Prototyp môže mať jednoduché sivé plochy, ale presné texty a realistické správanie. Práve taká kombinácia sa môže hodiť pri overovaní firemného schvaľovania.

Chcete zistiť, či ľudia rozumejú rozdielu medzi vrátením a zamietnutím? Potrebujete skutočné označenia, dôsledky oboch akcií a nadväzujúce stavy. Farebný štýl môže byť zatiaľ základný. Chcete overiť zadávanie údajov klávesnicou alebo prácu čítačky obrazovky? Obrázky prepojené odkazmi nie sú dostatočným prostredím. Zvoľte funkčné prvky zodpovedajúce skúmanému správaniu.

V zadaní výslovne vymenujte obmedzenia: žiadne reálne odosielanie, vopred dané údaje, simulované čakanie alebo pevný počet výsledkov. Každé obmedzenie porovnajte s výskumnou otázkou. Ak môže zmeniť správanie účastníka, musíte prototyp dopracovať alebo záver zúžiť. Väčší vizuálny detail sám tento nedostatok neopraví.

05Modelový príklad: dve cesty vrátenia nákupnej požiadavky

Nasledujúci príklad je autorský model, nie projekt, výskum ani výsledok zákazníka LISTIFY. Firma v ňom schvaľuje nákup vybavenia. Zamestnanec zadá požiadavku, vedúci ju kontroluje a niekedy vráti na doplnenie. Predpokladáme, že skutočné rozhovory ešte len majú potvrdiť problém: ľudia údajne nevedia, kto má po vrátení pokračovať.

Variant A ponúka spoločné tlačidlo „Zmeniť stav“ a dlhú ponuku. Variant B rozlišuje akcie podľa aktuálnej situácie a pri vrátení si vyžiada vysvetlenie pre zamestnanca. Nevyhlasujeme vopred víťaza. Jednoduchšia ponuka môže pomôcť orientácii, ale môže tiež skryť menej častý legitímny postup. V prvej diskusii si preto kreslíme obe cesty vrátane toho, ako zamestnanec požiadavku znovu odovzdá.

Pripravíme tri konkrétne otázky: rozpozná vedúci vhodnú akciu, pochopí zamestnanec dôvod vrátenia a zistia obaja, kto má pokračovať? Cieľom nie je porovnať obľúbenosť farieb. Ak chceme oba návrhy skúšať s rovnakými ľuďmi, počítame s učením a vplyvom poradia. Lepší výsledok druhého priechodu nemusí spôsobiť samotný variant. Pri interpretácii uvedieme poradie a predchádzajúcu skúsenosť účastníka.

06Postavte celú úlohu vrátane vierohodnej výnimky

Pre každý priechod si najskôr spíšte východiskovú situáciu, dostupné informácie, rozhodnutie a konečný stav. Pri vedúcom sa náš model začína upozornením na požiadavku, pokračuje kontrolou detailu a končí odovzdaním na opravu. Zamestnanec potom nájde dôvod, doplní údaj a odošle požiadavku znovu. Obe roly potrebujú jasnú nadväznosť, aj keď ich testujete v oddelených sedeniach.

Pridajte jednu výnimku, ktorá súvisí s hlavným rizikom. Vedúci napríklad požiadavku vráti bez vysvetlenia a rozhranie ho vyzve na doplnenie. Čo uvidí zamestnanec? Čo sa zachová pri návrate? Vyplnenie všetkých ideálnych údajov do jedinej pripravenej cesty by tento problém neodhalilo. Naopak modelovanie každej zriedkavej situácie zbytočne oddiali prvé užitočné pozorovanie.

Použite vymyslené názvy, sumy a osoby, ale zachovajte realistickú dĺžku a zložitosť. Kontrolu jednotlivých prvkov môžete prejsť pomocou 20 pravidiel UX pri návrhu prototypu. Tento článok na ne nadväzuje organizáciou experimentu: každý pripravený stav musí mať dôvod, ktorý súvisí s otázkou testu.

07Vyberte účastníkov podľa skutočnej práce a okolností

Dostupní kolegovia sú užitoční pri skúšobnom priechode, nemusia však zastupovať budúcich používateľov. Vedúci, ktorý denne schvaľuje nákupy, má iné očakávania než človek zastupujúci ho raz ročne. Zamestnanec s prvou požiadavkou zasa nepozná interné skratky. Určte relevantné rozdiely a pri nábore sa pýtajte na nedávnu skúsenosť, nielen na pracovnú pozíciu.

Zohľadnite zariadenia a podmienky práce. Schvaľovanie v telefóne medzi stretnutiami sa líši od sústredenej práce na veľkom monitore. Účastníkom s potrebou podporných technológií pripravte vhodnú podobu prototypu aj sedenia. Obmedzenie nástroja neoznačujte za nedostatok človeka. Ak dané správanie nemožno otestovať, uveďte ho medzi otvorenými otázkami a naplánujte vhodnejšie overenie.

Počet sedení odvoďte od rozmanitosti rolí a neistôt. Neexistuje jedno univerzálne číslo, ktoré potvrdí celý produkt. Malé kolo môže odhaliť konkrétny problém a umožniť ďalšiu iteráciu. Nemôže samo spoľahlivo odhadnúť jeho výskyt v celej populácii. Oddeľte pilotný test s kolegom od hlavných pozorovaní, pretože pozná zadanie a môže autorovi nevedomky pomáhať.

08Zadávajte situáciu a cieľ bez názvov tlačidiel

NNGroup odporúča realistické a uskutočniteľné scenáre bez nápovedy k ovládaniu. Slabé zadanie nášho modelu znie: „Kliknite na Vrátiť na doplnenie a napíšte komentár.“ Tak overíte predovšetkým schopnosť nasledovať pokyn. Silnejšie zadanie opisuje, že pri požiadavke chýba účel nákupu a zamestnanec ho má doplniť, skôr než rozhodnete.

Účastník dostane potrebný kontext: svoju rolu, ukážkovú požiadavku a informáciu, ktorú ako vedúci potrebuje. Úloha znie: „Vyriešte túto požiadavku tak, aby kolega doplnil chýbajúci účel. Nákup zatiaľ nechcete schváliť ani definitívne odmietnuť.“ Sledujte, čo urobí a ako si výsledok vysvetlí. Nepredčítavajte mu v úvode budúce stavy systému.

Pre zamestnanca pripravte nadväzujúcu situáciu: „Potrebujete dokončiť žiadosť o vybavenie. Vedúci vás požiadal o doplnenie informácií. Pokračujte, ako by ste to urobili v práci.“ Vopred určte podmienku dokončenia, napríklad opätovné odovzdanie s doplneným účelom. Scenáre najskôr prejdite nanečisto. Opravte chýbajúci kontext a technické slepé uličky, nie formulácie len preto, že ľudia nevolia vašu obľúbenú cestu.

09Veďte sedenie tak, aby autor návrhu nezachraňoval výsledok

Na začiatku vysvetlite účel, obmedzenia prototypu a priebeh sedenia. Dohodnite nakladanie s poznámkami a prípadným záznamom; nahrávanie nemá byť prekvapením. Uistite účastníka, že skúšate návrh a nehľadáte jeho chyby. GOV.UK pri moderovanom teste odporúča predovšetkým pozorovať a počúvať.

Po zadaní nechajte človeka konať. Keď povie „asi je to hotové“, požiadajte ho, aby opísal, čo sa podľa neho stalo. Nehovorte „nechcete ešte kliknúť sem?“. Ak musí moderátor pomôcť, zaznamenajte kedy a ako. Dokončenie po vysvetlení má inú výpovednú hodnotu než samostatný priechod. Pomoc môže byť vhodná na pokračovanie výskumu, nesmie však zmiznúť zo záveru.

Rozlišujte problém návrhu a problém pripravenej ukážky. Kliknutie na nefunkčnú, ale logickú cestu je informácia o očakávaní. Neoznačujte ju automaticky za používateľskú chybu. Zapíšte očakávaný výsledok a obmedzenie prototypu. Pri opakovanom výskyte zvážte rozšírenie ďalšej verzie. Pozorovatelia majú sledovať dohodnuté otázky a nezasahovať do sedenia vlastnými návrhmi.

10Z pozorovania vytvorte zistenie, nie percento úspechu produktu

Zápis musí umožniť dohľadať, čo sa skutočne stalo. Uložte verziu prototypu, rolu, úlohu, pozorované správanie, prípadnú pomoc a výsledok. Oddeľte doslovné vyjadrenie od interpretácie. GOV.UK pri analýze rozlišuje pozorovania, zistenia a nadväzujúce kroky. Vďaka tomu možno diskutovať o príčine bez prepisovania pôvodného dôkazu.

Čisto modelový zápis: v štyroch sedeniach s vedúcimi dvaja ľudia po vrátení požiadavky nevedeli, kto má pokračovať. Jeden požiadal o pomoc. Nie je to nameraný výsledok LISTIFY ani odhad pre celý trh. Je to ilustrácia, ako zapisovať malý súbor pozorovaní. Výrok „polovica našich zákazníkov nevie schvaľovať“ by z takého testu nevyplýval.

Možné vysvetlenie znie, že stav „Rozpracované“ nevyjadruje zodpovednosť. Alternatívou je chýbajúce potvrdenie alebo neznalosť firemného procesu. Navrhnite úpravu stavu a potvrdenia a uveďte, ako ju preveríte. Ak meníte viac prvkov súčasne, môžete overiť zlepšenie celého priechodu, ale ťažšie priradíte efekt jedinej zmene. Zapisujte aj prípady, ktoré prvej interpretácii odporujú.

11Rozhodnite: zmeniť, doplniť dôkaz, pokračovať alebo zastaviť

Zoraďte zistenia podľa dopadu na dôležitú úlohu, závažnosti omylu a sily dostupného dôkazu. Modelové nechcené schválenie nákupu potrebuje prednosť pred kozmetickou preferenciou ikony. Samotný počet zmienok nie je celá priorita. Jediný závažný omyl môže odhaliť problém, ktorý stojí za okamžité preskúmanie, hoci zatiaľ nepoznáte jeho výskyt.

Pre každé vybrané zistenie určte úpravu alebo ďalšie overenie, zodpovednú osobu a termín rozhodnutia. Pripojte podmienku, pri ktorej možno pokračovať. Napríklad musí byť zrozumiteľné, že vrátená požiadavka čaká na zamestnanca; nevyriešenú integráciu musí medzitým preveriť technický pokus. Neskrývajte zostávajúce riziká pod celkové zelené hodnotenie.

Pri ďalšom kole používajte zaznamenanú verziu a porovnateľný cieľ. Zvážte nových účastníkov, aby výsledok nestál iba na zapamätanej ceste. Aj rozhodnutie návrh zjednodušiť alebo zastaviť je platný výsledok. Prototypovanie má cenu vtedy, keď jeho poznatky môžu ovplyvniť investíciu, nielen potvrdiť vopred sľúbený rozsah.

12Odovzdajte rozhodnutia a bezpečne oddeľte ukážku od prevádzky

Vývojári potrebujú okrem obrazoviek aj pravidlá a dôvody. Odovzdajte východiskové stavy, prechody, roly, texty, chybové situácie a výsledky testov. Vysvetlite, čo je schválené, čo je hypotéza a čo sa ešte netestovalo. Pre odhad rozsahu je cenné aj rozhodnutie funkciu odložiť. Nenahrádzajte otvorenú otázku presným obrázkom, ktorý iba budí dojem hotového zadania.

GOV.UK upozorňuje, že prototypový kód nie je automaticky vhodný pre produkciu. Zdieľanú ukážku preto označte ako testovaciu, obmedzte prístup a používajte bezpečné dáta. Skutočné platby, e-maily alebo zápisy do klientskych systémov do bežného testu nezapájajte. Po skončení rozhodnite, kto materiály potrebuje a ako dlho ich uchováte.

• Je doložená otázka, cieľová rola a rozhodnutie, ktoré test podporuje?
• Sú oddelené závery o použiteľnosti, hodnote a technike?
• Dá sa dohľadať verzia, scenár, pozorovanie a poskytnutá pomoc?
• Má každé zásadné zistenie vlastníka a dohodnutý ďalší krok?
• Sú výnimky a netestované časti viditeľne označené?
• Prevzal vývojár pravidlá, stavy a technické otvorené otázky?
• Je dohodnuté overenie implementácie, prístup k ukážke a správa záznamov?

Po implementácii overte skutočné správanie znovu, pretože napojenie na dáta aj nové obmedzenia rozhrania môžu výsledok zmeniť. Na nadväznosť na vývoj webových aplikácií pripravte hlavnú úlohu, dostupné dôkazy a zoznam neistôt. To je užitočnejší podklad na prvé rokovanie než neurčité zadanie „urobte nám niečo podobné“.

13Časté otázky o wireframeoch a prototypoch