USER EXPERIENCE Materiál k přednášce na FIT VUT Brno 14.12.2010
1. Proč můj budík nezvoní? Jak digitální svět ovládli programátoři.
Jak si stojí: člověk vs. počítač počítač superrychlý bezchybný bez citu doslovný sekvenční předvídatelný nemá morálku hloupý člověk superpomalý chybuje často a vášnivě emočně labilní nepřesný náhodný nepředvídatelný eticky založený inteligentní
Proč řešit UX? průměrný počítač je příliš složitý pro průměrného uživatele. skuteční uživatelé se při vývoji ignorují vývoj fakticky řídí programátoři a softwaroví inženýři
Co je to příliš složitý? Kognitivní tření [Cooper Inmates] odpor, na který narazí lidský intelekt při konfrontaci s komplexním systémem nejistota, zmatení, frustrace uživatele KT složitost nebo komplexnost ovládání! Vysoké KT moderní mikrovlnná trouba bankomat navigační počítač Nízké KT housle psací stroj analogový budík
Jak se většina software vyvíjí Hlavní slovo: programátor / softwarový inženýr jako jediný rozumí implementaci programátor plní specifikace efektivně: úspora času a peněz bezchybně: vše funguje bezpečně a správně s nízkými nároky na HW: úspora výpočetních prostředků
Jak přemýšlí programátor Homo sapiens homo logicus [Cooper-Inmates] Homo sapiens vyžaduje jednoduchost hledá úspěch stará se o je pravděpodobné Homo logicus chce mít kontrolu hledá porozumění a moudrost stará se o je možné Programátor pohrdá obyčejným uživatelem
Kdy si to můžeme dovolit Když nemáme konkurenci Příklad: Novell Netware do roku 1990 Když vyvíjíme pro programátory IDE vývojářské pomůcky knihovny a engines serverové OS a systémy specificky zaměřené aplikace
Jak to řeší většina: A co s použitelností? Poznatky od beta-testerů Dopsání slov uživatelsky přívětivý do specifikací a do letáku Zvoláním, jak jsou uživatelé hloupí
Mýtus o uživateli Pyramida eufemismů [Cooper Inmates] Špičkoví experti = omlouvači Znalí uživatelé = flegmatici Nezkušení uživatelé = naříkači = elastický uživatel
Jak lidé používají produkty? Mají cíl a očekávají, že produkt jej naplní Produkt sekačka na trávu digitální budík textový editor titulkovací software Cíle sekání trávy s minimem námahy buzení v definovaný čas dokument: - vytvoření nového - úprava - čtení - tisk - recenze a oprava titulky: - vytvoření nových - úprava, přečasování existujících - překlad na jiný jazyk
Pyramida fungujícího produktu Každý produkt (i mimo SW) má tři strany: žádoucnost chtějí to lidé? [Keeley, Doblin Group]
Důsledek špatných produktů Chyby při práci následky chyb = spousta peněz Frustrace zákazník: musí zaplatit následky a zdržení výrobce: updaty, technická podpora, vzdělávání snížení produktivity snadnější přechod ke konkurenci Špatně použitelný software se špatně prodává (pokud nejste Microsoft).
Když chyby zabíjí Let 965 American Airlines: [Cooper-Inmates, wikipedia] B-757 narazil v Kolumbii do hory při přistání havárie po špatném nastavení navigačního počítače Pilot zadal waypoint ROMEO místo ROZO 159 mrtvých příčina: lidská chyba, ALE? proč má spoluvinu počítač: po stisknutí R nabízel jako první ROMEO místo ROZO ROMEO byl 139 mil daleko. nevyhodnotil zadaný waypoint jako špatný v jeho možnostech to v roce 1995 mohlo být.
Když to funguje TiVo nahrazuje videorekordér novou zkušeností
Když to funguje zappos.com přehlednost, obsahová čistota, srozumitelnost
2. Co software běžně dělá a dělat by neměl
1) Software zapomíná jsme nuceni nastavovat informaci znovu při opětovném spuštění programu při opětovném vykonání funkce (ještě horší!) typický zádrhel: souborový systém dialog si většinou pamatuje jen poslední adresář skutečné použití: lokace se mění dle kontextu typu akce nahrání, uložení formátu souboru.
2) Software se nepředře zájem programátora: co nejméně zatížit prostředky PC skutečná realita v roce 2010: PC nedělá většinu času nic místo toho by mohlo: indexovat, zapamatovávat si aktivně vyhledávat a napovídat vytvářet předpoklady budoucích situací, zahazovat průběžně ty špatné [Cooper-About Face]
3) Software neinformuje (správně) málokdy je uživatel přesně v obraze nejvíce prostoru = chybové stavy a hlášení proč software často neumí informovat o stavu, ve kterém se program nachází informovat o hloubce věcí počet, průběh informovat o možných / pravděpodobných cestách dál
4) Software se nepřizpůsobí SW existuje jen v jenom kontextu = ve kterém bylo vytvořeno SW nebere v potaz aktuální situaci uživatele jeho vytížení out-of-order příkazy výjimky z normálního běhu věcí přednostní zpracování čehokoliv na základě úsudku systémově: špatné, lidsky: ospravedlnitelné
5) Software obviňuje uživatele Chyby = často nepoužitelná chybová hlášení Nejčastější prohřešky: program nerozlišuje vinu program nedbá na to, zda uživatel hlášce rozumí program nenabízí řešení program se ukončí a zapomene vše
6) Software se zříká odpovědnosti potencionálně nebezpečné situace: dialog program by se neměl vyhýbat zodpovědnosti program by neměl zdržovat dialogem využití UNDO viz webové aplikace Google
Proč se tak software chová? návyk vývojářů vyžití špatně řešených UI prvků zastaralé / nevhodné knihovny programátorovi záleží více na programu, než na uživateli programátor chápe interakci po svém
3. Úvod do User Experience pojmy, zkratky a profese
Co to je UX? UX = User Experience = všechny aspekty uživatelské zkušenosti při interakci s produktem, službou, prostředím nebo zařízením UX bere v potaz funkčnost prezentaci výkon systému interaktivní chování nápomocné vlastnosti
UX není (jen) použitelnost Použitelnost (usability) snadnost použití a osvojitelnost principů lidmi vytvořeného produktu alternativy: user-friendly, easy-to-use profese: usability specialist UX expert aplikace vědeckých postupů výzkum, testování, analýza získávání dat a jejich syntéza na konkrétní kroky
Interakční design HCI human computer interaction skládá se z jednotlivých metod prvků UI UI user interface uživatelské rozhraní Interakční design ID zabývá se úkoly a procesy, na které uživatel narazí při manipulaci s produktem / programem / službou profese: interakční designér hledá návrh UI, který uspokojí uživatele a jejich záměry řešení, které nejlépe zapadá do možností / cílů produktu
Stupně vývoje UI [Cooper-About Face] Implementační rozhraní reflektuje, jak software funguje interně sada funkcí, oddělených do příbuzných oblastí Metaforická rozhraní vizuální podklady které vytváří metaforu s úkolem hranice: existují úkoly, které nelze vizuálně naznačit naznačení úkolů omezuje jejich vnímání Idiomatická rozhraní uživatel se je naučí používat a poznávat opakováním vytvoření nové myšlenkové asociace - idiomu
Příklady UI Metaforické Microsoft Bob
Příklady UI Implementační Apollo VUT Metaforicko idiomatické toolbar programu Paint.NET
Informační architektura Zabývá se informací a jejím předáváním uživateli srozumitelnost, jasný význam konzistence např. položky menu struktura navigace vyhledávání informace IA se prosazuje v: web, informační systémy profese: informační architekt stará se o správný přenos informace v jejím významu pomocí daného produktu k uživateli
UX jako standard? v tuto chvíli neexistuje jednotné názvosloví pro jednotlivé metody pro profese v oboru pro výsledky a jejich formát ISO 9241-210:2010 Ergonomics of human-system interaction jednotlivé profese většinou zajišťuje jeden člověk často věnující se jiné činnosti vývoj, grafický design
4. Správný model vývoje po všech bodech k úspěchu
Modely bez kontroly programátor vydání softwaru manažer programátor vydání softwaru
Zajištění kvality manažer programátor tester vydání softwaru
Vizuální podoba aplikace manažer programátor tester designér vydání softwaru
Znalost uživatele Stačí popis segmentu trhu? statistické údaje k příjmu a utrácení informace o zaměstnání, předpokládané záliby úspěšné vytvoření produktu = detailní znalost uživatele potřebujeme odpovědi na otázky proč? jak?
Jak zapojit uživatele přímo uživatel dostane rozhodovací roli výhoda: přenesení zodpovědnosti na uživatele nevýhoda: uživatel neovládá design ví, co ho pálí, ale nemá ponětí, jak to správně řešit nepřímo výzkum -> poznatky pro design pochopení cílů uživatele
Cooper: cílový design skutečný cíl uživatele je často odlišný od záměru tvůrců softwaru, např.: vypadat ve své práci kompetentně mít věci pod kontrolou cíle se liší od úkolů: vystavit fakturu, zrecenzovat příspěvek design pro cíle vs. design pro úkoly
Pouze cíle uživatele? úspěšné produkty plní v první řadě cíle uživatele, ALE nejdůležitější je plnění cíle podnikání úloha, kterou aplikace má po stránce vydělávání peněz každá aplikace je závislá na úspěchu mělo by nás v první řadě zajímat, jak tomu napomoci metody musíme podřídit cíli podnikání extrém: anti-ux někdy má místo
Proč design? design = kompletní definice produktu zahrnuje požadavky uživatelů popisuje vzhled a fungování vs. tradiční vnímání design je facelift implementace grafická podoba navržená pro již dokončený produkt
Design ale musí vytvořit podobu produktu na základě vstupů výzkum trhu, etnografická data, analýzy proto musí existovat proces: vstupní data výzkum trhu analýzy cílový design navržená podoba aplikace
Cílový design: proces 1: přemýšlení výzkum modelování požadavky 2: návrh rozhraní struktura detaily výsledky
Možný výsledek cílového designu textový výstup důležité pro pozdější reference obsahuje závěry, na základě kterých vznikl design obsahuje podněty pro další fáze layout, vývoj, provoz názorný výstup specifikace rozhraní wireframes, mockups detailnost závisí na složitosti rozhraní postery, prezentace vhodné pro sladění vývojového týmu lepší přesvědčení investorů
5. Uživatelský výzkum sbíráme data o lidech
Kvalitativní vs. kvantitativní kvantitativní data lehce k dispozici, vyjádřitelná čísly měření počtu operací, návštěvnosti, míry úspěchu odpověď na otázky kolik, kdy, kde kvalitativní data odpovědi na otázky proč a jak nepoměrně obtížněji dolovatelná do jisté míry lze dedukovat z kvantitativních
Interview - druhy můžeme se dotazovat: investorů obchodní záměr odborníci - SME subject matter experts odborníci přes danou oblast např. zdravotnictví uživatelů produktu lidí, kteří rozhodují o koupi nemusí být automaticky uživatelé mimo interview lze čerpat z existujících zdrojů recenze, audity, analýzy konkurence
Pohovor s odborníky jsou často expertní uživatelé je třeba znát jejich potřeby mohou preferovat složitější ovládání/interakci odborník není designér je třeba ho krotit při návrhu vlastních řešení otázka: jak to pomůže vám / uživateli? pohovor s nimi je nezbytný, pokud je aplikace komplexní / specializovaná!
Pohovor s uživateli vybíráme: současné, ale také budoucí uživatele dle předpokladů obchodního modelu dotazujeme se na: kontext, ve kterém bude produkt používán kdy, kde - prostředí, pracovní procesy, dostupný čas odborná znalost co musí znát k používání současný stav jaké úkoly musí řešit cíle a motivace co chtějí úkoly dosáhnout problémy, frustrace, jak přemýšlí o produktu
Kontextuální interview sledování dotazovaného v přirozeném kontextu, v jakém bude produkt používat prostředí, čas, doplňky interakce hloubkové dotazování otázka myslí si odpověď otázka odpověď
Designér a výzkum? designér má schopnost vcítit se do role ostatních empatie přizpůsobí lépe návrh skutečným potřebám uživatelů má data z první ruky důvěra lepší myšlenková asociace
6. Mentální modely persony proč a jak
Proč model uživatele? organizace vyzkoumaných poznatků lepší přenos kvalitativních znaků chování odpovědi na proč a jak jasná znalost cílů snazší pochopení kontextu
Bez modelu uživatele mýtus elastický uživatel ohne se, kam potřebuje investor / vývojář design vztažený na tvůrce soudí potřeby uživatelů podle sebe designér, vývojář diametrálně odlišní od uživatele! zaměření se na zbytečnosti např. přílišná koncentrace na mezní stavy, které jsou nepravděpodobné
Jaký by měl model být? Specifický, ne všeobecný zátěž: uspokojení více typů lidí = zvýšení KT pro všechny zůčastněné praktické hledisko: většina prvků se nedá navrhnout tak, aby uspokojily každého ale specifičnost má své meze! (vždy určuje obchodní model)
Persony a další modely persony = reprezentace individuálních osob jsou snadno popsatelné a reálně uchopitelné vyvolají empatii mezi tvůrci dají se zasadit do skutečných situací vzhledem k produktu další modely model pracovní činnosti graf model vstupu a výstupu model skutečných / fyzických objektů
Provizorní persony nejsou založeny na datech, ale expertních odhadech dají se aplikovat, pokud to situace vyžaduje lepší než žádný model, ale nejde o nejlepší možné UX!
Cíle person nejdůležitější charakteristika cíle motivují úkoly, které budou uživatelé provádět měly by být získány z kvalitativních dat tři druhy: zkušenostní pocit kontroly, pochopení, radosti koncové konkrétní dosažitelné výsledky životní dlouhodobé životní cíle
Ne-uživatelské cíle cíle zákazníka (pokud kupující není uživatel) např. cena / výkon krátkodobý a stranou dění ale důležitý cíl cíle investora zvýšení profitu, podílu na trhu, získání a udržení zákazníků získání zájmu veřejnosti (non-profit) technické cíle kompatibilita, konzistence dat, nízké požadavky na HW
Jak vytvořit persony Na základě zjištění z počátečního výzkumu Vyfiltrujeme typy lidí s různými cíli Sjednotíme do person tak, aby cíle nekolidovaly navzájem úkoly a překážky k dosažení cílů byly stejné Popis persony do hloubky, která je nutná vzhledem k produktu není reálná postava sepsání profilu na základě dat
Vytvoření persony I. zjištění proměnných charakteristik vycházíme z kontextu a vlastností, které produkt ovlivní má volný čas časové dispozice je vytížený(á) namapování osob z výzkumu na charakteristiky
Vytvoření persony II. identifikace vzorů chování shluky stejných vlastností na osách fyzické vytvoření persony: pojmenování, doprovodné informace využijeme získaná etnografická data pokud nás zajímají vztahy mezi více personami zmapovat a popsat jejich vzájemné propojení
Vytvoření persony III. kontrola: nezbývá již nic? žádné redundantní charakteristiky žádné další vzory chování, které jsou v rozporu s existujícími personami určení důležitosti: primární persona pro ni je návrh UI sekundární persony změna v návrhu, která nepoškodí PP zákaznické persony nakupující dotčené persony jsou ovlivněni ale nejsou uživatelé negativní persony pro ty specificky UI netvoříme
Co s personami prezentace a komunikace jejich podoba musí být jasná vývojářům investorům marketingu a PR propagace jsou-li fyzicky k dispozici (papírová karta) je snadné se na ně odkazovat
Scénáře před návrhem ideální scénář popis kroků k dosažení cíle z pohledu persony předpoklad ideálního rozhraní magie, co by kdyby proč? představa ideálního rozhraní dokáže pomoci při tvorbě jakéhokoliv rozhraní při tvorbě návrhu slouží k specifikování a pozdější validaci jednotlivých kroků
Pro další fázi: vznik požadavků zjistíme přesné nároky, které jsou kladené na produkt víme, čeho se vyvarovat a co dodržet dokážeme navrhnout konkrétní úkoly, které bude uživatel provádět ==> další fáze návrh rozhraní
7. Návrh rozhraní od požadavků k wireframes
Základní vlastnosti UI forma na čem se bude pracovat webová aplikace webová stránka desktopová aplikace pozice kolik pozornosti UI dostane suverénní, dočasná, daemonická vstupní metody konkrétní typ interakce klávesnice, myš, webový prohlížeč, dotykové rozhraní
Datové a funkční prvky datové prvky všechny data, která jsou nutná k provedení úkolů zprávy, záznamy, obrázky důležitý je kompletní souhrn závisí na tom funkčnost vycházíme především ze zadání a dostupných možností funkční prvky všechny funkce, které s daty aplikace provádí reprezentace těchto dat v rozhraní zde se uplatní: ideální scénáře, důkladné specifikace úkolů
Funguj jako člověk pomůcka: aplikace s nízkým KT se chová jako člověk ohleduplný, nápomocný, slušný užitečné otázky pro návrh funkcí: jak by to řešil nápomocný člověk? je s primární personou zacházeno lidsky? jak mohu zminimalizovat její námahu? jak mohu informovat, aniž bych se pletl do cesty? jak mohu usnadnit dosažení cílů persony?
Používejte vzory a principy odladěné, dobou testované koncepty v UI výhoda: idiomatická znalost u uživatele vyplácí se jít s dobou, inspirovat se úspěšnými zlatá pravidla: vymýšlejte nové principy, až když není zbytí vždy k nim vycházejte ze základních stavebních prvků existujících UI
Příklad principu: drag-n-drop kliknutí na objekt a přesunutí -> provedení změny požadována vizuální zpětná vazba: při přesunu zvýraznit možné body / plochu přijetí přesouvaný objekt musí být viditelně tažen indikace přesouvatelnosti, indikace správného přijetí další body k ošetření: auto-scrolling minimální vzdálenost pro započetí dragu přizpůsobení směru V/H dle aplikace (tabulky) přepnutí přesnosti myši, využití klávesnice, snap-in funkce
Logické skupiny a celky definice skupin a pozice prvků rozmístění a záběr místa dle důležitosti hierarchie: kontejnery směr postupu: které prvky v jakém pořadí shlukování: proč a kde každé UI vytváří v hlavě uživatele mentální model podrobná představa, jak věci fungují špatné UI představa je falešná, zvyšuje se KT
Je čas malovat prvotní návrhy skeče a mockups možno užít specializovaný software balsamiq pro většinu případů: papír + tlustý fix [Balsamiq Mockups, http://balsamiq.com/]
Funkční prototypy umožňují kromě náhledu i částečnou funkčnost vhodné pro účely prvních testování uživatelské testování prototypu předvedení zákazníkovi ověření funkčnosti pro designéra vytváří softwarové nástroje Axure příp. prototyp tvoří samo vývojové oddělení
Doladění detailů upřesnění rozhraní v celé jeho šíři výstup ve formě wireframes případně konečné vizuální rozhraní důležitý je nejen vzhled, ale také popis funkčnosti nástroje: Axure, ProtoShare, Omnigraffle (MAC)
Příklad wireframe
Příklady wireframe - výsledek
Příklady wireframe - výsledek
8. Testování použitelnosti ověření hypotéz a validace designu
Role testování uživatelů potvrzení závěrů z designu produktu role je ve validaci a ověření získání kvalitativních poznatků testovat se může jakmile jsou hotové alespoň prototypy / náčrtky speciální forma pro IA: card sorting když není na testování čas důkladný design má vždy větší prioritu!
Přínos testování poznání uživatele-začátečníka pokročilý / expert: časově náročné a složité rozeznání hlavních problémů UI na co se při návrhu zapomnělo vyladění drobných detailů rychlost scrollování míra informování změny v názvosloví prvků
Formy testování pevně zadaný scénář výsledek: splní / nesplní kvalitativní poznatky o průběhu nestrannost a užitečnost scénáře prověřena víckrát neformální sezení spontánní, bez přípravy rychlé, ale riziko vedení uživatele, kam potřebujeme potřebujeme technicky zdatné respondenty
Testování dle času sumativní testuje se na hotovém programu může zpracovat i třetí strana může být provedeno různě dlouho po vytvoření vyžaduje experta na zpracování závěrů zvláštní typ: webové stránky více viz *Steve Krug, Jakob Nielsen] formativní testuje se při vývoji v průběhu tvorby designu / programování
Formativní testování začíná se, jakmile je co testovat prototyp UI, aplikace, programu papírový prototyp vyžaduje respondenty s fantazií respondenti měli by vycházet z person u testování plní zadané úkoly a přemýšlí nahlas sezení si zaznamenáváme a moderujeme nestrannost, neznalost / znalost produktu dle potřeby musíme zajistit přirozené prostředí a vztah moderátor - respondent
Zapojení designéra při testování zapojení při sezení minimalizujeme! testování se může ovlivnit propašování manipulace ve prospěch designu zapojení designéra při testování: pomoc při vytváření scénářů zná cíle a úkoly schválení výběru respondentů zná persony sledování sezení vzdáleně / po dokončení společné vyhodnocení závěrů
Když vládne uživatel Testování ve stylu dokud se nechytne bez koncepce = vysoká ztrátovost lidem to vadí! pozůstalí uživatelé většinou promíječi Zpětná vazba od uživatelů pozor: uživatel nemá představu, co skutečně potřebuje Závěr: uživatel se respektuje, ale nesmí vývoj řídit!
Agile a UX Agilní vývoj založen na iteracích 1. získání počátečních podkladů 2. vývoj jedné fáze 3. testování a předání fáze klientovi 4. zanesení připomínek a zpět na bod 2. 5. odevzdání finálního produktu vs. UX úsilí při návrhu -> méně zkoušení vhodnost: záleží na projektu
Příklad: agilní vs UX Mojechaty.cz redesign rezervací
Příklad: agilní vs UX Mojechaty.cz první návrh (základní UX) rozdělení fází na rezervaci a objednávku zpřesnění stavu menší matení uživatelů výběr libovolného data z kalendáře výběr libovolného rozsahu ubytovaných dní
Příklad: agilní vs UX Mojechaty.cz další návrh (pomezí UX / Agile) není jasné, kdy se ubytovat / odubytovat nelze ubytovat ve stejný den, kdy se někdo odubytuje důsledek: zobrazení počtu nocí
Příklad: agilní vs UX Mojechaty.cz poslední oprava (Agile) fáze rezervace povolení více současných o výsledné rozhodnou administrátoři důsledek: nová barva předrezervace
Závěr výběr metody, hloubka výzkumu, detailnost návrhu: vždy závisí na okolnostech! vyvarujte se: tvorbě aplikací bez znalosti uživatelů přílišného vlivu ze strany uživatelů posuzování věcí podle citu programátora naučte se hovořit o aplikacích s lidmi, kteří je skutečně používají
9. Kde zjistím více knihy a weby, které nesmíte minout
Knižní zdroje Alan Cooper: The Inmates are running the asylum 1999 vysvětluje proč má UX smysl příklady z businessu rozdíly v mentalitě vývojářů a uživatelů nastínění nového procesu
Knižní zdroje Alan Cooper: About Face 3 2007 vysvětlení: UX výzkum, metody, persony cíli řízený design (goal-driven) UI základy a jednotlivé druhy komplexní přehled UI vzorů
Knižní zdroje Steve Krug: Don't Make Me Think [2005] jak web skutečně vnímají jeho uživatelé Steve Krug: Rocket Surgery Made Easy [2009] uživatelské testování pro web nízkonákladová, vysoce přínosná varianta
Webové zdroje Cooper blog o UX http://www.cooper.com/journal/ Jakob Nielsen Alertbox (použitelnost webu) http://www.useit.com/alertbox/ Usability counts blog / odkazník o UX http://www.usabilitycounts.com/
Kdo přednášel Ing. Marek Gach kontakt: gach@kurzor.net Ing. Jan Malý kontakt: maly@kurzor.net ve spolupráci se společností Kurzor, s.r.o. http://www.kurzor.net