Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

A szoftver-ergonómia módszerei

20131016:1800 - BME
by

Péter B. Polgár

on 25 November 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of A szoftver-ergonómia módszerei

A szoftver-ergonómia módszerei
Szoftver ergonómia - Az ember (=felhasználó) hogyan tud egy adott szoftvert használni
Interakciók
Jelezzük, ha várunk valamit a felhasználótól!
Billentyűlenyomást hanggal igazoljunk vissza!
Mindig jelezzük vissza az adatmódosítás eredményét!
Jelezzük, ha egy parancs el lett fogadva vagy végre lett hajtva!
Adjunk időben hibajelzést, de az akciót szükségtelenül ne szakítsuk meg!
Amennyire csak lehetséges, induljunk ki a felhasználó nyelvezetéből és a számítógéppel végzett műveleteiből.
Kompromisszumok a számítógépes rendszer eredményessége és a felhasználó ráfordításai között.
Legáltalánosabb elvek:
tartsuk szem előtt a felhasználók tevékenységét,
ismerjük a felhasználókat,
lehetőség szerint vonjuk be a felhasználókat (vagy azok képviselőit) a fejlesztési folyamatba.
Biztosítsuk a párbeszéd alakulásának visszaidéző áttekintését!
Biztosítsunk rálátást a soron következő párbeszéd-lépésekre!
Tegyük a párbeszédet (részben) reverzibilissé!
Minden parancs legyen reverzibilis!
Biztosítsunk egyszerű eszközöket a már bevitt adatok javítására még a parancs végrehajtása után is!
A gyakorlottabb felhasználóknak biztosítsuk az arra alkalmas műveletek rövidre zárását!
Adjunk "escape" opciót minden állapotra!
Adjunk áttekintést a feladat-helyzetről!
Biztosítsuk az egyéni "akció-program" kifejlesztését!
Legyünk tudatában a kijelzett kérdések közötti kapcsolatoknak!
A lehetőség szerint adjuk meg a feltett kérdések lehetséges válaszait!
Tegyük lehetővé a sűrített "input"-ot!
Legyen lehetséges funkciók definiálása!
Ne kérjünk redundáns adatot!
Segítsük a hibák felfedezését!
Figyelmeztessük a felhasználót arra, hogyan teheti hatékonnyá a gyakran ismétlődő műveletek elvégzését!
Adjunk képernyő-üzeneteket az egyszerre lehetséges különböző tevékenységekről!
Támogassuk a különböző tevékenységek közötti gyors váltást!
Időnként emlékeztessünk a még le nem zárt tevékenységekre!
Figyeljük a felhasználó válaszidejeinek és hibázásainak alakulását!
Ha arra szükség van, adjunk javaslatot az interakció megszakításának vagy egyes műveletek elhalasztásának módjára!
Adjunk szórakoztató üzeneteket vagy többletfeladatokat, ha szükséges!
Ne használjunk rövidítéseket vagy kódokat a hiba-üzenetekben!
Ne adjunk egyszerre túlságosan sok információt!
Egységes és konzisztens legyen a képernyő elrendezése!
A rendszer-üzeneteket mindig ugyanazon a helyen adjuk!
Ne használjunk hétnél több menüpontot egy menüben!
Ne használjunk hét karakternél hosszabb kulcsszavakat!
Helyezzük a kurzort mindig oda, ahova az adatot kell bevinni!
Design space analysis
Az előbbi megnyilvánulások nem rendezettek, nem volt koherens logikai váz: időben csapongó és vissza-visszatérő jellegű volt
Az alkotó (kreatív) folyamat ilyen:
látszólag rendezetlen
vargabetűkkel tarkított megközelítésmód
Az alkotó folyamat megzavarása nélkül egy laza és rugalmas gondolati struktúrát (az előbbiek alapján QOC reprezentációt) biztosítunk a tervezők számára, akkor ez segít(het)i kreatív képességeik megnyilvánulását és kibontakozását
Alapja: sikeres tervezők spontán tevékenységének vizsgálata
Empirikus kutatásokban tapasztalt és sikeres tervezők megfigyelt spontán kommunikációját és tevékenységét elemezték
A tervezők teljesen természetes módon dolgoztak, de a konkrét feladatot a kutatóktól kapták és tevékenységüket videóra rögzítették (nem in the wild helyzet, de legalább in the zoo)
Valamennyi verbális megnyilvánulásukat átírták szöveges formába (ún. verbal protocol módszer) és kategóriákba sorolták azokat
A DSA módszer alapja egy terv magyarázat (Design Rationale, DR) létrehozása
Design Rationale (DR)
A hagyományos tervdokumentációban benne vannak a döntések (eredményei), de hogy jutottak ehhez el ehhez a döntéshez?
A konstrukciós és implementációs tervek indoklás nélkül közlik ezeket a döntéseket és az rejtve marad, hogy ezek a döntések miért lettek éppen ilyenek
A terméktervezés nagy mértékben interperszonális, szociális folyamat, amit a résztvevők széles körének meg kell érteni és követni kell tudni
A módszer filozófiája
A DR:
a gondolati út dokumentálása
a tervezői döntések indoklása
a lehetséges alternatív megoldások előnyeinek és hátrányainak az összevetése
eredményesen használható a termék dokumentálásában és menedzselésében
jól áttekinthető, segíti a feladatok átgondolását, megértését
összhangban van a tervezők spontán tevékenységével, munkastílusával
A tervezési folyamatnak sajátos pszichológiai jellemzői vannak
Az alkotó mozzanatok a tervező tevékenységnek csak kis részét jellemzik
Ezek az intuíció - a „belátás” - pillanatai, amikor a jelentős ötletek születnek (tudáson alapuló szintű, összetett probléma-megoldó tevékenység)
A tevékenység döntő része még elismerten sikeres és eredeti tervezők esetén is
gyakorlottságon alapuló (rutin), és
szabályokon alapuló (egyszerű probléma-megoldás).
Csökkenteni kellene a rutin és a szabályok alkalmazásának arányát, hogy az intuíció hatékonyabb legyen
Pszichológia a tervezésben
A felhasználói felület tervezését támogató filozófia és módszertan
GOMS modellek
Kognitív ciklusidő
tC = 70 ms (25 - 170 ms)
Korábban már exponált tételek felismerésének időigénye újonnan adott listán.
Motoros ciklusidő
tM = 70 ms (30 - 100 ms)
Az ember által végzett különböző mozgások nem folytonosak, mikromozgások sorozatából állnak.
tM egy mikromozgás ideje.
Kognitív és motoros ciklusidők
A perceptuális ciklusidő
tP = 100 ms (50 - 200 ms), ez a pszichológiai jelen
a két legfontosabb perceptuális csatornára, a vizuálisra és a hallásira vonatkozó kísérleti eredmények alapján.
Ha a t=0 időpontban igen rövid időre fény villan fel, akkor az a t= tP időpontban a vizuális tárban még rendelkezésre áll.
A t < tP feltétel mellett tapasztalható a látszatmozgás és érvényes a
Ciklusidők
Egyes lépéseknél szeriális (sorba kapcsolt) elemű feladatokra dolgozták ki, miközben a valós feladatok nagy részében sok párhuzamosan futó elem van.
Egyáltalán nem kezeli a mentális megterhelést.
Csak a használhatósággal (usability) foglalkozik, nem tud mit kezdeni a funkcionalitással (functionality).
Egyáltalán nem kezeli a felhasználók elfáradását.
Egyáltalán nem kezeli a felhasználók közötti egyéni különbségeket.
Semmilyen támpontot nem ad arra vonatkozóan, hogy a felhasználók mely esetekben ítélik a rendszert hasznosnak, kielégítőnek, illetve globálisan elfogadhatónak.
A GOMS csak gyakorlott felhasználókra alkalmazható: a gyakorlatlan felhasználók sok időt probléma-megoldással töltenek el és nem a feladat ésszerű terv szerinti végrehajtásával
Nem tudja figyelembe venni:
a tanulás hatását,
a hosszabb kihagyás utáni újbóli használat problémáit
hogyan kell jól tanulható konzisztens felhasználói felületet kialakítani.
Hibamentes munkára vonatkozik, a hibázásokat nem tudja figyelembe venni.
A számítógépes munkavégzés
elemi perceptuális és motoros komponensei vonatkozásában konkrét és határozott,
a kognitív folyamatokat illetően azonban kevéssé differenciált.
Korlátok
A felhasználó azon eljárásai amelyekre támaszkodva adott helyzetekben a rendelkezésére álló lehetséges módszerek közül választ.
Pl.: Cél ugyanannak a szónak a többszöri beírása. Lehetséges módszerek:
a közvetlen manuális beírás
a vágólapról történő sorozatos bemásolás (egér, ctrl-v)
a Kész szöveg -> Szövegtár funkció különböző alkalmazása.
Kiválasztási szabályok
Operátor-sorozatok (szekvenciák), amelyek segítségével bizonyos célok elérhetőek.
Hacker- féle akció-elmélet értelmében összetettebb akcióknak tekinthetők.
Módszerek
Perceptuális operátorok:
rövid fényfelvillanás észrevétele (100 ms),
hatbetűs szó felismerése (340 ms),
egy "szökellő" szemmozgás elvégzése (230 ms).
Kognitív operátorok:
egy parancs előhívása az HTM-ból (1350 ms),
parancs ismételt előhívása az HTM-ból (660 ms),
döntés módszerek közötti választásról (620 ms).
Motoros operátorok:
kézmozgás billentyűzetről egérre (360 ms),
kézmozgás billentyűzet más részéről kurzor vezérlő billentyűkre (210 ms),
kézmozgás billentyűzet más részéről funkciós billentyűkre (320 ms).
Operatorok
Az emberi tevékenység adott célok által vezérel (Hacker akció elmélete, Rasmussen modellje)
Ezek a célok ember-számítógép interakcióban az elérendő végállapotok
A kivitelezés terv meghatározása:
rutin feladatokra (nem tudatos)
tárolt eljárásokra
szabályokra épül
A kivitelezés terv felépítése már részben vagy egészében tudatos is lehet
Célok
Egyszerűbb ember-számítógép interakció típusok elemzése és modellezése
Előrejelzések az adott interakciós módokkal dolgozó felhasználók várható feladat-megoldási időire
Mennyi időt nyer a felhasználó azzal, ha az eredeti 0,2 cm-es célterület (pl. menüsáv) helyett 0,5 cm-eset kell elérnie 10 cm-ről?
Pl: Elérési idő csökkentése
A visszacsatolás a motoros akcióról a percepció felé viszonylag lassú (200 - 500 ms),
gyorsan végzett tevékenységeket (gépelés, beszéd), előre programozott motoros akciók bizonyos hosszúságú sorozataiban (ún. bursts) bonyolítjuk le,
amelyek eredményéről nem - vagy csak utólag - kapunk konkrét visszajelzést.
Gyors mozgásos rutinakció
A kézzel történő mozgás pozícionálási ideje és a céltárgyat jellemző méret, és távolság közötti kapcsolatot írja le
T – pozícionáláshoz szükséges várható idő
a – eszköz indítási/leállítási idő
b – az eszköz belső sebessége
D – távolság indulástól érkezés középpontjáig
W – cél szélessége a mozgás irányában
a, b eszköz specifikus érték
Fitt törvény
Iskolapélda: előugró menüsávok vizsgálata
Pl: Menüsáv áttervezése
Ez a megoldás sokszorosára növelte a célterületeknek a Fitt törvényben szereplő effektív méretét (W-t). Az így kapott idő-megtakarítás már valóban jelentős: 25% (1800 ms -> 1450 ms).
A döntési idő egyenlő valószínűségű döntési alternatívák esetén a következőképpen függ a döntési alternatívák n számától:
Hick törvény
Interjú
a használó megismerése,
munkájára vonatkozó ismeretei,
fogalmai, szóhasználata, mentális modellje,
mit csinál: feladatainak fölsorolása, ezek tartalma,
a munka módszere: hogyan csinálja, teljesítmény adatok, rutin feladatok és különleges esetek,
feladatok, a végrehajtás módja, műveletelemek.
Célok
Lehet előre tervezett szerkezetű (kérdések és válaszok), vagy szabadon folyó, de mederben tartott beszélgetés
Megfelelő személyt kell találni: a munkát ténylegesen végző, jellemző felhasználó
Gyors és egyszerű módszer, és olcsó, azonnali eredményekkel, sok és mélyreható ismereteket szerezhetünk
Arról tájékozódjunk inkább, hogy
most mit csinál
, nem arról, hogy mit vár az új szoftvertől
Fókuszcsoport megbeszélés
Egy meghatározott célra összpontosítunk, ennek tudatosítása az elején
Cél: kérdés(ek) feloldása
Forgatókönyv szerint zajlik
követelmények összegyűjtése
fontossági sorrend felállítása
a termék vagy prototípus értékelése a megfogalmazott követelmények alapján
Cél: értékelés
Céltól és résztvevőktől függően többféle lehet:
A munkában érdekeltek rendszeres megbeszélései: tervezők, programozók és a használók
Megcélzott vagy valós felhasználókkal való csoportos interjú
Kérdőív
Csak tárgyszerű kérdések (nincsenek kényes kérdések)
Előre meggondolni: mire vagyunk kíváncsiak, hogyan fogjuk kiértékelni, hogyan fogjuk fölhasználni
A kérdőív feleljen meg néhány formai és tartalmi szabálynak
Legyen világos a kérdőív célja, kiértékelése, fölhasználása
A kérdőívet először magunk, majd kisebb csoport megpróbálja kitölteni
Kérdőív készítése
Papíron kiosztott (ma inkább számítógépen, weben) kérdések sorozata
A használó és feladatai megismerésének egyik eszköze (de másutt is használjuk)
Irányelvek
Az irányelv gyűjteményeket ellenőrzőlistába szokták szervezni
Minden irányelvre Átmegy/Megbukik (Pass/Fail)
Ha nem sikerült, lehet ajánlásokat is mondani (miért nem ment át)
Irányelvek ellenőrzésére sokféle módszer van
Rendszer dokumentáció ellenőrzése
Dokumentált bizonyíték
Analitikai bizonyíték
Empirikus bizonyíték
Mérés
stb.
Használat
A felületek tervezésére vonatkozó irányelvek (GUI design guidelines) a bevált gyakorlatokat tükrözik
Hasznos magas szintű, esetenként alacsony szintű iránymutatást adnak a használhatóság növeléséhez
http://www.useit.com/homepageusability/guidelines.html
Nielsen kezdőlap checklist
Direct manipulation dialogs-ra vonatkozik
ISO 9241-16 Checklist
Olyan termék elemzésére használható a legjobban, amelyek használatát a felhasználók az explorációs (felfedező) tanulás útján sajátítanak el.
Többféle forma, legismertebb a kognitív (de van pluralisztikus, szerepátvétel alapú, stb.)
Az elemzés az elképzelt felhasználó lépéseinek szimulációját jelenti kérdések feltevésével.
A használat során feltárt problémákra a tervezés következő iterációs lépésében kell megoldást találni.
A vizsgálatot szakértők vagy a valós felhasználók végezhetik.
Bejárási technikák
Az alapot a felhasználó viselkedésének a következő egyszerű modellje képezi:
A felhasználó egy nagyvonalú elképzelést alakít ki arról, hogy mi a célja, mit is akar elérni (definiálja maga számára a feladatot).
A felhasználó a felhasználói felületen keresztül felfedezi a rendszert: igyekszik olyan akciókat találni, amelyek hozzájárulhatnak célja eléréséhez.
A felhasználó kiválasztja és végrehajtja azt az akciót, amelyről leírása vagy megjelenése alapján úgy érzi, hogy leginkább illik ahhoz, amit el akar érni.
A felhasználó értelmezi a rendszer válaszát és megítéli, hogy közelebb jutott-e célja eléréséhez.
Bejárás modellje
A „kognitív bejárás” (Cognitive Walkthrough) a szoftverek egyik funkcionális tesztelési módszerének, a „kód-bejárásnak” (Code Walkthrough) az adaptálása a UI vizsgálatára
A kód-bejárás -> programozók értékelik egymás programjait (verbálisan végigkövetik egy kiválasztott programrészlet futását)
A kognitív bejárás -> elemzők értékelnek egy rendszert (verbálisan végigkövetik azt az utat, amin a felhasználóknak végig kell menniük egy kiválasztott feladat elvégzése érdekében)
Ahogyan a kód-bejárás programhibákat (bug) talál, úgy a kognitív bejárás olyan pontokat azonosít, ahol a felhasználók valószínűleg nem találják meg a helyes tennivalókat
Ahogyan a kód-bejárás nem igényel gépet, úgy a kognitív bejárás sem igényel valódi felhasználókat és ezért egészen korai verziók vizsgálatára is használható.
Kód és kognitív bejárás
Példa feladatlap
Az elemzés az (1), (2) és (3) lépések szimulációját jelenti a következő kérdések feltevésével:
A következő helyes akció kézenfekvő és felismerhető?
Az akció tartalma összeköthető a céllal?
Válasz van és az értelmezhető, eldönthető a helyessége?
A feladat végrehajtása konzisztens az alkalmazáson belül?
Bejárás végrehajtása
Az elemzést a csoport tagjai egymástól függetlenül kezdik. Az elemzőket egy-egy asszisztens figyeli, s minden észrevételét rögzíti.
Ezek után az összesített hibalistát együttes ülésen megnézik: közösen mérlegelik a megtalált problémák súlyosságát.
Heurisztikus elemzések
Papír prototípus
Nem működő prototípusokat demonstrációs vagy kreativitást serkentő céllal gyakran használnak a szoftverfejlesztésben. Pl. mock-up
A papír prototípus alacsony valósághűséggel rendelkező (low-fidelity) prototípusfajta
A papír prototípus lehet kézzel rajzolt vagy bármilyen képszerkesztő vagy rajzolóprogrammal létrehozott és kinyomtatott
Tesztelésre akkor használható, ha valós tartalma van és a felhasználó interakciót folytathat vele (egyébként csak bemutatásra szánt képernyőtervek)
Prototípusok
Nagyobb a helyigény, mint számítógépen történő tesztelésnél (mert több az eszköz és a résztvevő)
Végrehajtás
Felhasználó
„Számítógép” (=a számítógép szerepét játszó személy)
A teszt vezetője (facilitátor)
Megfigyelők
A résztvevők
Megjelenítési hibákat
Hátrányok
Rossz alapkoncepció
Félrevezető szóhasználat
Navigációs problémák
Tartalmi kérdések
Mit tartalmazzon a súgó
Elrendezés a képernyőn
Megtalált problémák
A prototípust nem kell leprogramozni, csak megrajzolni
A kódolás előtt azonosítja a fő problémákat (technikai jellegűeket is)
Pillanatok alatt módosítható, a módosítás helyben kipróbálható
A használhatósági tesztet el lehet akkor is kezdeni, ha a fejlesztés késik
Nem csak a hibák azonosítására, hanem a designnal kapcsolatos kérdések tisztázására is használható
Előnyök
A papír prototípus alapú tesztelés a használhatósági tesztek olyan formája,
ahol a szoftver későbbi felhasználóinak egy reprezentatív csoportja
realisztikus feladatokat hajt végre
azáltal, hogy interakciót folytat
a felhasználói felület papíron rögzített verziójával,
amelyet egy, a számítógép szerepét játszó valós személy működtet.
Ennél a tesztnél tesztülések között, sőt azok közben is meg lehet változtatni a felhasználói felületet (de meg kell nézni, hogy valóban megoldottuk-e a problémát)
Reális és jelentőséggel bír a felhasználók számára
Nem túl általános és nem túl specifikus (Nem: „Hogyan navigálnak a felhasználók az oldalon?”)
Véges számú, meghatározott megoldása van (Ne adjunk olyan feladatot, amit lehetetlen végrehajtani)
Felismerhető végpontja van (Nem: „Nézzen körül ezen az oldalon!”)
Cselekvésre, nem véleményre vonatkozik (Nem: „Mégis mit gondol erről a weboldalról?”)
5-30 perc alatt megoldható
Leírása tartalmazza a feladat előfeltételeit, a megoldás lépéseit, becsült időtartamát, eredményét, a használónak adandó instrukciót
A jó tesztfeladat
Résztvevők meghatározása (pl.: tervező, fejlesztő, grafikus, szoftvererges, marketinges, technikai dokumentáció készítője, stb.)
Megválaszolandó kérdések felvetése (pl. Milyen fontos design/üzleti döntéseket kell meghozni? Miben nem vagyunk biztosak?)
User profile meghatározása (képzettség, tapasztalatok, munkahely, beosztás, egyéb demográfiai és viselkedéses jellemzők)
Az egész kutatás idői beosztásának megtervezése (pl. tesztfordulók száma)
A tesztülés idejének megtervezése (általában 1-2 óra)
Hány felhasználó vegyen részt a vizsgálatban (papírprototípus-alapú tesztnél 3-4 elég)
Felhasználók toborzásának megkezdése
Teszt tervezése
Ha nem tűnik befejezettnek az alkalmazás, a felhasználók kevésbé „fogják vissza” magukat.
Használható, nem szőrszálhasogató kritikát kapunk.
A műszakilag kevésbé képzetteket sem félemlíti meg.
Példák
Metrikák
Az alap gond: ha nem tudja megoldani a felhasználó a feladatot, meddig tartson a teszt?
Meg lehet mondani a felhasználónak, hogy addig foglalkozzon a feladattal, amíg készen nincs, vagy a valóságban feladná / segítséget kérne
Három csapás elve (Mi számít próbálkozásnak?)
Idő korlát a feladatok elvégzésére

Figyelem: ha egy feladat nem sikeres, bármennyire is nem a felhasználó hibája, idegesíti őt, ezáltal befolyásolja a továbbiakban.
(TM1) Megállási szabály
Az adatgyűjtés közvetett módja: a használati napló file-okat elemezzük
Az előnye, hogy a tényleges használat során keletkezett adatokat vizsgáljuk (rossz feladatok is kiszűrhetők)
Adatbányász módszereket lehet használni
Hátránya:
A fejlesztés során nem annyira használható
Mit csinál a felhasználó?
Ha bonyolult az adatbányász modell, félrevezető lehet
Különleges adat: Naplók
Használhatósági problémának számít a felület azon hibáit, amely csökkenti a hatékonyságot, hatásosságot vagy az elégedettséget
A fejlesztés során történik
Felhasználói tesztekkel
Súlyosság alapján lehet besorolni őket
Fajtái: Összes probléma, kategóriánkénti problémák száma, feladatonkénti problémák száma
Probléma alapú metrika
A legegyszerűbb gyűjteni: megkérdezzük a felhasználót, mit gondol a rendszerről
-> Kérdőív + interjú
Hasznos, mert megmutatja a rendszer érzékelését, percepcióját
Érzéseket is mutathat (elégedettség méréshez kell)

Mikor gyűjtjük:
Feladat után
Teszt végén
Önbeszámolt metrikák
Mit csinál a felhasználó a teszt alatt (verbalizáció, testbeszéd, fiziológiai adatok)
Méréshez előképzettség és különleges hardver szükséges (szemmozgás követő kamera)
Például verbalizáció és testbeszéd:
Teszt közben feljegyzésre kerül, mit mond vagy csinál a felhasználó
+/- megjegyzések, javaslatok, kérdések, …
Arc kifejezés, kéz mozdulatok, …
Viselkedési metrikák
Mérés előtti teendők:
Kell egy teljes + pontos lista a műveletekről
A műveletek elejét és végét meg kell határozni (kognitív?)
A műveleteket kell majd megszámolni -> videó készítése hasznos lehet
A műveleteknek értelmesnek kell lenniük
Csak sikeres feladatokat nézzük
A mérés nehézsége, hogy sok művelet nagyon gyorsan történik
(TM4) Hatékonyság mérése
A hatékonyságot lehetne mérni a feladat idővel is, de még jobb, ha a feladat elvégzéséhez szükséges erőfeszítést mérjük
Például mennyi művelettel jutott el a feladat végéig
Minden művelet egy bizonyos mennyiségű erőfeszítésnek felel meg
A cél a műveletek számának, így az erőfeszítés csökkentése
Erőfeszítés lehet:
Kognitív: „fejben történő dolgok”
Fizikai: művelet végrehajtása
(TM4) Hatékonyság
A hibák méréséhez előre tisztázni kell a helyes műveletek halmazát
A hiba lehetőségeket is előre tudni kéne
Milyen lehetőségei vannak a felhasználónak hibázni?
Lehet, hogy nem minden hiba egyforma fontos
Minden esemény egy hibának számít
A hibák számából nem lehet következtetni arra, hogy mi történt valójában
A hiba típusok okait meg kell vizsgálni
(TM3) Hibák mérése
Felhasználó hibázik -> általában tervezési hibáról van, felületi vagy mélyebb
Tetszőleges használati hibát érthetünk ez alatt (csúszás, kihagyás, tévedés)
A hibák mérésével kideríthető, hogy miért nem sikerül egy adott feladat
A teljesítmény mérésében is segít (a hibák száma megmutatja a kevésbé jó felületi részeket)
(TM3) Hibák
Feladat idő: a feladat elkezdése és befejezése közt eltelt idő percekben (másodpercekben) stopperral vagy időbélyeggel
Előre meg kell határozni és az összes feladatra konzisztensen, hogy mikortól kezdünk és meddig mérünk
Vége: amikor már nem használja a rendszert
Még így is zajos lehet…
(TM2) Feladat idő mérése
Általában 3-6 szintet használnak, leggyakrabban 3-at:
Siker
Részsiker
Kudarc
(Lehet tovább alszintezni, pl segítséggel vagy segítség nélkül)
A szintek reprezentációjára két módszer:
Siker pont: A szinteket 0,0 és 1,0 közti értékekre határozzuk meg, lehet átlagolni
Felhasználó élmény alapján (szint a problémák alapján)
(TM1) Szintes siker használata
Ha megállapítható a siker mértéke, akkor szintes sikerről beszélhetünk
„Részpontszám”
A feladat részleges végrehajtása is értékes
Gyűjtése hasonlít a bináris sikerhez, csak előre a szinteket is definiálni kell, például:
A feladat minden lépése sikeres?
Nehéz volt végrehajtani az egyes lépéseket?
Szüksége volt segítségre? (súgó)
A végrehajtás optimális volt, vagy kerülővel jutott el?
Ha a szintek kicsit puhák, akkor nehéz lehet megegyezni, mekkora is volt a siker
(TM1) Szintes siker
A legelterjedtebb metrika:
A felhasználó hatásosságát méri egy adott feladat halmazra
Ha a feladatot könnyű meghatározni – könnyű mérni
Mindig feladat alapú

Két fő típus:
Bináris
Szintes

Értékeléshez nem kell matekozni: ha sikeres, akkor minden ok, ha nem, akkor valami nem jó
Ezért lehet verifikációra és validációra is használni
(TM1) Feladat eredmény
A használhatóság definíciója alapján:
(ISO 9241) 3.1 Használhatóság „Annak mértéke, ahogy a terméket meghatározott felhasználók meghatározott
célokért hatásosan, hatékonyan és elégedetten használják egy adott környezetben.”
Hatásos -> „Elvégezte a feladatát?”
Hatékony -> „Milyen gyorsan végezte el a feladatát?”
Elégedett -> ? „Közben mennyire érezte jól magát?”
A használhatóság minőségi jellemzői alapján:
ISO/IEC 9126-1:2001: Software engineering – Product Quality- Part 1: Qualty model, 6: Quality model for external and internal quality
Tanulhatóság (Learnability)
Érthetőség (Understandability)
Működtethetőség (Operability)
Vonzóság (Attractiveness)
Megfelelősség (Compliance)
Mit mérünk formálisan
Elérhetőség: fogyatékkal élők mennyire tudják a rendszert használni (->általában is javítja a használhatóságot)
Nemcsak vak vagy siket, hanem pl: idős vagy gyerek felhasználók, idegen nyelvet beszélők
Metrikát a célcsoport szerint határozzuk meg
Jól számolható az irányelv listáknak való megfelelés, pl.: a W3C akadálymentesítési listája
Különleges adat: Elérhetőség
A kezdő felhasználók még nem használják hatékonyan a rendszert, az idő múltával fokozatosan szereznek tapasztalatokat, ez a tanulási görbe
A tanulhatóság a görbe meredeksége
A tanulhatóságot a ráfordított idővel és erőfeszítéssel mérik, amíg a felhasználó kiismeri a rendszert
Más TMx-eken alapszik, de több teszttel, időkihagyásokkal mérik
A tanulhatóság egy másik eleme a visszahívás, az elsajátítás után mennyire marad tartós az ismeret
(TM5) Tanulhatóság
A hatékonyság méréséhez kiváló
Általában minél gyorsabb, annál jobb a felhasználónak
Nem mindig a legjobb. Pl.: játékok, vagy meghatározott ideig tartó feladatok
Kérdés: a sikertelen feladatokat mérni kell-e
Az idő mérése befolyásolja a felhasználót:
Ha nem mondod meg: elkalandozik
Ha megmondod: ideges lesz
Jó módszer: nem mondod meg, de megkéred, hogy a lehető leggyorsabban csinálja
(TM2) Feladat idő
A feladat eredmény legegyszerűbb formája
Két lehetőség van: siker vagy bukás
Akkor érdemes használni, ha az egész rendszer célját vizsgáljuk
Méréskor érdemes 1-et vagy 0-át írni (könnyebb összeadni a végén)
Hátránya, hogy nincsenek részletek mi történt, hol van a hiba
(TM1) Bináris siker
Feladat eredmény mérésének van egy fontos előfeltétele: Előre el kell dönteni mikor sikeres a feladat, és mikor nem
Kell egy végállapot, ami elkülönül a feladattól
Meg kell határozni, mi számít sikernek
A mérés közben strukturált formában kapjuk az eredményt (űrlap, vagy szóban elmondja)
A teszt vezetője kitöltheti az előre elkészített tesztlapot
(TM1) Mérése
Nem azt mérik, hogy a felhasználók mit gondolnak, vagy mit mondanak, hanem hogy mit csinálnak
A mérés a felhasználó meghatározott viselkedéséről szól
Lényegében:
Legjobb mérés a hatásosságra és hatékonyságra
A miről szól és nem a miértről
Feladat központúak (teljesítmény meghatározott célért történő meghatározott feladat végrehajtása közben)
A használhatóság alapja
Teljesítmény metrikák
Metrikák típusai
Amit nem mérünk az nincs is…
Ha nem tudjuk, hogy hol tartunk most, honnan tudjuk mikor értük el a célunkat?
Számszerűsítve szofterges jellemzők = szofterg metrikák
Többnyire felhasználó tesztek során…
Alapkérdések: Mit, miért, hogyan
Szabványos Használhatósági Skála
10 kérdéses, Likert skálás, attitűd vizsgáló kérdőív
Az egész rendszerre ad egy értéket 1-100 között
Más rendszerekkel is összehasonlítható az eredmény
Az egy dimenziós vég érték előny és hátrány, jól összesít, de a részleteket elfedi
Szabadon elérhető (SUS, Standard Usability Scale)
SzHS
Bevezetés
Alapfogalmak
Módszerek
Objektumok kiválasztása aktív helyeik megfogása révén
Sok tekintetben bonyolultabb (pl.: mentális modell nem látszik kívülről), mint nem szoftver esetben
Sokkal többféle lehetőség szoftveres felület megalkotására (ez is bonyolítja)
A szokásos TV távirányító....
Vagy kicsi a kezünk?
... és még egy a DVD-nek, a kábel-nek, a hifinek, a ...
Ami kellene...
Polgár Péter Balázs
http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-Generation.aspx
Erre gondolunk...
... ezt kapjuk.
Miért foglalkozunk?
Egy szoftver tervezésekor a megvalósítási lehetőségek száma majdnem végtelen - ami azt is jelenti, hogy majdnem ugyanennyi olyan megoldás van, amit a felhasználók
nem tudnak
, és végül
nem is fognak használni
.
1
2
3
Használhatóság def
(ISO 9241-11:1998 Definition 3.1)
Használhatóság = SzoftErg
User Experience
Program tervezés (computer science)
Pszichológia
Design
Hogyan hozzunk létre szoftvereket, rendszereket?
Mit tudunk létrehozni?
Milyenek az emberek?
"a person's perceptions and responses that result from the use or anticipated use of a product, system or service".
Nincs univerzális használhatóság
A használhatóság mérhető
Ez egy interdiszciplináris terület még, sokan sokfelöl jöttek, ennek megfelelően az elnevezés sokféle lehet... a lényeg a "="-n van.
"Annak mértéke, hogy
adott környezetben
,
adott felhasználó

adott feladatot
mennyire
eredményesen
,
hatékonyan
és
elégedetten
végez el egy termékkel."
Shneiderman arany 8-asa
1. Konzisztencia
Ben Shneiderman "Designing the user interface" könyvéből (első kiadás: 1987)
Használhatóságban lassan változnak a dolgok, mert a témánk az ember, aki szintén lassan változik - szemben a technológiával
Tegyük lehetővé a felhasználók számára egyes lépések lerövidítését vagy átugrását (”shortcut”).
2. Rövíditések
Biztosítsunk informatív visszajelzést.
3. Visszajelzés
4. Dialógusok
Engedélyezzük az akciók visszafordítását (”undo”).
6. Visszavonás
Tegyük lehetővé, hogy a felhasználó uralja a párbeszédet.
7. Irányítás
Csökkentsük a rövid idejű memória terhelését.
8. Terhelés
Biztosítsunk egyszerű hibakezelést.
5. Hibakezelés
Ha hiba történt, a felhasználó nem
jópofizást
technikai bla-bla-t
"OK" gombot
akar, hanem
a hiba pontos leírását
megoldási lehetőségek
akció (most mit csináljon)
De a legjobb, ha nem is lehet hibázni (error prevention)
Hasonló dolgokat hasonlóan nevezünk, jelzünk, csinálunk.

Különböző dolgokat különbözően nevezünk, jelzünk, csinálunk.
Törekedjünk konzisztenciára.
Főleg a haladó felhasználókat segíti, a hatékonyság (efficiency) növelése miatt fontos.
Támogatja a fokozatos tanulást is (kezdőknek más kell, mint a haladóknak.)
Nem mindig nyilvánvaló, hogy mi történik - pláne hogy egyáltalán történik-e valami.
a számítógép "dolgozik"
már kell visszajelzés (pl.: animáció)
10 sec - figyelemi fókusz határa
0,1 sec - azonnali válasz érzet
1 sec - megszakítottság érzet
közvetlen hatás az interakcióra
visszajelzés maga az akció eredménye
a felület lassú
észrevehető visszajelzés (homokóra )
mikor lesz kész
megszakítás lehetősége
Válaszidők, visszajelzések
A felhasználó mindig legyen tisztában azzal, hogy amit éppen csinálni akar, az már elkezdődött, hol tart, és befejeződött-e.

Lezárás: kellemes érzés + mutatja hogy kezdhetem a következőt.
A párbeszédeknek legyen világos kezdete, tartalma (közepe) és befejezése.
Ha van egy állandó menekülési útvonal, amivel az ember bármit csinál, vissza lehet menni, az bátorítja a funkciók önálló felfedezését, megtanulását.
A (számítógép) az ember munkáját segíti, tehát nem szabad, hogy ő irányítsa az ember munkáját.
A felhasználó kezdeményezzen, ne reagáljon

(Látszat irányítás: pl.: placebo gombok)
(Kivéve: varázslók, de ezek is inkább a kezdőknek segítenek.)
A gép nagyon sok mindent egyszerűbben, gyorsabban csinál, használjuk ki a lehetősegeket, csökkentsük a felhasználó mentális terhelését.

Erre azért is szükség van, mert az ember munkamemóriája korlátos.
Nemcsak arra vonatkozik, amire "emlékezni kell", hanem amit "át kell látni".
Nemcsak memória, hanem minden fajta mentális errőforrás, pl.: figyelem, észlelés...
Action Facilitation Approach
ROE (1988)
9
8
7
6
5
2
3
4
1
Használjuk az ő szókincsét!
Használjunk udvarias hangnemet!
Hagyjuk, hogy ő uralja a párbeszédet!
Biztosítsunk több párbeszéd-szintet!
Azonos válasz-időket biztosítsunk hasonló helyzetekben!
Ha a válaszidő 15 másodpercnél hosszabb, közöljük ennek okát és a várható válaszidőt!
Adjunk teret az "akció-programok", valamint végrehajtásuk módosításának!
Támogassuk az "akció-programok" megszakításmentes gyors végrehajtását a tevékenység alatti és az eredményt közlő visszajelzésekkel!
Biztosítsunk eszközöket az akciók előkészítéséhez!
Biztosítsunk eszközöket az akciók végrehajtásának ellenőrzésére, beleértve a későbbre tervezett akciókat is!
Vegyük figyelembe a felhasználó perceptuális, kognitív és motoros mechanizmusainak lehetőségeit és korlátait!
Vegyük figyelembe és támogassuk a felhasználó azon igyekezetét, hogy optimalizálja az akciók hatékonyságát: tegyük lehetővé számára a Rasmussen-féle szabályozási szintek változtatását!
Tartsuk fent az egyenletes munkaterhelést!
Vegyük figyelembe és támogassuk a felhasználó azon igyekezetét, hogy egy időben több feladattal is foglalkozzon!
Ez az elrendezés a távoli menüsávoknak meglehetősen lassú elérését teszi csak lehetővé.
Ez az elrendezés felére csökkenti ugyan az átlagos távolságokat, de többlet kognitív terhelést ró a felhasználóra, mivel dönteni kell a mozgás irányáról.
A távolabbi menüsávok szélesítésével csökkent azok elérési ideje, de - a Fitt törvénynek megfelelően - ez mindössze mintegy 80 ms nyereség (1800 ms -> 1720 ms).
A felhasználói teszt
Felhasználó
Szoftver
Teszt vezető
Megfigyelők
Valós
visszajelzés
a szoftverrel valós
feladatokat
végző valós
felhasználóktól
Feladat
A jó feladat
Levezetés
DE
Felhasználó teszt...
Nem a felhasználót teszteljük, hanem a szoftvert
A felhasználó segít nekünk a használhatósági hibák feltárásában
Ennek megfelelően kezeljük a tesztet megelőzően, közben és utána is.
Ha zavar a név, inkább hívjuk használhatósági tesztnek.
Eredmény
A teszt
Távoli
Felkészülés
Mennyi felhasználót vizsgáljunk?
Csak akkor van értelme, ha az eredményeket fel is használják.
Forma
Típusok szerint
Levezetés
Technika
Folyosói teszt
Laborban
Retrospektíven
Szemmozgáskövetés
Felvétel
Közvetítés
http://www.bbsoftware.co.uk/bbflashbackexpress/download.aspx
Ingyenes, veszi képernyőt, kamerát, hangot.
Google hangout - google acc-al ingyenes
Hangosan
"Think aloud" protokol
Megkéred a felhasználót, hogy hangosan gondolkozzon, mondja el mit miért csinál
Megismerhetők a gondolatai, hogyan gondolkozik a feladatáról
Elő kell idézni a teszt vezetőnek - folyamatos kérdésekkel, pl:
"Miért kattintottál oda?"
"Mire számítottál, mi fog itt megjelenni?"
"Mond el, hogy szerinted ez mit csinál?"
A felhasználó végzi a feladatát, miután készen van, visszanézve egy felvételt (még jobb szemmozgás követővel) rákérdezni, hogy mit miért csinált.
Csak speciális esetekben jó, pl. a feladat főbb elemeinek végrehajtásávát már ismerjük, a feladat elmélyültséget kíván.
Terepi
Kontrollált körülmények
Felhasználót zavarhatja
Felhasználó közeli körülmények, előkészület nehéz lehet
Felhasználó saját gépe, nem jön át testbeszéd, nehéz lehet a szoftver beállítása
Aki éppen arra jár kipróbálja gyorsan
Több adat, több költség
A jó riport
TTT
Tagolt
Tömör
Tárgyszerű
A talált hibákra koncentrál - és a lehetséges megoldásokra
Érthető a fejlesztőnek, érthető a vezetőnek
Változást eredményez
"Fogyasztható"
Nyílt
A felhasználó a saját végrehajtási terve szerint halad - ha nem akar egy funkciót kipróbálni, külön kérnünk kell rá
A felhasználó az előre megadott feladatokat hajtja végre, nem próbál ki olyan funkciókat, amik nem a feladatához tartoznak
vs
Zárt
Nem irányítja a felhasználót (nem azokat a szavakat használja, mint a felület)
Egyértelmű, végrehajtható
Csak akkor zárt végű, ha valami nagyon konkrét dologra vagyunk kiváncsiak
A teszt céljához igazodik
Nielsen féle ökölszabály
5
http://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
0 felhasználó - 0 eredmény
Már jobb a nagy hibákat kiszűrni és újra tesztelni
12 a hibák többsége megvan
http://www.nngroup.com/articles/how-many-test-users/
DE
Agilis / lean eset:
RITE
Rapid Iterative Testing and Evaluation
1 teszt, nagy hibák javítása a következőre
2. Felhasználók
1. Teszt célja
3. Szoftver előkészítése
4. Lebonyolítás terve
Mire vagyunk kiváncsiak, milyen tervezési / vizsgálati kérdésre szeretnénk választ kapni.
Fontos tisztázni, hogy a választott módszerrel erre valóban választ kaphatunk.
A teszt céljának megfelelő felhasználók toborzása
Fontos lehet:
Előképzettség
Szoftver használati tapasztalat
Mivel foglalkozik amúgy
"Incentíva"
A teszt levezetője ismerje jól a szoftvert.
Ha prototípus legyen világos, hogy meddig működik, milyen hibaüzenetek várhatók.
Nem muszáj percre lebontani, de legyen meg az elképzelés, hogy kb mire mennyi idő kell majd.
Nem szerencsés 1 óránál hosszabbra tervezni, elfárad a felhasználó és a vezető is.
A teszt egy nagyon furcsa élmény a felhasználónak - kicsit olyan mint egy vizsgahelyzet.
Ezért fontos, hogy megfelelő légkört teremtsünk, ne érezze úgy, hogy "produkálnia" kelljen magát vagy bármi rosszat tud tenni.
Ha elakad - dönteni kell, mikor segítünk neki átlendülni a holtponton.
Ne hagyjuk, hogy valami a felhasználóban "maradjon", azért van a teszten, hogy segítsen, így kérdésekkel derítsük ki a lehető legtöbbet.
Teszt végén mindig biztosítsunk időt a közben felmerült kérdések megválaszolására (közben nem lehet megbeszélni, lehet, hogy üti a teszt célját.)
Miért?
Nemcsak arra ad választ, hogy
mit csinálnak
a felhasználók, hanem arra is,
hogy miért
.
Mint kvalitatív kutatási forma új szempontokat is felderíthet.
Az egyik legjobb módszer tényleges felhasználói visszajelzések gyűjtésére.
Tervezési szempontok
Egyszerű, érthető a kérdés?
Egyértelmű a válaszadás módja?
Könnyen kitölthető?
Lényeges a kérdés?
Nem fölösleges?
Könnyen értékelhető?
Csak más vizsgálatokkal együtt használható, azokat előkészíti
Gyors, egyszerű módszer, de személytelen
Speciálisak, pl.: SUS (Standard Usability Scale)
Célja: ismeretek szerzése emberek egyes csoportjairól, feladataikról, tevékenységükről
Könnyen kitölthető?
Nem túl sok a kérdés?
Terjedelme nem túl nagy (egy-két oldal)?
Az elején kijelenti a kérdőív célját?
Van fölvilágosítás a kitöltés módjáról?
Logikusan csoportosítottak a kérdések?
A kérdőív
Minden kérdésre
A legrégebben alkalmazott szabványos kérdőív
„Mennyire tetszik a felhasználónak a rendszer”
Mindig konkrét használat után érdemes kitöltetni
Egyetlen szám 0-100 között az eredmény
Sok adat áll rendelkezésre -> könnyű meghatározni hol tartunk másokhoz képest
Ingyenesen használható
Standard Usability Scale (SUS)
Találkozás egy használóval, előzetes megbeszélés után
(Stakeholders / döntéshozóknál speciális: projekt támogatás megszerzése, maga szintű célok tisztázása)
Lebonyolítása
Időtartama: legfeljebb 1/4-1 óra, inkább több alkalommal
Az interjú során, elsősorban az elhangzottak megjegyzésére kell törekedni, értékelés utólag
Az interjú terve: mit akarunk megtudni (kérdések), az értékelés módja, kivel, mikor, hol, a rögzítés tervezett módja, forgatókönyv, mit kell előkészíteni?
Előnyei: több személytől több szempont várható, minden érdekelt kifejtheti a véleményét, jó közérzetet teremt
Résztvevők száma: 10-15, idő: 1-1,5 óra max
Hátrányai: több időt vesz igénybe, a domináns személyiségek elnyomják a csöndesebbeket
Ez hasonlít a marketinges fókusz megbeszélésekre
Az eredmény egy fontosság-elégedettség mátrix
Használható fejlesztési preferenciák, irányok meghatározására
Itt különösen fontos a megfelelő levezetés
Több cél (nem lehet sok) esetén előre napirend
folyamatos tájékoztatás
a haladás ellenőrzése
problémák megbeszélése
Lehet nem papír prototípus (mock-up, simulation), de az kicsit más, bár látszólag nem
és
Technikai
gyors és olcsó
Pszichológiai
Felhasználók
Tervezők, fejlesztők
Döntéshozók
Úgy érzik, van beleszólásuk a termék kialakításába.
Kimutatja, ha a koncepcióval van alapvető probléma.
Megkönnyíti a kommunikációt.
Könnyebb megváltoztatni valamit, amibe kevés erőfeszítést fektettünk.
Elkerülhetőek a „hitviták”.
Milyen jellegű problémákat
nem
találhatunk meg a segítségével?
Gördítéssel kapcsolatos hibák nem jelennek meg
Hosszú listák kezelése a valóságban nehézkesebb
Félrekattintások, billentyűhibák nem jönnek elő
Egérkurzor pozicionálásával kapcsolatos nehézségek nincsenek
Válaszidő nem realisztikus
Interakciós hibákat
Ha a betűméret nem megfelelő
Ha a képekkel gond van
Szöveg rendezése, zárása papír prototípuson rosszabbnak látszik
Ezek mélységiek!
A terv
Egyéb: írnok, a szükséges szerepek eljátszói, a technika kezelői
Lehet egy ember
{
Szempontok papír prototípus alapú tesztelésnél
A „számítógép” szerepét játszó résztvevőt fel kell készíteni (tudja, mire mit kell reagálnia; ne beszélgessen a felhasználóval; várja meg, mit tesz a felhasználó, és arra reagáljon; ne dúlja szét a berendezést)
Eleinte furcsa érzés a felhasználónak, mert szokatlan az interakció
Ha nincs elég megfigyelő, vagy messzebb vannak, hasznos a felvétel, de felülről kell felvételt készíteni
Videó felvétel nem feltétlenül szükséges, mert a tevékenység lassabb, szemmel követhető, a felület pedig tesztről tesztre fejlődhet.
A facilitátornak arra is figyelnie kell, hogy a „számítógép” helyesen reagál-e, és kezelnie kell azokat a helyzeteket, amire nem készültek fel (egy papír prototípus is „lefagyhat”).
Think aloud
Előnyök
Empirikus kísérleteken alapulnak
Irányelvek követése olcsó módszer a jó felületek tervezéséhez
Hátrányok
Néha túl általános egy aktuális problémára (nincs mindenre best practice)
Nem a mi felhasználóinkra vonatkoznak
Pl2
Pl1
Példa irányelvek a 113-ból:
7. A kezdőlapot úgy tervezd, hogy világosan különöljön el az összes többi oldaltól
18. Kerüld a redundáns tartalmat
86. Kerüld a pop-up ablakokat
Csoportokba szervezetten, kifejezetten kereskedelmi portálok kezdőlapjára vonatkozik
A legtöbb módszer hátránya, hogy csak bizonyos fajta tervezési problémákra alkalmazhatók. Kevésbé kötött módszerre is szükség van.
4-6 szakértő végzi
saját tapasztalataik és „design heurisztikák” alapján.
A módszer nagy előnye, hogy olcsó és ismert problémákra hatékony
Hátránya viszont, hogy inkább a hiányosságokra koncentrál, mint a megoldásokra és csak igen kevéssé megismételhető, és elég sok téves hibát jelezhet
Menete
Az eredmények a fenti kérdésekhez kapcsolódó területeken problémák felfedezése: ahol a kérdésre "nem" a válasz, ott valamilyen probléma van. A problémákra a tervezés következő iterációs lépésében kell megoldást találni pl. heurisztikus értékeléssel.
A DR maga is termék, hatékonyan használható
az alaptermék magyarázatában
menedzselésében
dokumentálásában
az ezeket kísérő (állandó) kommunikációban
A DR a tervezői döntések megindokolásának célszerű és jól áttekinthető dokumentálása
Összes tervezői megnyilvánulások 96 %-a közvetlenül a tervezési feladattal volt kapcsolatos, ezen belül:
8 % tervezési kérdések (questions - Q)
38 % tervezési opciók (options - O)
54% pedig értékelési kritériumok (criterias - C)
Példa
(O)
(G)
(M)
(S)
Egyszerű akciók amelyeket a felhasználók könnyen és gyorsan képesek végrehajtani.
Bloch törvény (Inger intenzitás x Idő = konstans vizuális hatás)
Ha a kísérleti személyeknek másodpercenként kb. 10 kattanó hangot exponálnak, akkor valamennyit külön képesek hallani, de másodpercenként kb. 30 kattanó hang esetén is csak kb. 10 kattanásról számolnak be.
A ciklusidők az egyes processzorok minimális elemi információinak a feldolgozásához szükséges idők
Elérési idő csökkentésére 4 változat került kidolgozásra:
Az így elérhető időnyereség tehát minden egyes pozícionálásnál: 567 - 439 = 128 ms.
Ha ezt a műveletet 2000-szer kell egy nap elvégezni, az 128x2000 ~= 256.000 ms ~ 4 perc időnyereség naponta.
Ha az alternatívák eltérő pi valószínűségűek:

A szoftver-ergonómia kimenete lehet a szoftver (felhasználói interakciót biztosító részeinek) terve, ezen belül különösen tevékenységek, tartalmi részek, felületek leírása.

A szoftver-ergonómiai tevékenységek körébe tartozó dolgok közül a legfontosabb a szoftver már elkészült részeinek vagy prototípusainak vizsgálata és tesztelése, ajánlások megfogalmazása a felderített hibák feloldására
A szoftver-ergonómia nem programozás. (DE: prototípus?)
A szoftver-ergonómia nem (visual) design. (DE: szoftver design?)
Nem
Hanem
Megismerjük
Elemezzük
Megtervezzük
(felhasználói élmény?)
Egy személy tapasztalatai és reakciói, amelyek egy termék, rendszer, vagy szolgáltatás várható vagy tényleges használatából erednek.
(ISO FDIS 9241-210:2009. Ergonomics of human system interaction - Part 210: Human-centered design for interactive systems (formerly known as 13407))
Interakciós stílusok
Kérdés felelet
Telefonos interakció
Menü alapú
Közvetlen manipuláció
Űrlap
Hasonlít a papíros űrlapokhoz
Parancssoros
Ember bírja a parancsot, gép értelmezi, végrehajtja, kiírja a választ.
Webes
Gép szövegesen kérdez
Ember szövegesen válaszol
Előnyei
Hátrányai
Nem igényel tanulást
Kevés, egyszerű funkció esetén viszonylag gyors,
Ezért eseti használónak jó,
Jó hibakezelést tesz lehetővé
Sok, összetett funkció esetén lassú, nehézkes,
Hosszabb szöveges válaszok esetén hibázás lehetősége,
Hosszabb idő után unalmas, megalázó lehet,
Bár indokolt esetben, rövidebb ideig jó lehet
Ember irányítson
Akkor jó, ha igény a biztonság
Pl.: szoftver telepítése, reaktor indítása
Természetes nyelvi
Előnyei
Hátrányai
Használható a meglévő telefonhálózat,
Kis ráfordítással jelentős forgalom (semmi köze a szoftver ergonómiához)
Rövid, egyszerű funkciók esetén gyors
Eseti használónak megfelelő lehet
Hosszú, összetett funkciók esetén lassú
Menüpontok fölsorolása, a menüpont neve és tartalma…
Számítógépes interakcióhoz szokott embernek…
A gépi hang idegen  a szöveg gondos tervezést igényel
Előnyei
Hátrányai
Kötetlen szintaxis, kötetlen sorrend
Kevés tanulás
Nem lehet elfelejteni
Rugalmas
Költséges
Gyakran tisztázó kérdések kellenek – ezért hosszadalmas lehet
Gyakran céltól elhajló
Korlátos intelligenciájú rendszereknél ismerni kell a rendszer korlátait
Szóbeli, verbális interakció
vagy gépelés (hosszadalmas)
vagy beszéd (bonyolult?)
Nem egyértelmű az élőbeszéd
-> kontextus fontos
Előnyei
Hátrányai
Gyors, egyszerű, kényelmes,
Használata könnyen tanulható,
Eseti használóknak megfelelő,
A menü látványa tájékoztatás a lehetőségekről
Nem kell megjegyezni a lehetőségeket
Folyamatos használatuk hosszú időn át unalmas
A hierarchikus menüknél a gép irányít
A mélyebben lévő elemek elérése lassú
Gyakorlott felhasználóknak lassú
Tervezési elvek
Egyöntetűség (konzisztencia)
Választási módok: egérrel, billentyűvel...
A menü kinyílik az egér rávezetésekor
Egy kattintás elég – ha nem destruktív
Folyamatos visszajelzés – és nyugtázás
Lehet magyarázat – buborék, állapotsor
Hangjelzés ha baj van
Gyors billentyűk
Tömör menüszavak
Egyértelmű és könnyen megérthető
Kisbetűkkel (de nem túl kicsi betűkkel)
A megjelenő cím összhangban a menüvel
Igék, vagy névszók – egyöntetűen
Szemléletes tagolás
Főmenü + legfeljebb 2 szint
Halványítás
Mindig ugyanott
Szemléletes interakció, a lehetőségek a felhasználó előtt látszanak (felsimerés emlékezés helyett)
Hierarchikus menük,
vagy egérrel lehet manipulálni,
vagy billentyűzettel (menüszám beírni)
A felületen látható objektumokon közvetlenül, kontextusban végzek el műveleteket.
Metafórák, affordanciák!
Előnyei
Hátrányai
Könnyen tanulható, lassan felejthető
Hatékony,
Élvezetes, sikerélményt, megelégedettséget nyújt
Nem biztos, hogy magától értetődik
Előnyei
Hátrányai
Egyszerű, kényelmes,
Csak billentyűzettel: egyöntetű kezelés
Könnyen tanulható,
Eseti használóknak megfelelő,
A kérdések: tájékoztatás a feladatokról
Beépíthető ellenőrzések: teljesség, adat-típusok

Nagyméretű űrlap kitöltése unalmas
(A gép irányít, de nem akkora baj)
Információ (lineáris) bevitelére
Előnyei
Hátrányai
Az ember irányít,
Rugalmas, kifejező parancsok
Előttünk állhat a parancs-napló
Növekményes tanulás
Gyors, egyszerre sok adattal lehet dolgozni
Ismétlődő feladatokra
Haladó felhasználóknak
Kognitív terhelés; emlékezni kell,
Könnyen felejthető
Nehezen tanulható
Fokozott hiba-lehetőség
Nehézkes javítás
Nagyon pontos mentális modell kell, nem lehet hibázni
Következetes szórend, szintaxis szerkezet
Következetes rövidítési elvek (pl. DEL, de CNTRL)
Egyöntetű szóhasználat,
ellenpélda: DELETE, ERASE, CANCEL
Legyen makró építés
Legyenek szóváltozatok (alias)
A paraméterek feltételezett éréke (alap, default)
Legyen súgó
Korlátozzuk a parancsok számát! (?)
Jellemző és megkülönböztethető parancsnevek
A rövidítések mellett a teljes parancsnév is
Tervezési elvek
Linkek
Keresés
Ha nem jó a link szövege, akkor sokáig tart kiértékelni, tényleg erre van-e szükség
Egyértelmű mit kell csinálni, csak egyvalamit lehet csinálni
Értelmezési távolság számít (Keresési eredmény oldal)
Jobban támogatja a mentális modell létrehozását
Ha rossz a keresési algoritmus sokáig tart a végrehajtás
Interakciót segítő eszközök
Metafórák
Felületen használt objektumok és valós elemek közti kapcsolat
Direct manipulációnal fontos
Legismertebb: "Desktop metafóra"
DE:
Affordanciák
Amikor a tárgyak megmutatják, hogy mit lehet velük csinálni - korábbi tapasztalatok alapján.
az objektum tulajdonsága, hogy a felhasználó szerint mit tud vele csinálni.
Észlelt affordancia:
Tényleges affordancia:
az objektum tulajdonsága, hogy a felhasználó mit tud vele csinálni.
Legjobb ha ez a kettő megegyezik (elvárásnak megfelel)
Hozzárendelés (mapping)
A felhasználó hogyan keres kapcsolatokat vezérlők és kijelzők között.
Főzők elhelyezése
Véletlenszerű - 24 lehetőség,
szükséges emlékezni + cimkézés
Párosával - oldalanként 2 lehetőség
=4 összes lehetőség
Teljes hozzárendelés - 1 lehetőség
Nem kell emlékezni, csak felsimerni
Távolságok
Értelmezési távolság
Amit a felhasználó csinálni szeretne, és aminek egy felületi elem látszik
Jelzési távolság
Aminek egy felületi elem látszik, és amit ténylegesen jelent (csinál)
Mentális modell
hiányos tényeken alapszik (nem tudományos modell)
homályos, inkonzisztens
flexibilis
szelektív (ami a felhasználó számára releváns)
korlátozott hatókörű
személyes
instabil - ahogy megismeri a rendszert, változik
Amit gondol, hogy működik a rendszer
Mentális modell
egy kognitív leképezés egy dologról, logikusan és hihető módon megalkotva, hogy a dolog felépítéséről vagy működéséről mit gondolunk
ha megfelelő, akkor segíti a felhasználó munkáját
ha nem, akkor hibázáshoz vezethet
Új folyamat
Használat kontextusa
Követelemények
Design, implementáció
Értékelés
A felhasználói csoportok
Felhasználók jellemzői
Feladatok jellemzői
Kontexus jellemzők
Konkrét design
Prototípusok
Iterációk kezelése visszajelzések alapján
Formatív tesztek
Visszajelzések beépítése
Dokumentáció
Következő iterációra készülés
Szummatív tesztek
Eredmények kommunikálása
Módszerek csoportosítása
Kvalitatív
Kvantatív
VS
Analítikus
Empirikus
VS
"usability testing"
pl.: használhatósági teszt, környezeti vizsgálat, megfigyelés…
Empirikus vizsgálatoknál
a vizsgálandó szoftver terméket - vagy annak működő prototípusát
a felhasználók kezébe adjuk
az interakciót megfelelő eszközökkel empirikusan tanulmányozzuk
labor vagy terep körülmények között
"usability inspection"
pl.: heurisztikus módszerek, irányelv vizsgálat, bejárási technikák…
Analítikus vizsgálatoknál:
valamilyen módon szimuláljuk a felhasználó várható tevékenységét
vagy ismert tudásból indulunk ki (best practices, bevált gyakorlat)
szinte mindig laborban
A kérdés:
Sok felhasználó adataiból képzett statisztikai jellegű információból vonunk le következtetéseket.
Pl: Kérdőív, adatok elemzése, webanalítika
A kérdés:
Miért történik?
Mi történik?
Pl: felhasználói teszt, interjú
Kevés felhasználóval készített vizsgálat, mélyebb eredmények feltárására.
Ergonomics of human-system interaction, Part 210: Human-centred design for interactive systems'
alapján
6 alapelv
Kontextus
Bevonás
Érteklés
Iteratív
Teljes UX
Csapat
(a folyamatban)
A designt a felhasználó, a feladatai és a környezete explicit megértése alapján készítjük.
A tervezés és a fejlesztés teljes ideje alatt aktívan bevonjuk a felhasználókat.
A designt a felhasználó központú értékelés finomítja és viszi előre.
A folyamat iteratív.
A design a felhasználói élmény egészéről szól.
A tervező csapat tagjai multidiszciplináris tudással és perspektívával rendelkeznek.
Termék tervezési / projekt kérdés, főleg a szabványnak konkrétan nem része.
Vizsgálati módszerek
Felhasználói profilok
Perszónák
Kulcs feladatok
Koncepció modellek
Eredmények
Nem klasszikus, írott specifikáció, inkább interakciós tervek
Használat kontextusa
Követelmények a felhasználó szükségletei alapján
Követlemények szabványok, bevált gyakorlátok, irányelvek alapján
Használhatósági követelmények
Szervezeti követelmények
Tervezési módszerek
Értékelési módszerek
Irányelvek
Koncepciók
(Tervezési segítség)
Lelet analízis
Vagyis bármi, ami a szoftver használatát támogatja, de nem szerves része annak (a kézikönyv vagy egyéb dokumentáció nem tekinthető ennek), és a felhasználók közreműködésével készült.

A módszerre általános leírás nem adható, mindig a leletek tipusától függ, hogyan kell feldolgozni és hogyan lehet felhasználni az eredményeket.
A módszer lényege, hogy a szoftver (vagy eszköz) használata során keletkezett tárgyi vagy egyéb lelet1)ek (artifaktumok) elemzéséből következtet használhatósági problémára. A lelet milyenségére nincs megkötés, gyakorlatilag bármi lehet:
Keresőkifejezések egy honlapon
Cetlik a gépen
Sérülés vagy elhasználódás a felületen
Házi készítési kiegészítők
Más szoftverek használatával kombinálás
Rövíditett leírások
Puskák a használathoz
Megjegyzések
Fórum kérdések
Blog bejegyzések
Például keresőkifejezések esetén, ha egy adott kifejezésre sokan, több rokonértelmű szóval keresnek, akkor nem találják, vagy elvárják hogy arról a dologról legyen információ az oldalon. Esetleg arra is fény derülhet, hogy a felhasználók nem ismernek fel egy nem közönséges szót, és inkább rákeresnek a saját szavaikkal.
Felhasználó attitüdje
Felhasználó viselkedése
Koncepció
Konkrét
Rendszerezve
Építő blokkok
Alkalmaz
Full transcript