Testování použitelnosti bez laboratoře: průvodce pro začátečníky

Týmem FabricLoop  ·  Květen 2026  ·  4 min čtení

Testování použitelnosti má nezaslouženou pověst drahého a pomalého. Když lidé slyší „uživatelský výzkum“, představí si jednosměrné zrcadlo, moderátora s podložkou na papíry a dvoutýdenní harmonogram. Taková verze testování existuje a má své využití — ale není to verze, kterou produktové týmy potřebují většinu času.

Verze, kterou většina týmů potřebuje, je jednodušší: pět uživatelů, prototyp ve Figmě nebo testovací prostředí, videohovor a 45 minut na jednu relaci. Při dobrém provedení odhalí většinu vážných problémů s použitelností ještě před vydáním. Při pravidelném provádění — třeba jednou za sprint — přináší kumulativní zlepšování kvality produktu, které žádná analytika po spuštění nenahradí.

Tady je návod, jak na to od nuly.

Čtyřkrokový průběh testovací relace

Krok 1: Nábor — záleží víc na tom, koho testujete, než na tom, kolik jich je

Pět účastníků je správný počet pro většinu testů použitelnosti. Výzkum Jakoba Nielsena prokázal, že pět uživatelů odhalí přibližně 85 % problémů s použitelností a další účastníci už přinášejí klesající přínos. Tři sezení po pěti uživatelích v různých fázích návrhu jsou cennější než jedno sezení s patnácti.

Kritéria náboru jsou důležitější než počet. Test použitelnosti s pěti lidmi, kteří se co nejvíc podobají vašemu cílovému uživateli, odhalí skutečné problémy. Test s patnácti lidmi, kteří mu neodpovídají, vyprodukuje jen šum. Stanovte dvě nebo tři screeningová kritéria — roli, kontext používání, úroveň technické zdatnosti — a držte se jich.

Nejrychlejší cesta k náboru je pro většinu týmů e-mail stávajícím uživatelům, kteří dali souhlas s kontaktováním. Nabídněte skromnou odměnu — dárkový poukaz v hodnotě £20 stačí na 45minutovou relaci. Snažte se naplánovat relace v rámci téhož týdne; čím delší je mezera mezi náborem a testováním, tím vyšší je podíl těch, kteří se nedostaví.

Krok 2: Scénář — situace, ne pokyny

Nejčastější chybou při psaní scénáře je formulovat úlohy jako pokyny: „Klikněte na Nastavení, pak přejděte na Oznámení a změňte svou volbu na...“ Tím uživateli říkáte, co má dělat, takže testujete, zda umí následovat pokyny, a ne zda je rozhraní intuitivní.

Úlohy místo toho napište jako situace: „Představte si, že dostáváte příliš mnoho oznámení a chcete upozornění jen tehdy, když se vás někdo zmíní přímo. Ukažte mi, co byste udělal(a).“ Uživatel tak dostane realistický cíl a vy můžete sledovat, jak se v rozhraní opravdu pohybuje — včetně míst, kde se zmate.

Krok 3: Vedení testu — vaším úkolem je sledovat, ne pomáhat

Nejtěžší na moderování testu použitelnosti je odolat nutkání pomoci. Když je uživatel zmatený, každý instinkt velí skočit mu do toho a ukázat, kam kliknout. Jenže právě ten zmatek jsou data. Uživatel, který se trápí, vám říká, že s rozhraním není něco v pořádku — a ve chvíli, kdy zasáhnete, o signál přijdete.

Požádejte uživatele, aby během celé relace přemýšleli nahlas: „Jak budete postupovat, říkejte mi, na co se díváte a co si myslíte.“ Vzniká tak nepřetržitý proud dat o jejich mentálním modelu. Všímejte si nejen chyb, ale i váhání — uživatel, který se na tři sekundy zastaví, než klikne na správné tlačítko, přesto odhalil problém v návrhu, i když nakonec uspěl.

Krok 4: Syntéza — vzory, ne citace

Krok syntézy je místo, kde vzniká většina hodnoty — a kde většina týmů šidí. Hrubé poznámky z pěti relací nejsou zjištění. Stanou se jimi, když uděláte jako tým debriefing, seskupíte pozorování podle témat a přiřadíte hodnocení závažnosti.

Debriefing udělejte týž den jako relace, dokud jsou pozorování čerstvá. Problémy rozdělte do tří skupin: kritické (uživatelé nedokázali úlohu dokončit), střední (uživatelé úlohu dokončili, ale s výraznými obtížemi nebo chybou) a drobné (tření, které nezabránilo dokončení). Kritické problémy je třeba opravit před spuštěním. Střední problémy by měly mít prioritu v příštím sprintu. Drobné problémy jdou do backlogu.

Zjištění sepište na jednu stranu: tři nejzávažnější kritické problémy, u každého doklady od alespoň dvou účastníků a navrhovanou změnu návrhu. Cokoli, co potřebuje víc místa, patří do samostatného dokumentu.