Zavedení použitelnosti do firmy : Použitelnost dot kom

Jak se měří použitelnost

Jednoduchá otázka. Často jedna z prvních. A odpověď? „Těžko říct.“

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ů.

Konzistence uživatelského rozhraní

Uživatelské rozhraní musí být konzistentní. Pokud není, zhoršuje se učící křivka, snižuje se spokojenost uživatelů a celkově je aplikace větší či menší chaos se všemi důsledky z toho vyplývajícími.

Když se začnu zabývat použitelností některé existující aplikace, většinou je jeden z prvních námětů na zlepšení to, že by se mělo sjednotit ovládání tak, aby v každém okně nebylo trochu jiné. Navrhnu nějaká doporučení a vytvořím mustr na nejkřiklavější případy. Rozdíly nechám odstranit. Většinou je první reakce autorů softwaru, zejména vývojářů, odmítavá – nevidí to jako velký problém, mají pro odlišnosti nejrůznější důvody nebo jsou líní něco měnit. …Pokračování článku…

Tvorba person

Máme-li hotovy role, můžeme se vrhnout na vytvoření person. Tvorba person je zajímavější a rychlejší než v případě rolí, ale samotná práce s personami je dlouhodobá. Hodně trnitá, ale většinou i zábavná a uspokojující.

Kolik person?

Postupně vezmeme všechny role a pro každou najdeme jednu nebo víc person. Persona se od role liší tím, že jde o reálného (přestože virtuálního) člověka. Někdy se v jedné personě spojí více rolí, třeba když uživatel pracuje v malé firmě a má toho na starosti víc nebo třeba když některá role nevydá na celou pracovní dobu uživatele. Persona také typicky pracuje s více produkty, s našimi i s cizími. Když se rozhodujeme, jaké persony tvořit, zkusme se zamyslet, jestli již nějakou vhodnou nemáme. …Pokračování článku…

Role

Typů rolí existuje celá řada. V tomto článku se píše o rolích ve smyslu UCD – User Centric Development.

Většinou, když necháte programátora tvořit, do velké míry předpokládá, že uživatelé jsou jako on. A že se zajímají o jeho software a že mu věnují veškerou pozornost… Samozřejmě, že se tento jev netýká jen programátorů, ale všech lidí, kteří se podílejí na vývoji.

Bylo by dobré, kdyby se všichni mohli setkávat s uživateli, pozorovat je při práci a konzultovat s nimi své nápady. Protože to ale často není možné, simulujeme toto setkání pomocí rolí a person.

Nejdříve vytvoříme role. Administrátor, sekretářka, účetní… všichni, co mohou využívat daný software, a to přímo i nepřímo. Například ředitel asi nebude s vaším softwarem pracovat, ale bude po sekretářce chtít, ať tam zadá nějaká data a pak bude číst výstupy. …Pokračování článku…

Jak psát chybové hlášky

Motivace

Pokud chcete zlepšit použitelnost aplikace a nemáte dosud zaveden proces kontroly jejich textů, udělejte následující trik: nechte si vypsat všechny texty aplikace do jednoho souboru. Pod sebe. Pak se začtěte.

Pravděpodobně zjistíte, že jak to tam jednotliví programátoři flákli, tak to tam je. Kvalita a smysluplnost bývá nevalná a míchají se různé styly a úrovně podle toho, jak na tom zrovna autoři zrovna byli.

A teď si představte, že takové chybové hlášky vidí chudák uživatel v okamžiku, kdy má problém. …Pokračování článku…