Použitelnost, nebo User Experience, nelze nějak jednoduše, levně a efektivně měřit. Ono je už dost těžké jasně vymezit, co to použitelnost vlastně je.

V naší firmě máme CMMI, ISO 9001 a podobné procesní normy a pokud naše oddělení nechce (ani nemůže) stát mimo, musíme zavést i měření našich výstupů, tedy použitelnosti. Museli jsme se s tématem tedy poprat.

Dříve jsme zkusili se našich uživatelů ptát, jakou by zvolené funkcionalitě nebo aplikaci dali školní známku. Když jsme s použitelností začínali, měl náš software dost problémů, proto bylo běžné, že dostával trojky a čtyřky. To pak byl dobrý argument pro vedení, že se problémem musí něco dělat. Časem jsme si mákli a dostali náš software na celkem dobrou úroveň. U uživatelských testování se později stalo jen výjimečně, že by účastník nesplnil zadané úkoly. Ve školním hodnocení jsme pak dostávali většinou dvojku nebo trojku. A to už se problém metriky ukázal v celé šíři. Lidé u nás jsou zvyklí, že trojka je celkem špatná známka a jednička zase moc super. Navíc je tento systém nepřenosný do zahraničí (naše vedení, klienti…). Další potíží bylo, že uživatelé často nevěděli, co přesně hodnotí (grafika super, tak vám dám za jedna). Proto nám nakonec tento způsob přestal vyhovovat. Z počátku pomohl, pak se přežil.

Hledal jsem jinou metodiku. Nakonec mě oslovila populární metoda SUS. Je to deset jasných specifických otázek a jejich bodové ohodnocení. Výsledkem je číslo 0–100. Čísla se dají srovnávat, dají se dělat grafy s trendy, dají se sledovat jednotlivé odpovědi, dají se porovnávat jablka s hruškami.

SUS byl vymyšlen hodně, hodně dávno a lze ho aplikovat na jakýkoliv systém, třeba hardwarový. Možná v některých případech jsou některé otázky irelevantní (pro webové stránky prý nic moc, zkuste pohledat), pro naše softwary to sedne dobře. Doporučuji.

A na co si dát při zavádění SUS pozor? Jen buďte pozorní a obezřetní při vyhodnocování výsledků. Je velmi důležité se ptát správných lidí – musí to být vaše cílová skupina, uživatelé nebo skupina, kterou chcete zkoumat. Jinak dostanete výsledky, které jsou mimo.

A jak prezentovat výsledky? Když někomu například řeknete, že SUS vyšel 64, moc mu toho neřeknete. Ale existuje pěkná studie, kde je jednotlivým hodnotám přiřazeno přídavné jméno nebo jiné slovní hodnocení. A s tím už lze prezentovat velmi lehce.

Většinou posluchače zajímá, jakých hodnot dosahují známé softwary (Office, Creative Suite, Apple). Ať jsem hledal, jak jsem hledal, nic jsem nenašel. Pokud se vám poštěstí lépe, pochlubte se, prosím.

Ještě dodám, že jsem na otázku z titulku neodpověděl. Jen jsem napsal, jak to děláme u nás, u softwaru pro enterprise. Daleko lepší odpověď, s mnoha možnostmi, dostanete v knize Measuring the User Experience: Collecting, Analyzing, and Presenting Usability Metrics. Doporučuji, je tam přehled jak kvalitativních, tak kvantitativních postupů.

Zamyslete se na redukční dietou. Ta sice bude bolet, ale pravděpodobně nejvíc bude trpět vaše ego ve spojení se sentimentem (Cože, toto mám odstranit? Vždyť to byla práce to vytvořit!! A jeden týpek to používá). Ale věřte mi a tomuto pěknému článku, že čím má aplikace méně (správné) funkcionality, tím se lépe používá.

Jeden kolega klade říká univerzální == na houby. A myslím, že co se týče aplikací, má pravdu. Aplikace mají dělat jen něco a to mají dělat pořádně.

Ikona

• Spoří místo (16 x 16 pixelů i menší).
• Může být designový prvek.
• Má konstantní rozměry, více ikon lze jednoduše zarovnat pod sebe i vedle sebe. To se hodí do různých toolbarů.
• Rychleji ji najdete a rozpoznáte, pokud jste v aplikaci zběhlí. Ikony hledáte na úrovni reflexů, texty vyžadují racionální vrstvy mozku.
• Nemusí se lokalizovat. Lokalizace je drahá záležitost.

Text

• Význam je jasný – primárně přemýšlíme ve slovech.
• Nemusí se učit – mnoho ikon napoprvé nedáte.
• Je mnohem levnější – vymyslet a nakreslit jednoduchou dobrou ikonu je práce na hodinu, pokud máte praxi.

Celkově z toho vychází, že jak text, tak ikony mají své místo. Ikony jsou nevhodné pro rychlý start, texty zase mohou zdržovat zkušené uživatele. Ale nemusí.

Od ikon nečekáme, že je intuitivně pochopíme bez komentáře. Ty doby tady možná byly když Susan Kare začínala. Aplikace byly velmi jednoduché. Třeba my v jedné rozsáhlé aplikaci máme skoro tisíc ikon a některé mají zobrazit nuance nuancí nebo permutace permutací. Je to extrém, samozřejmě. Ale ani v malých specializovaných aplikacích není možné udělat ikony intuitivní (odstavec, variabilní odstavec, neviditelný odstavec, text, neviditelný text, text jako proměnná… a to vše ve velikosti 16 x 16 pixelů).

Ikony se musíme naučit. Proto nikdy nedělejte ikony bez nápovědy. Až se je naučíme, rady by nás zdržovaly. Proto nikdy nedávejte pod ikony popisek – ani vypínací, vždy bude některá ikona nezřejmá, a proto si to nikdo nevypne.

Ikony se musíme naučit. Proto nikdy nedávejte ikony na místa, kde je důležitá rychlá orientace nováčků. Informační kiosek v administrativní budově, legenda v jízdním řádu, katalog výrobků nebo domovská stránka webového obchodu by nikdy neměla mít zvláštní ikony (všeobecně známý nákupní vozík na e-shopu samozřejmě ano, ale kategorie výrobků rozhodně ne).

Uvedu příklad.

Chceme si vybavit kuchyni elektrospotřebiči. Vůbec jim nerozumíme a potřebujeme se zorientovat. Vezmeme si katalog, kde je 20 stejných trub. Jsou tam fotky – stejné nerezové obdélníky se sklem a s čudlíky. Jmenují se také stejně AKZ a trojmístné číslo. Pod každým obrázkem je asi dvanáct ikon. Čert aby se v nic vyznal, vysvětlení je kdesi jinde v katalogu a zapamatovat si všech 24 významů je jako bych hrál pexeso. Pro nás je dobrá srovnávací tabulka na následující straně, ale grafický přehled je nám na nic – použitelnost tedy mizerná.

Vezměme to ale z pohledu obchodníka. Ten těch katalogů má asi dvacet a všude se opakují stejné vlastnosti. Do katalogů se dívá denně. Pro něj je dobré, že tam jsou stránky s ikonami, které umí, rychle se zorientuje a může před námi machrovat, jak to všechno zná a lépe nás oblbnout. Výborná použitelnost.

Tyto diametrálně rozdílné výsledky použitelnosti jedné věci jsou také skvělým argumentem pro tvorbu person.

Mezi lidmi, i mezi těmi v IT, panuje mylná představa, že pro provedení uživatelského testování potřebujete speciální hardware a software, místnosti s poloprůhlednými skly, dobře vyškolené a zkušené psychology a podobně. Vůbec ne. Uživatelské testování můžete rozjet ve vaší firmě zítra ráno (no dobrá, do týdne) a nebude vás to stát nic, kromě času několika lidí. Do uživatelského testování je samozřejmě možno dát hodně peněz, ale pokud jste ho ještě nikdy neprováděli, byly by vyhozené. Dobré, neomezované pracoviště lze vytvořit do 50 000 korun (software – 1000 USD, normální vyhrazený počítač – 1500 USD?, kamera – 20 USD, mikrofon – 10 USD), ale jak si ukážeme v tomto článku, lze se bez této investice obejít.

Nyní popíši doporučený průběh vašeho prvního uživatelského testování. V dalších příspěvcích popíši ideální/optimální stav.Nejdříve je třeba vymyslet, co chcete testovat. Uživateli by mělo splnění úkolu trvat podle vás asi půl až tři čtvrtě hodiny. Ne víc, ono se to určitě protáhne na hodinu nebo i na dvě. Asi se vám bude zdát, že to bude jen malá část aplikace, to nevadí.

Napíšete zadání. Mělo by být krátké a stručné a mělo by hovořit uživatelovým jazykem. Dobrý příklad: Přišel jsi do práce a našel jsi v mailu požadavek na ocenění projektu, zpracuj nabídku. Špatný příklad: Vytvoř nový projekt v nabídce Ocenění, ulož ho… Zadání má být kompletní, měly by tam být napsány cesty k souborům, se kterými se bude pracovat, hesla a podobně.

Také je třeba specifikovat, koho chcete testovat. Pokud už jste pokročili v UCD, prostě vyberete roli nebo personu a jste hotovi. Tu nyní samozřejmě nemáte, proto se zamyslíte, komu je funkcionalita určena.

Mezi vašimi kolegy nebo zákazníky najdete 3–5 lidí, kteří budou ochotni se testování zúčastnit a kteří více méně odpovídají vašim představám o uživatelích testované funkcionality. Lepší jsou kolegové, jsou lépe k dispozici a výsledky s nimi budou taky dobré. Zákazníky se nezdržujte.

Naplánujete termín testování. Na jednu testovanou osobu počítejte hodinu a půl, takže pět lidí zabere asi den.

Sezvěte všechny zúčastněné. Testovanou osobu, moderátora, odborníka na použitelnost, produktového analytika, hlavního programátora, programátora funkcionality… Všechny, co mohou ovlivnit podobu aplikace. Ideálně jsou v místnosti, kde se testuje, dva, maximálně tři lidé. Zájemců bývá víc, proto je dobré obrazovku testovacího (normálního) počítače přenášet jinam. První testy ale proveďte se všemi lidmi, je to kolektivní zážitek.

Postupně proveďte test se všemi uživateli, každý z účastníků by si měl psát poznámky, co by se dalo v aplikaci zlepšit. Podrobnosti o průběhu samotného testu vydají na samostatný článek.

Po skončení testů, nejlépe na druhý den, by se měli všichni pozorovatelé sejít na společné schůzce a projít si své poznámky. Mnohé se bude shodovat s poznámkami ostatních, uživatelé budou mít podobné problémy a chování. Vedoucí schůzky by měl zajistit, aby se všechny náměty zaznamenaly do firemního systému tak, aby se jimi někdo zabýval a do některé příští verze se změny v softwaru provedly.

A to je vše. Je to dlouhý článek, ale když si ho projdete, zjistíte, že je to celé hodně jednoduché. Vlastně je to jen trocha organizace.

Sledování pohybu očí

Sledování očí má smysl a je to velice dobrá technika. Ale na něco jiného, než na vylepšování aplikací. Hodí se na webové stránky a na letáky. U webu máte několik sekund na to potenciálního zákazníka zaujmout. V letáku je to podobné. Kdyby například tento server měl za cíl vychytat si SEO a profitovat z náhodných návštěvníků, kteří si budou kupovat elektroniku tady a ne v jednom z milionu úplně stejných obchodů, testování pohybu očí by pomohlo ulovit nějaké to procento lidí navíc. Ale že je tento server postavený na pravidelných návštěvnících, je důležitější zjišťovat a řešit jiné věci. Že lidem chybí nějaká vlastnost, že by něco bylo lepší dělat lépe nebo jaká témata čtenáře (uživatele) zajímají.V aplikacích je to stejné, lidé s nimi pracují dlouhodobě a naučili se v tom chodit. Takže jejich kroky jsou rychlé, mechanické a (někdy) zbytečně dlouhé. Třeba se cesty učili před několika lety a nikdo jim neřekl o nových zkratkách a sami je neobjevili. Sledováním očí bychom zjistili, že je vše v pořádku – chodí rychle a plynule.

Speciální týmy pozorovatelů

Někdy je ve filmech vidět, jak je test promyšlen a naplánován do detailů, kontroluje se každá odchylka od připraveného scénáře, kreslí se grafy, vyhodnocuje se pomocí superpočítače a týmu psychologů. Testů jsou desítky. Jistě by to tak bylo zajímavé dělat. Vy to tak nedělejte. Toto celé by stálo spousty peněz. Udělejte to co nejjednodušeji a nejlevněji. Získáte “jen” 80 procent podnětů a bude vás to stát tisícinu peněz a času. Udělejte 3-5 testů a pozvěte ke sledování (sdílení obrazovek) ty, kdo s testovanou oblastí mají u vás co do činění.

Poloprůhlené stěny

Někde (ve filmech) jsou k vidění poloprůhledné stěny. Je doba počítačová, kamery si dáte, kam budete chtít a pracovní plochu je stejně dobré přenést do jiného počítače. Jestli nevíte co s penězi, vybudujte si dvoumístnost jen na testování, jinak to jsou zbytečně vyhozené peníze.

Nahrávání a vyhodnocování videa

Když jsme s uživatelskými testováními začínali, koupili jsme speciální software (Morae) pro nahrávání a vyhodnocování videa. Snímá se obrazovka, video z kamery, zvuk, myš, kliky, klávesy… spousta věcí. Při vyhodnocování lze dělat grafy, statistiky, stříhat video…

Problém je, že když testujete na třech lidech po hodině, jen přehrání záznamu zabere další tři hodiny a to je dost času. Proto se snažíme všechny podněty zaznamenat už v průběhu testu a záznam už nevyhodnocujeme. Test nahráváme jen pro případ sporů (což se skoro neděje), pokud se chceme podívat na nějakou konkrétní situaci (zaznamenáme si čas) nebo pro kolegy, kteří nejsou v době testu přítomni. Ale záznamy jako takové nijak neprocházíme.

Trik triků

Největší trik, který nikdy nezklame, je tento. Udělejte uživatelské testování co nejlevnější a co nejjednodušší. Tedy skoro zdarma. A dělejte je furt, za tu cenu si to můžete dovolit.

Uživatelské testování softwaru je možné dělat všemožnými způsoby, ale vždy půjde o jeden princip. Uživateli připravíme co nejvěrněji prostředí, na které je zvyklý a necháme ho dělat práci, kterou běžně dělá nebo by měl dělat. Při tom ho pozorujeme a snažíme se ho co nejmíň vyrušovat. Získané podněty vyhodnocujeme až poté. Cílem je, získat podněty, ne jejich řešení.

Nejlepší by bylo testovat na pracovišti uživatele, to je ale zřídka možné. Minimálně je to nákladnější.

Role

Na uživatelském testování se (u nás) podílí několik důležitých rolí, bývají spojeny.

• Zadavatel vymyslí, co, jak a s kým by se mělo testovat.
• Koordinátorka zajistí testované osoby, vytvoří rozvrh a pozve všechny účastníky.
• Mediátor vede testování a zajišťuje, aby proběhlo optimálně podle zásad vedení testování.
• Hlavní pozorovatel rozumí do detailu zkoumané problematice a komunikuje s testovanou osobou.
• Pozorovatelé test pozorují, většinou vzdáleně, a stejně jako ostatní si dělají poznámky. Po skončení testu se podílejí na jeho vyhodnocení.
• Tester je vždy jen jeden. Plní zadané úkoly a nechá se pozorovat.
• Psychology u nás nemáme.

Poučení pozorovatelů

Účastníci by se měli sejít před samotným testem. Pokud je to pro někoho poprvé, mediátor (povede test, zná techniky a bude hlídat, aby se dodržovaly) jim dá poučení o tom, že cílem testování je získat podněty a ne řešení, že je třeba uživateli vytvořit co nejreálnější prostředí, jako by byl sám (neradit, nenavádět, nepomáhat a to ani souhlasným nebo nesouhlasným pomrukáváním). Pokud pozorovatele něco zaujme, může se zeptat, pokud ho nebude moc rušit. Lépe je se zeptat až na konci, kdy proběhne krátké intrview.

Je třeba předem pozorovatelům zakázat bavit se vzájemně během testu. Je to totiž lákavé nejen najít problém, ale rovnou se podělit o řešení. Proto se to často při testování stává, ovšem moderátor má takové diskuze tlumit už v zárodku. Důvod je ten, že pokud někdo diskutuje, nepozoruje test a navíc ruší ostatní.

Dále je dobré zmínit, že test by měl trvat hodinu a že pokud přesáhne 90 minut, bude ukončen třeba v polovině. Uživatel je po té době unavený a to, co se nestihne otestovat, by se mohlo zahrnout později do samostatného  testu. Je dobré, myslet na dojem, který si testovaná osoba odnese. Jednak o tom bude mluvit s kolegy, ale také se dá očekávat, že ji ještě někdy o účast na testování požádáme. Všem přítomným také vysvětlíme, co mají dělat. Co nejméně rušit svou přítomností a psát si poznámky, kdykoliv je napadne nějaké vylepšení, které by uživateli usnadnilo práci. Někdo si papír a tužku nevezme (to jsou ti optimisté, co si myslí, že si ty dva nápady zapamatují), buďme připraveni. Dále je třeba říct, že s testerem budou mluvit dva lidé: mediátor a hlavní pozorovatel (to je člověk, který většinou připravoval zadání a problematice rozumí).

Před testem je tak třeba připravit počítač, tedy nainstalovat potřebný software, někam umístit soubory, které bude uživatel při práci potřebovat a podobně. Je dobré myslet na to, že před druhým a dalšími testy, bude třeba odstranit to, co tam tester vytvořil nebo modifikoval.

Poučení testera

Konečně přijde tester. Pokud nemá s uživatelským testováním zkušenosti, bude mírně vystresovaný, i když to asi nepřizná. Je třeba mu poděkovat za to, že přišel pomoci zlepšit použitelnost softwaru, který používá nebo možná bude. Pak je nutné ho ujistit, že netestujeme jeho, ale software – že pokud mu něco nepůjde, je to problém softwaru a ne jeho. Za každé jeho selhání budou peskováni vývojáři a problémy odstraní. Dále je dobré zmínit, že se snažíme simulovat jeho pracovní prostředí a ať pracuje, jak je zvyklý. (Hodně lidí tady poznamenává, že nejsou typičtí uživatelé. Nechme je při tom.) My se budeme tvářit, že tady nejsme a nebudeme mu pomáhat. Úkoly má splnit samostatně a po svém. Může používat vše, co má běžně k dospozici, tedy internet, dokumentaci, poznámky, jiný software… A pokud se někde zasekne, může zavolat na podporu. Dále je nutné testera vybídnout, aby komentoval, co dělá, na čím přemýšlí, co ho napadlo a podobně.

Test

Po poučení dáme testerovi vytištěné zadání jeho úkolů. Poznamenáme, že je jednoduché (mělo by být) a že by ho měl zvládnout. Necháme ho zadání si v klidu přečíst, případně mu řekneme další informace. Když začne pracovat na počítači, ujistíme se, že zadání rozumí. Většinou ho řekne vlastními slovy. A většinou začne něco beze slova klikat. I když vidíme, co dělá, je třeba ho rozmluvit, pokud nic neříká, ptát se, co dělá, nad čím přemýšlí… Měl by téměř bez ustání mluvit. Po chvíli si na to zvykne a svou práci komentuje.

Když jde špatnou cestou, necháme ho a pozorujeme, jak a kdy se opraví (nezkušené pozorovatele často svrbí jazyk a když to nevydrží, má je mediátor taktně nebo jakkoliv upozornit). Právě slepé uličky a to, jak se z nich uživatel dostane, je na celém testování to nejpřínosnější (uživatelé si je v reálu také projdou). Když mají pozorovatelé dotaz, měli by si ho nechat na závěrečnou diskuzi. Pokud je krátký nebo by nerušil, je možné se zeptat rovnou. Ale od toho uživatelské testování není. Tester by se měl hlavně soustředit na plnění úkolu.

Tester se občas zasekne a neví, jak dál. Většinou se zeptá na radu. Je třeba mu říct, že my tu běžně nejsme a naopak chceme zjistit, jak to samostatně vyřeší. Většinou na to přijde. Pokud skutečně ne, připomeňne mu možnosti, které má, tedy dokumentaci, internet… a zeptáme se ho, jak by to řešil sám – to pozorovatele samozřejmě zajímá. Když si přesto neví rady, připomeneme mu možnost si zavolat na podporu.

Osvědčilo se naaranžovat k tomuto účelu vedle počítače dětský plastový telefonek (z cukrárny, za sedm korun). Bez něj často není jasné, jestli je podpora stále na telefonu nebo už ne. Také to trochu odlehčí situaci – fakt se tím dovolá. Někdo z pozorovatelů zahraje podporu na druhé straně telefonu.

Tester většinou má po simulovaném zavolání na podporu tendenci jen čekat na radu, když už všichni vidí, co dělal. Je přínosné nechat ho, ať řádně zatelefonuje, zformuluje problém a dostane odpověď, jakou by asi dostal od podpory. Odpovědi z podpory by měly být takové, jako by se od podpory čekaly, stručné a nepřímé. Podpora často neví, kde je problém, jen nabídne, co by se mohlo zkusit.

Zde je důležité zdůraznit, že pokud software nefunguje podle očekávání (padá, funkcionalita se chová jinak, než jsme čekali), testera v tom nenecháme (pokud to nechceme testovat) a problém vyřešíme nebo popíšeme, jak by to mělo být správně. Software by měl být bez chyb, ale uživatelské testování se často dělá na posledních verzích, tedy na alfách a tak se stabilitou to může být na hraně. Nemělo by to ale být pravidlo – ostatně před testem bychom si měli úkol sami splnit, abychom se ujistili, že je vše v pořádku.

Rozhovor po testu

Když tester splnil všechny úkoly, poděkujeme mu za pomoc a měli bychom se ho zeptat na jeho dojmy a připomínky k tomu, jak dobře se mu úkoly plnily, co by si přál v aplikaci změnit… Zde je také prostor klást dotazy, které jednotlivé pozorovatele napadly během testování. Tady už jde o diskuzi, je možné testerovi poradit nějaké triky, které nezná (je to uživatel, bude rád, že přišel). Většinou i z této debaty vzejdou zajímavé podněty.

My se ještě ptáme, jakou známku by tester dal použitelnosti testovaných funkcionalit. Je to zajímavé slyšet, zvláště horší známky jsou argumentem pro to, aby se “něco změnilo”.

Při celém testování i při diskuzi je důležité mít stále na paměti, že tester tady není k tomu, aby hledal řešení problémů. Můžeme se ho zeptat, jaké řešení by očekával, ale pokud neví, nesmíme na něj naléhat. Hledat řešení je naše práce, ne práce uživatelů ani testerů. Je dobré mu to i říct.

Poděkování

Na závěr bychom měli testerovi poděkovat za přínos použitelnosti aplikace, kterou používá. A přínos to je. Také je dobré mu dát za námahu drobný dárek. Prvním účastníkům jsem třeba dával nanuk, a tak když přišli z testování do své pracovny (byli to kolegové), většinou se jich všichni ptali na dojmy a jejich odpověď byla, že to bylo super, že dostali nanuk.

To asi vyplývá z toho, že na taková nezaběhnutá testování lidé chodí s obavami (budou se na mě dívat, dokonce nahrávat a co když se ukáže, že něco neumím…) a na konci to z nich spadne a vlastně si uvědomí, že to nebylo hrozné, nikdo na ně nekřičel… a dokonce dostali dárek.

Po nanucích jsem dával různé pamlsky a když už testování pro většinu kolegů byla stará vesta, přestal jsem s tím. Ale pěkně poděkovat se musí vždy.

A to je celé. Je to dlouhý článek, ale uživatelské testování je jednoduché.

Po půl roce musím konstatovat, že to bylo a ještě bude hodně práce, ale že jsem s výsledky nadmíru spokojený.

Měl jsem asi osm přednášek na různá témata (jak konzultovat, tvorba prototypů, role a persony, uživatelské testování, návrhové vzory…) a dost jsme toho společně procvičili a prokonzultovali. Dobré bylo, že v rámci výuky jsem se donutil přečíst spousty knih a článků – dost mě to namotivovalo. Budu v tom pokračovat.

Když učíte, sami se toho spousty naučíte.Nyní postupně nasazuji absolventy do vývoje, budou jeho integrální součástí. Ještě mě bude stát dost sil je zapracovat, ale důležité je, že projekt má stále podporu vedení a že to ergonomy dost baví a stále mají chuť do práce. Pokryjeme – podle priority podrobně nebo méně – celou produktovou řadu. Ani jsem si nedoufal.

Nyní o důležitosti a nutnosti mít dobrou použitelnost u nás nikdo nepochybuje – o tom se nediskutuje. Řešíme jen “jak” a v tom máme dobře našlápnuto.

Sebekriticky se musím pochválit – mám z toho dobrý dojem. A těším se na budoucnost.

Kdybychom si dokazovali, který návrh je nejlepší, možná bychom diskutovali dodnes. Také bychom mohli dávat body. Ani jeden z těchto postupů by nebyl User Centric Development – uživatelé by byli vynecháni.Nakonec jsme všechny varianty nakreslili a obešli jsme okolní pracovny a poptali jsme se na názor. Vybrali jsme ty kolegy, kteří se nejvíce blíží koncovým uživatelům, záměrně jsme tedy vynechali napříkad programátory. Nechali jsme je vybrat nejlepší řešení a okomentovat důvody. Dva návrhy byly přijmuty dobře, nakonec jsme udělali něco mezi nimi. Za hodinu jsme měli jasno.

Tuto techniku rád používám, když se nemůžu rozhodnout mezi několika variantami, když vím, že můj návrh stále není dobrý a zejména když chci někoho ryche přesvědčit, že jeho nápad není dobrý. Je to relativně objektivní.

Je samozřejmé, že toto není jediná technika, která se na danou finkcionalitu použije. Například uživatelské testování není dobré vynechat. Ale pro návrh je rychlý průzkum skvělý.