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č člověk

superrychlý superpomalý

bezchybný chybuje často a vášnivě

bez citu emočně labilní

doslovný nepřesný

sekvenční náhodný

předvídatelný nepředvídatelný

nemá morálku eticky založený

hloupý 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 Nízké KT

moderní mikrovlnná trouba housle

bankomat psací stroj

navigační počítač 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]

• Programátor pohrdá obyčejným uživatelem

Homo sapiens Homo logicus

vyžaduje jednoduchost chce mít kontrolu

hledá úspěch hledá porozumění a moudrost

stará se o „je pravděpodobné“ stará se o „je možné“

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

A co s použitelností?

Jak to řeší většina:

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

= elastický uživatel

Špičkoví experti

Znalí uživatelé

Nezkušení uživatelé

= omlouvači

= flegmatici

= naříkači

Jak lidé používají produkty?

• Mají cíl – a očekávají, že produkt jej naplní

Produkt Cíle

sekačka na trávu sekání trávy s minimem námahy

digitální budík buzení v definovaný čas

textový editor dokument: - vytvoření nového - úprava - čtení - tisk - recenze a oprava

titulkovací software 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 • zákazník: musí zaplatit následky a zdržení

• výrobce: updaty, technická podpora, vzdělávání

• Frustrace

– 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

programátor vydání

softwaru manažer

Zajištění kvality

programátor manažer

tester vydání

softwaru

Vizuální podoba aplikace

programátor manažer

tester

vydání softwaru

designér

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

navržená podoba aplikace cílový

design

Cílový design: proces

výzkum modelování požadavky

struktura detaily výsledky ………

………

1: přemýšlení

2: návrh rozhraní

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í

• namapování osob z výzkumu na charakteristiky

časové dispozice

má volný čas je vytížený(á)

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

• 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

vyplácí se jít s dobou, inspirovat se úspěšnými

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