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 alapjai

BME Szoftver-ergonómia, 20130220 és 20130227
by

Péter Balázs Polgár

on 28 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of A szoftver-ergonómia alapjai

A szoftver-ergonómia alapjai Szoftver ergonómia - Az ember (=felhasználó) hogyan tud egy adott szoftvert használni Miért rosszak a mai programok:
Ijesztők (pl.: technikai zsargon)
Félrevezető kérdések (pl.: Word mentés)
Hiba üzenetek (pl.: „Hiba történt. OK?”)
Programozók irányítani akarnak, felhasználók használni (pl.: átrendezhető menü)
Felesleges funkciók (pl.: körlevelet ki használta?) Felhasználói részvétel fontossága Termelékenységnövelés elérhető: 30% eszközök, 300% emberek miatt Emberi tényezők szerepe A szoftver-ergonómia tárgya Társ területek Tervezési modellek Többféle módszertant is létrehoztak ezen problémák kezelésére: Eleinte nem számítógépes irányultságú, inkább épített környezet (1960-as évektől)
Az emberek jogára épít, hogy részt vehessenek az őket érintő, munkájukat befolyásoló döntésekben
A felhasználók részt vesznek a tervezésben
A designerek inkább tanácsadók („advisor”)
Szociális tényezőket is figyelembe vesz
Modern formája: crowdsourcing (elosztott PD) a felhasználók IT-kal kapcsolatos ismeretei hiányosak
kommunikációs problémák (a szakértőknek és a felhasználóknak nincs „közös nyelve”)
intellektuális nehézségek (absztrakt gondolkodás: elképzelni a rendszer jövőbeni működését, „elővételezni” az új követelményeket)
„hostage situation”: a felhasználó nem akar buta kérdéseket feltenni – passzív magatartás Bár programozók indították, de…
Sok közös pont van az agilis és a felhasználót bevonó modellek között
Jó a gyors iteráció (van alkalom a felhasználókkal egyeztetésre, együttműködés)
Az utóbbi 2-3 évben közeledik a két közösség (közös konferenciák, beszélgetések)
Az UCD-n belül is van már agilis megközelítés
Azonban nincs direkt hivatkozás a felhasználóra (megrendelő nem az!) Agilis és felhasználók Inkább filozófia, mint konkrét módszertan (sokféleképpen megvalósítható)
Nemcsak szoftverre, hanem bármire jó
A lényeg: a tervezés középpontjában az ember van, akinek a termék készül
Az ember szükségleteire épít, nem próbálja meg a termékhez „idomítani”
Ehhez nemcsak analizálni kell, mire van szükség, hanem a felhasználókkal ki is kell próbáltatni (-> iterációk) Milyen feltételek mellett jelentős elsősorban a közvetlen participáció hatása?
…ha a projekt mérete viszonylag kicsi;
…ahol a felhasználók ismeretei lényegesek a sikeres megvalósításhoz;
…olyan szervezetben, ahol az egységesség („uniformity in design”) nem követelmény;
…ha a szervezetben egy bizonyos fokú konszenzus van a projekt céljait illetően; Participáció hatásossága Az egyént és a személyes kommunikációt, a módszertanoknál és az eszközöknél.
A működő szoftvert, az átfogó dokumentációnál.
A megrendelővel való együttműködést, a szerződéshez való ragaszkodással szemben.
A változásra való reagálást, a tervek rigorózus követésével szemben....
Noha, fontosak az utóbbiak is, mi fontosabbnak tartjuk az előzőeket. Agilis szoftverfejlesztés kiáltvány A felhasználók igényei alapján döntenek
A felhasználók tevékenységét vizsgálja
Felhasználók a vizsgálatok tárgyai

Passzív részvétel
Autokratikus(abb) A felhasználók részt vesznek a döntésben
A felhasználók véleményét meghallgatja
Felhasználók partnerek a tervezésben
Aktív részvétel
Demokratikus(abb) vs Irányelvek, esetleg egyszerű módszerek (interjú)
Egy vagy több módszer rendszeres alkalmazása
Önálló folyamat (egyenrangú vagy alárendelt a szoftveres fejlesztésnek)
A fejlesztés UCD alapú
A termék létrehozása UCD alapú Szoftver-ergonómia projektben Jogszabályok, szabványok Használatra (ISO 9126 részei, ISO 20282)
Felületre és kezelésre (ISO 9126 részei, ISO 9241, ISO 14915, ISO 18021…)
Dokumentáció (ISO 18019, ISO 15910)
Fejlesztés (ISO 13407, ISO 16982)
Érettség (ISO 18529)
Speciálisak (ISO 62366)
Vannak még nem ISO-k is, pl.: ANSI vagy EU-s Vonatkozó szabványok „A szoftver feleljen meg a feladatnak”
Magyar betűk
„A szoftver legyen könnyen használható”
Magyar súgó
A dolgozók tudomása nélkül nem vehető igénybe mennyiségi vagy minőségi ellenőrzés
„Alkalmazni kell a szoftver-ergonómia elveit” 3. rész: Ember-gép kapcsolat Az intelligens termékekhez kapcsolódó jogszabályok:
European directive No. 90/270/EEC (1990)
Health and Safety (Display Screen Equipment) Regulations 1992 (HSE, UK)
50/1999. EüM rendelet Kapcsolódó jogszabályok Szoftver minőség dimenziók Ergonomic requirements for office work with visual display terminals (VDTs) — Part 11: Guidance on usability Definíció ISO 9241-11 A szoftverek minőségének termék-szempontú megközelítése:
A részletekbe menő irányelvek szintjén:
ergonómiai elvek (ISO 9241)
a szellemi munkaterhelés ergonómiai alapelvei (ISO 10075)
multimédia felhasználói felületek ergonómiai elvei (ISO 14915)
Szoftverminőség (ISO 9126)
A minőségkövetelmények kiértékelése (ISO 14598) Szofterg és minőség 1. rész: Berendezések
(képernyő, billentyűzet, munkaasztal, szék)
2. rész: Környezet
(pl. világítás, klíma, zaj)
3. rész: Ember-gép kapcsolat Melléklet az 50/1999. EüM rendelethez A rendelet hatálya kiterjed mindenkire, aki legalább napi 4 órán keresztül képernyős eszközt használ
Példa a szigorú előírásokra: Max. napi 6 óra, óránként min. 10 perces, össze nem vonható szünetekkel
2001. január 1-től az új képernyős munkahelyekre, 2001. december 31-től a régiekre is… 50/1999. EüM rendelet Használhatóság (Usability): a jellemzők azon összessége, amelyet a használathoz szükséges erőfeszítés mértéke, illetve felhasználók által arról kialakított értékelés határoz meg.
Érthetőség (Understandability): az erőfeszítés …, hogy megértse a rendszer logikáját.
Tanulhatóság (Learnability): az erőfeszítés …, hogy megtanulja a rendszer logikáját.
Üzemeltethetőség (Operability): az erőfeszítés ..., hogy működtesse a rendszert és a működést ellenőrizze. 6.3 Használhatóság ISO/IEC 9241: Képernyős terminállal végzett irodai munka ergonómiai követelményei
Az 1992-ben megjelent szabványt 1996-98 közt bővítették ki a szoftverekre vonatkozó részekkel, majd 2001-ben megújították.
Részei: 12. rész: információmegjelenítés
(információszervezés, grafikus objektumok, kódok)
13. rész: a felhasználót segítő eszközök (ált. elvek, prompt, visszajelzések, állapotinf., hibakezelés, súgó)
14. rész: menü-alapú interakció
15. rész: parancsnyelven alapuló interakció
16. rész: közvetlen manipulációs interakció
17. rész: űrlapkitöltésen alapuló interakció 1. és 11. rész: áttekintés
2. rész: munkafeladatok
3. rész: képernyő (hardver)
4. rész: billentyűzet (hardver)
5. rész: munkahely-elrendezés
6. rész: környezet
7. rész: képernyőn való tükröződések (hardver és környezet)
8. rész: színek (hardver)
9. rész: egyéb beviteli eszközök (hardver)
10. rész: a dialógus alapelvei ISO/IEC 9241 Interakció tervezésének elvei 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) UCD + módszerek 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 Szoftver-ergonómia 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
sirpepe@elte.hu
@polgarp http://thedailywtf.com/Articles/Enterprise-Dependency-The-Next-Generation.aspx Erre gondolunk... ... ezt kapjuk. Iteratív! Felhasználó részvétel A viselkedést nézzük, nem amit mondanak A tervező nem a felhasználó Miért foglalkozunk szofterg-gel? 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 Környezet, helyszín,
kapcsolat Megismerjük Elemezzük Tervezzük
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 Cél, feladat,
tevékenység A szoftver-ergonómia nem programozás.
A szoftver-ergonómia nem design. Nem Hanem Használhatóság = (ISO 9241-11:1998 Definition 3.1) Használhatóság = SzoftErg User Experience (felhasználói élmény?) Program tervezés (computer science) Pszichológia Design Hogyan hozzunk létre szoftvereket, rendszereket? Mit tudunk létrehozni? Milyenek az emberek? “Amikor a technika a tevékenységi szükségleteknél többet elégít ki, figyelembe véve a szubjektív, helyzetfüggő, komplex és dinamikus használatot akkor UX-ről beszélünk.
felhasználó belső állapota (pl.:, hajlamok, elvárások, igények, motiváció, hangulat, stb),
a design jellemzői (pl.: bonyolultság, cél, használhatóság, funkcionalítás, stb.
a kontextus (vagyis a környezet) ahol az interakció megvalósul (pl.: szervezeti, társasági helyzet, az aktivitás értelme, a használat önkéntessége, stb.”
(Hassenzahl & Tractinsky) 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." http://www.usabilitynet.org/tools/methods.htm Módszerek a UsabilitNet.org-n „Why user participation necessary?”
(Washington Post, 2007. január 3., http://www.washingtonpost.com/wp-dyn/content/article/2007/01/03/AR2007010300941_pf.html) Informatikusokat kevésbé érdekli a felhasználó (az ő szakmája a számítógép)
A rendszereket a tervezők gondolkodása határozza meg
A technikai rendszerek az egyszerűbb feladatokat automatizálják, a nehezek maradnak a felhasználóknak Szervezeti problémát emberek oldhatnak meg, nem számítógépek Folyamat: Szervezet: Technika: DE: Leendő felhasználók bevonása nehéz Mérhető, tesztelhető, részletes és az üzleti igényeknek megfelelő tevékenységek Lean UX - az agilis fejlesztéshez Felhasználó központú (User centered design, UCD) Participatív tervezés (Participiatory design, PD) Követelmény analízis (Requirements analysis, RA) http://www.agilealliance.hu/ Projekt méret, pénz, szaktudás és elkötelezettség (filozófia) is befolyásolja (pedig inkább szükség alapján kéne…) Nielsen 8 lépcsős érettségi modellje:
http://www.useit.com/alertbox/maturity.html (1-4)
http://www.useit.com/alertbox/process_maturity.html (5-8) Érettség A minőségbiztosítás általános szabványai:
ISO 8402 (Minőség és minőségbiztosítás – szakszótár)
ISO 9000-es szabványsorozat
ISO 90003:2004 útmutató: az ISO 9001-es szabvány szoftverfejlesztésre való alkalmazása A szoftverek minőségének folyamat-szempontú megközelítése:
Szoftveréletciklus-folyamatok (ISO 12207)
Rendszeréletciklus-folyamatok (ISO 15288)
Emberközpontú szoftveréletciklus-folyamatok (ISO 18529)
Felhasználó-központú tervezés a teljes életciklus során (ISO 13407)
A szoftverfolyamatok közül a mérési folyamatok (ISO 15939)
A szoftverfolyamatok értékelése (ISO 15504) „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.” 3.1 usability: Extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. Empirikus Analítikus 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... ROE (1988) - Action Facilitation Approach 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). usability inspection:
heurisztikus módszerek, irányelv vizsgálat, bejárási technikák…
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)
labor usability testing
használhatósági teszt, környezeti vizsgálat, megfigyelés…
alkalmazása során 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 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 Felhasználó viselkedése Felhasználó attitüdje 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: Tervezés Értékelés
Full transcript