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] 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é“
• 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
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] Špičkoví experti
Znalí uživatelé
= omlouvači
= flegmatici
= naříkači
Nezkušení uživatelé
= elastický uživatel
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
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. 2. 3. 4. 5.
získání počátečních podkladů vývoj jedné fáze testování a předání fáze klientovi zanesení připomínek a zpět na bod 2. 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:
[email protected]
• Ing. Jan Malý – kontakt:
[email protected]
• ve spolupráci se společností Kurzor, s.r.o. – http://www.kurzor.net
