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

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.Na sjednocení ovládání je třeba trvat a je třeba ho provést. Ale současně je nutné nepostupovat striktně mechanicky.

Může se stát, že dobře odůvodněná výjimka pomůže zlepšit použitelnost. Někde se “nečekaně” použije mnohem větší tlačítko, jinde se zdůrazní nebo naopak potlačí některý prvek – a může to být ku prospěchu věci. Pro každou výjimku by ale měl být nějaký rozumně vyargumentovaný důvod (nejlépe podložený uživatelským testováním). Neboli cílem je mít vše jednotné a v odůvodněných případech být připraveni povolit výjimku.

K napsání tohoto článku mě poňoukla diskuze  na IxDA. Přečtěte si ji. Také se můžete do této organizace přihlásit, členství je zdarma.

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.K jedné roli také můžeme vytvořit více person. To se stane typicky v tom případě, když existuje několik různorodých typů uživatelů nebo použití. Třeba u nás to je vidět na roli vedoucího pobočky. Náš software, kde se něco objednává, se bude jinak používat, když půjde o vedoucího pobočky banky (velký aparát, striktní procesy), majitele prodejny automobilů (malá firmička, nezávislý prodejce) nebo hamburgerového fastfoodu (frenčíza). V těchto třech případech jsou různé motivace lidí, jinak k tomu přistupují, jinak platí… Proto jsme udělali persony tři.

Obecně bychom se měli snažit mít person co nejméně. Rozhodně musíme pokrýt všechny role.

Definice persony

U každé role se zamyslíme, jak asi vypadá typický uživatel a načrtneme ho. Většinou začínám u národnosti jména, věku, vzdělání a pohlaví. Najděte si svou cestu, takto to dělám já.

Národnost není důležitá. Pracuji ale v nadnárodní společnosti, proto by neměly být persony z jednoho místa (třeba jen Němci nebo Amíci nebo Japonci). Pokud se liší národnost, mohou se pak také výrazněji lišit fotografie a jména person. Národnost většinou u persony neuvádím, ale sám si ji pamatuji a pomáhá mi si je zapamatovat.

Jméno

Řekněme, že vyberu Maďara. Jméno a příjmení nacházím jednoduše: zadám do vyhledávače “Hungarian names” a odkazy převážně vedou na seznam jmen s překladem nebo s etymologií. Ze seznamu prostě vyberu jméno, které se mi líbí a které není podobné s již hotovými personami. Podobně vyhledám a zpracuji příjmení přes ”Hungarian surnames”.

Vzdělání

Poté si ujasním (podle role), předpokládaný věk a vzdělání. Většinou je tam možný velký rozsah věku, to nevadí. U vzdělání se většinou volí základka/střední/vysoká a typ školy, zda humanitní, technická, ekonomická nebo třeba umělecká. Vzdělání je možné navrhnout podle toho, co je nejtypičtější v nabídkách práce.

Fotografie

Mám-li toto vše ujasněné, najdu fotku. Nejlepší by bylo najmout modela/modelku, nechat ho profesionálně nafotit a v případě potřeby ještě dofotit další fotky. To by stálo hodně peněz, ale hlavně času. Také by se daly fotky koupit ve fotobance. Ani to není ideální, fotky jsou zde silně stylizované, ale nakonec se dá vybrat. A nápad fotit kamarády a kolegy je také nepraktický, takové lidi zná kde kdo ve firmě a asi by je rušilo, kdyby si měli za tváří představovat někoho jiného. Proto první fotky…ehm…tak nějak…z internetu.

Do gůgla zadám název pozice nebo něco, co by mi mohlo najít vhodnou personu. A přepnu se do zobrazení extra velkých obrázků. To je důležité, protože se fotky budou nakonec i tisknout a i jinak se s nimi bude pracovat. Nalezené fotky procházím a vybírám kandidáty. Z kandidátů vyberu nejlepšího a ten stáhnu. Fotku upravím, aby neměla ulítlé barvy a hlavně ji ořežu na definované rozměry (abych umožnil dávkové zpracování).

Ale v tomto případě pozor na to, že když si stáhnete fotky lidí ze sítě a persony se u vás uchytí, tak je budete asi ukazovat kde komu a hrozí malé riziko, že se stane malér. Měnit zažitým personám fotky taky není dobrý nápad. Nejlepší možnost je přece jen fotobanka.

Pracovní prostředí

Podle fotky upřesním podrobnosti o personě. Mám tedy jméno, věk, vzdělání, a pohlaví. Připíšu detaily o zaměstnání (máme firemní klientelu), jako je délka praxe, práce na směny, velikost pracoviště, počet kolegů na stejné pozici, pracovní náplň, zda ho práce baví, jestli uvažuje o odchodu, jak moc práci rozumí, co ho motivuje nebo demotivuje… Jde o to popsat personu v prostředí, kde náš software používá.

Osobní život

Formálně vzato by bylo zbytečné popisovat osobní život persony. Ale uživatelé person nejsou stroje a aby mohli navázat s personou vztah, měli by mít představu i o tom, co dělá ve svém volném čase. Proto uvádíme, zda má persona ženu/muže, přítelkyni/přítele, děti, psy… A také její koníčky. Pomůže to personu prokreslit.

Příznaky

Z praktických důvodů u každé persony vyjmenujeme všechny role, které zastává a produkty, které používá. Později se nám to bude dobře kategorizovat.

XML

Asi jsem to dosud nezmiňoval, dělám to tedy až nyní. Z počátku jsem popisoval role a persony v textovém editoru. Narazil jsem ale na to, že persony je třeba prezentovat v různých formátech a podobách (uvidíme později). Přešel jsem proto do XML a výstupy generujeme podle momentální potřeby. Nyní například generujeme web a PDF, chystám se na další věci. Z počátku to udělejte tak, abyste to měli co nejrychleji, až budete mít několik desítek person, převeďte to.

Nasazení

Nasazení a aktivní život person popíši jindy, je to na dýl.

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.Role by měly být definovány tak, jako byste psali popis pracovní pozice do inzerátu. Předpokládané vzdělání, zkušenosti, pracovní náplň, popis pracoviště, s kým komunikuje… První role bude těžší vytvořit, asi se vám bude zdát, že je to v každém případu nasazení trochu jiné. Doporučuji vzít konkrétního jednoho zákazníka/uživatele a zamyslet se, jak se liší od ostatních a s drobnými korekturami popsat jeho případ. Pokud se někteří zákazníci nebo uživatelé výrazně liší od jiných, je dobré vytvořit role dvě nebo víc. My třeba máme dvě sady rolí pro jeden produkt: malá fabrika o patnácti lidech a kolos se stovkami zaměstnanců. V malé fabričce dělají zaměstnanci hodně různorodé činnosti, ve velké jsou úzce specializovaní.

Platí, že byste se neměli moc vázat na současné uživatele, důležití jsou uživatelé cíloví. Pokud je některý uživatel jiný, než byste si představovali, nezabývejte se jím. Vlastně rolemi a personami říkáme: takovýmto rolím je určen náš software. Je na obchodnících, aby takovéto lidi sehnali.

V rámci práce na rolích je vhodné také popsat jejich zaměstnavatele nebo pracoviště. Značková prodejna Seatu v Hradci Králové, vede to majitel, pracují tam čtyři obchodníci, je tam servis… Vymyslete si to, ale buďte konkrétní. Role se pak vytvoří přímo pro danou společnost. Pokud máte soukromou klientelu, postupujte obdobně. Jde o to mít nějaké informace o tom, co jednotlivé role spojuje. Pokud produkt používá více společností a komunikují spolu, vytvořte jich víc.

Je velmi důležité role podložit daty. Vše, co se týká použitelnosti, musí být velmi dobře podložené. Jakmile se při nasazování rolí a person ukáže, že neodpovídají realitě, můžete to zabalit. Důvěryhodnost je to nejdůležitější, co budou lidé, kterým to budete představovat, zkoumat. Nepodceňte to.

Jakmile role vytvoříte, ověřte, že jsou v pořádku. Konzultujte to s každým, s kým budete moci. S obchodníky, s analytiky, s kolegy… Každý to trochu upřesní. Asi si někdo vzpomene na další role, které chybí. Ty vytvořte. Konzultace také mají dobrý efekt v tom, že takto nenásilně představíte, že se bude něco nového dít. A kolegy do toho vtáhnete. V této fázi vám nikdo pomoc neodmítne, později to bude něco jiného (to už bude dlouhodobá práce a nějaké změny navíc). Nyní se lidé rádi vytáhnou.

UCD je možno aplikovat i na nový software. Když ještě uživatele nemáte, postupujte stejně, jen budete muset trochu víc zapojit představivost. A o to víc to musíte ověřit. Jestli ověření podceníte, uděláte produkt pro nikoho a navíc tak pošramotíte pověst UCD, že to asi vedení stopne.

Výsledkem bude několik rolí (2-12?). Až jste si jisti, že jsou hotovy a kvalitní, vytvořte ke každé z nich nejméně jednu personu. Většinou jednu, ale někdy se stane, že je lepší jich udělat víc. Například já jsem pro roli školitele udělal role nováčka a zkušeného borce. Každý má jiné problémy a řeší je jinak. Nebo jsem měl roli vedoucího pobočky a tři role podle oboru. Prodejce párků se hodně liší od bankéře.

O personách zase jindy. Více v knize The Persona Lifecycle.

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.Jak na to

Řešení je velmi jednoduché, stačí se držet několika jednoduchých pravidel. Ale musíte se jich držet vždy a dobře.

1. Mluvte k uživateli, ne ke kolegovi z pracovny. Jestli je vaším uživatelem děcko, hláška má být pro dítě. Když opilý námořník v baru, hláška bude jiná, než pro profesora matematiky při prezentaci na konferenci. Musíte se zamyslet, jak tomu dítěti nebo profesorovi vzniklou situaci nejlépe popsat a vyřešit.
2. Oznamte, co, kde a proč se stalo.
3. Pokud to je možné a vhodné, poraďte s řešením.

To je celé, toto fakt stačí k tomu, aby hlášky byly božské. Ale musíte se to naučit a dodržovat.

Uvedu několik příkladů, čísla budou znamenat, který bod byl porušen:

• Problém: Soubor nenalezen (File not found)
  Řešení: Soubor statistik “Daily report.xml” nebyl vytvořen, není zapnuta volba “Generovat denní statistiky” v předvolbách aplikace.
  Porušení: 1. Uživatel nehledal soubor, chtěl se podívat na statistiku. 2. Není uvedeno jméno souboru ani co to má za následky. 3. Řešení se nemusí nabízet vždy, ale tady by asi bylo vhodné.
• Problém: Chyba: Parametr “Running” je ve stavu “true”
  Řešení: Procesoru “Clever” nelze měnit nastavení, neboť je aktivní.
• Problém: Nečekaná chyba: Out of memory. (/Src/Graphics/Triangle.cpp:454)
  Řešení: Program nemá k dispozici dostatek paměti. Zkuste ukončit programy, které právě nepoužíváte. Pokud se tyto problémy vyskytují častěji, mohlo by pomoci rozšíření paměti.
• Problém: Spojení bylo přerušeno (Connection failed)
  Řešení: Spojení se serverem bylo přerušeno. Kontaktujte správce na klapce: 666

Vlastně existuje ještě jedno pravilo, týkající se varovných a chybových hlášek: Žádná hláška – super hláška. Moje finální rada je následující: zbavte se (skoro) všech hlášek, stejně se používají, jen aby prudily. Zkuste si v duchu porovnat, kolik varování máte doma. Máte na skříňce napsáno, že dvířka mohou upadnout, když se na ně pověsíte? Potřebujete cedulku, že vám došla vejce nebo to poznáte sami? Vyžadujete při vysypávání koše varování, že pokud ty věci vhodíte do kontejneru, přijdete o ně? Jak často vás zajímá, že v kapse máte tři předměty…

Je to jen lenost programátorů (je lepší díru zakrýt, než ji obklopit deseti cedulemi Pozor díra ve všech jazycích) nebo falešná korektnost (opravdu si přejete soubor přejmenovat?), která vede k takovému velkému počtu hlášek v aplikacích. Redukujte, redukujte, ještě jednou redukujte.