1. Co se stalo? - kurzor.net · –alternativy: user-friendly, easy-to-use •profese: usability...
Transcript of 1. Co se stalo? - kurzor.net · –alternativy: user-friendly, easy-to-use •profese: usability...
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.
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
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
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
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ů
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
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í
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)
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 – 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í
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