Testování použitelnosti má nezaslouženou reputaci za to, že je drahé a pomalé. Když lidé slyší "uživatelský výzkum", představují si zrcadlo jednosměrné, moderátora se schránkou a dvoutýdenní časový plán. Tato verze testování existuje a má své použití — ale to není verze, kterou si aplikace týmy vyžadují nejčastěji.
Verze, kterou potřebují nejvíce týmy, je jednodušší: pět uživatelů, Figma prototyp nebo testovací prostředí, videohovor a 45 minut na jednu relaci. Pokud je to provedeno dobře, odhalí to většinu vážných problémů s použitelností před jejich odesláním. Pokud se to provádí konzistentně — i jednu relaci na sprint — vytváří to složit se zlepšování kvality produktu, které žádné množství analýz po spuštění nemůže replikovat.
Zde je návod, jak jej spustit od nuly.
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í, s klesajícími výnosy potom. Spuštění tří relací po pěti uživatelích v různých bodech procesu návrhu je cennější než jedna relace s patnácti.
Kritéria pro набor jsou důležitější než číslo. Test použitelnosti s pěti lidmi, kteří se blíže shodují s vaší cílovou persona, odhalí skutečné problémy. Test s patnácti lidmi, kteří se nehodují, bude generovat hluk. Definujte dvě nebo tři kritéria pro screenování — roli, kontext použití, technickou úroveň pohodlí — a držte se jich.
Nejrychlejší cesta наборu pro většinu týmů je poslat e-mail existujícím uživatelům, kteří dali kontaktní souhlas. Nabídněte skromnou motivaci — dárkový poukaz za 20 EUR je dostatečný na 45minutovou relaci. Cílem je plánovat relace v rámci téhož týdne; čím delší mezera mezi набором a testováním, tím vyšší je míra neúčasti.
Nejčastější chyba v psaní skriptů je psaní úloh jako pokynů: "Klikněte na Nastavení, poté přejděte na Oznámení a změňte svou volbu na..." To říká uživateli, co má dělat, což znamená, že testujete, zda mohou následovat pokyny, nikoli zda je rozhraní intuitivní.
Místo toho napište úkoly jako scénáře: "Představte si, že dostáváte příliš mnoho oznámení a chcete dostávat pouze upozornění, když vás někdo zmíní přímo. Ukažte mi, co byste udělali." To dává uživateli realistický cíl a umožňuje vám pozorovat, jak se skutečně orientují — včetně míst, kde jsou zmateni.
Nejtěžší část moderování testu použitelnosti je odolávat pocitu pomoci. Když je uživatel zmatený, každý instinkt říká skočit a ukázat mu, kam kliknout. Ale zmatek je data. Uživatel, který si je vědom, vám říká, že je něco špatného s rozhraním — a v okamžiku, kdy zasáhnete, ztratíte signál.
Požádejte uživatele, aby během relace hlasitě mysleli: "Jak budete postupovat, jen mi řekněte, na co se díváte a co si myslíte." To vytváří nepřetržitý stream dat o jejich mentálním modelu. Zaznamenejte nejen chyby, ale váhání — uživatel, který se pozastaví na tři sekundy, než klikne na správné tlačítko, stále odhalil problém s návrhem, i když nakonec uspěl.
Krok syntézy je tam, kde se vytváří většina hodnoty — a kde si většina týmů zkrátí rohy. Surové poznámky z pěti relací nejsou nálezy. Stávají se nálezy, když si debriefujete jako tým, seskupujete pozorování podle tématu a přiřazujete hodnocení závažnosti.
Proveďte debriefing ve stejný den jako relace, zatímco jsou pozorování čerstvá. Seskupujte problémy do tří skupin: kritická (uživatelé nemohli dokončit úkol), střední (uživatelé dokončili úkol, ale s významnou obtížností či chybou), menší (tření, které neubrání dokončení). Kritické problémy je třeba opravit před spuštěním. Střední problémy by měly být upřednostněny v příštím sprintu. Menší problémy jdou do backlogu.
Napište nálezy na jedné straně: tři hlavní kritické problémy s důkazem od nejméně dvou účastníků, každý s navrhovanou změnou návrhu. Cokoli, co potřebuje více místa než to, patří do samostatného dokumentu.