USER EXPERIENCE. Materiál k přednášce na FIT VUT Brno

Transkript

1 USER EXPERIENCE Materiál k přednášce na FIT VUT Brno

2 1. Proč můj budík nezvoní? Jak digitální svět ovládli programátoři.

3 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í

4 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

5 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

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

7 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

8 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

9 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í

10 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

11 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

12 Pyramida fungujícího produktu Každý produkt (i mimo SW) má tři strany: žádoucnost chtějí to lidé? [Keeley, Doblin Group]

13 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).

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

15 Když to funguje TiVo nahrazuje videorekordér novou zkušeností

16

17 Když to funguje zappos.com přehlednost, obsahová čistota, srozumitelnost

18

19 2. Co software běžně dělá a dělat by neměl

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

21

22 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]

23 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

24 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é

25 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

26 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

27 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

28 3. Úvod do User Experience pojmy, zkratky a profese

29 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

30 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

31 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

32 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

33 Příklady UI Metaforické Microsoft Bob

34 Příklady UI Implementační Apollo VUT Metaforicko idiomatické toolbar programu Paint.NET

35 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

36 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 :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

37 4. Správný model vývoje po všech bodech k úspěchu

38 Modely bez kontroly programátor vydání softwaru manažer programátor vydání softwaru

39 Zajištění kvality manažer programátor tester vydání softwaru

40 Vizuální podoba aplikace manažer programátor tester designér vydání softwaru

41 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?

42 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

43 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

44 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

45 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

46 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

47 Cílový design: proces 1: přemýšlení výzkum modelování požadavky 2: návrh rozhraní struktura detaily výsledky

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

49 5. Uživatelský výzkum sbíráme data o lidech

50 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

51 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

52 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á!

53 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

54 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ěď

55 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

56 6. Mentální modely persony proč a jak

57 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

58 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é

59 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)

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

61 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!

62 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

63 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

64 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

65 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

66 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í

67 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

68

69 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

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

71 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í

72 7. Návrh rozhraní od požadavků k wireframes

73 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í

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

75 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?

76 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

77 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

78 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

79 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,

80 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í

81 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)

82 Příklad wireframe

83 Příklady wireframe - výsledek

84 Příklady wireframe - výsledek

85 8. Testování použitelnosti ověření hypotéz a validace designu

86 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!

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

88 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

89 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í

90 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

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

92 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!

93 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 odevzdání finálního produktu vs. UX úsilí při návrhu -> méně zkoušení vhodnost: záleží na projektu

94 Příklad: agilní vs UX Mojechaty.cz redesign rezervací

95 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í

96

97 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í

98 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

99

100 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í

101 9. Kde zjistím více knihy a weby, které nesmíte minout

102 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

103 Knižní zdroje Alan Cooper: About Face vysvětlení: UX výzkum, metody, persony cíli řízený design (goal-driven) UI základy a jednotlivé druhy komplexní přehled UI vzorů

104 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

105 Webové zdroje Cooper blog o UX Jakob Nielsen Alertbox (použitelnost webu) Usability counts blog / odkazník o UX

106 Kdo přednášel Ing. Marek Gach kontakt: Ing. Jan Malý kontakt: ve spolupráci se společností Kurzor, s.r.o.