Gépélmény

Régen rossz, ha egy szakma képviselőjeként azt kell bizonygatnom, hogy amit csinálok az igen is szükséges és hasznos. A használhatóság még kevésbé közismert terület, bár a közelmúlt új eszközei, különösen az Apple termékei sokat tettek azért, hogy ismert legyen a használhatóság fogalma, és végre az emberek meg tudják fogalmazni, hogy mi a bajuk egy adott honlappal, azon kívül, hogy nem felhasználóbarát.

Az itthoni cégeknél mostanában kezdődött el egy olyan átalakulás, amikor az értéket termelők köre kezd bővülni a sales+programozó csoportból a vezetők fejében és már felmerül, hogy kell külön tesztelő, követelmény író és adott esetben használhatósági szakember.

Három axióma kezdésképpen:

1. Nem a felhasználó a hibás. (Legjobb esetben is a szoftver design.) Akinek van egy minimális üzleti gondolkozása, annak ezt nem kell magyarázni, az ügyfélnek mindig igaza van, azt szeretnénk ha ő megvenné a mi szolgáltatásunkat / szoftverünket / használná a weboldalunkat / vásárolna a webshopunkban. Ha ezt nem tudja megtenni, akkor nem ő a hibás, hogy nem találta meg a megfelelő gombot, hanem mi, hogy rossz helyre tettük.
2. Felhasználó nem fejlesztő.  A józan paraszti ész híveinek szokott nehezére esni ezt elfogadni, de sajnos csak nagyon ritka esetekben igaz. "A feleséged/párod/anyukád programozó? Ő ezt így megértené? Pedig ő még ügyesebb is számítógépes dolgokban, mert a Te hozzátartozód..."
3. A használhatósági szakértő kompetenciája adott. Talán ezt a legnehezebb megemészteni, ne hagyjuk hogy megkérdőjelezzék a hozzáértésünket. Bár én is igyekszem egyetemen tanítani, a használhatóságnak ma Magyarországon nincs formális képzés, ezért aki ezzel foglalkozik, túlnyomó részben önképzéssel és munkatapasztalattal jutott ide. (Itt felvetődhet a hozzá-nem-értők-de-magukat-eladni-tudók esete, akik a mindenki hitelét rontják béna elemzéseikkel és a felületet rontó javaslataikkal. Ennek az axiómának a lényege, hogy ha már az én szakmai kompetenciáim megkérdőjelezéséről van szó, pl. hogy nem tudok egy tesztből szignifikáns eredményt felmutatni akkor már valami nagyon kisiklott.)

Használhatóság a termékfejlesztésben
Üzleti szempontból szerintem van a köze a kockázatkezeléshez két szempontból:

• Felhasználói igények kiszolgálása: a használhatóság segít, hogy a célcsoportnak megfelelő legyen a szoftver, az ő igényeihez igazodjon. Eszköztára segít a tényleges követelmények feltárásában, rögzítésében, osztályozásában, fejlesztésre alkalmas hozásában, követésében, végül a további hibák feltárásában.
• Fejlesztési idő jobb becslése: ha van egy csatornánk, amiben a felhasználó igények lefordítódnak a fejlesztők nyelvére (pl.: kész UI tervekkel) akkor nincsenek felesleges körök a "nem ezt akartuk"-kal. Így elkerülhető a teljes bukás is (ami végső soron a szoftver újraírását eredményezi, duplázva, triplázva az időt).

Végül a felhasználóknak megfelelő szoftvert szívesebben veszik meg, sikeresebb lesz a piacon. Ma már a használhatóság selling point.

Magában a termékfejlesztési folyamatban a használhatóság kezdetektől fogva jelen lehet, jelen kell lennie már a koncepció megalkotásakor. Ezzel elkerülhetőek a későbbi meglepetések is, pl. koncepcionális problémák.

Fontos megjegyezni, hogy a használhatóság önmagában nem garantálja a jó terméket, nem ad útmutatást új termék kitalálására, az innovációra, csak a javításra (innovate vs. improve). Henry Ford mondta: "Ha megkérdeztem volna az embereket, hogy mit szeretnének, azt mondták volna, hogy gyorsabb lovakat."

Végül ha mérnökkel kell tárgyalni, érdemes megemlíteni, hogy a szoftveres szabványok ma már mind említik a használhatóságot (pl. az ISO 9126-ban a szoftver 6 minőségi jellemzője közül az egyik).

ROI mérése
Hogyan lehet mérni az üzleti megtérülést? Előtte utána lemérjük az üzleti eredményesség szempontjából fontos értékeket. Például:

• Call centernél a lényeg, hogy minél gyorsabb legyen a kiszolgálás. Mennyi idő a gyakori műveletek elvégzése a régi és az új szoftveren?
  (Idő különbség)*(Művelet gyakorisága)*(Hívás költség) = Eredmény
• Webshopnál: Vásárlások száma, átlagos költés száma
• Weblapoknál: konverziók száma
• stb.

A lényeg, ez a mi érdekünk is, előre határozzuk meg, hogy mi az üzleti cél és azt hogyan mérjük.

És végül ha bárki kétkedik a használhatóság szerepében, csak szótlanul mutass fel egy iPhone-t. (Esetleg kérd meg, hogy 5 percig használja, és azután szerinte tényleg csak a marketing miatt lett jobb.)

Kellemes karácsonyi megleleptés, hogy a közeljövőben két, érdekesnek igérkező alkalommal is hallhatunk usability-ről.

MeetOFF az Ergonómiáról és használhatóságról

Az első a MeetOFF szervezésében, kifejezetten rövid és talán kicsit prögösebb előadások, és (talán a környezet miatt is) több beszélgetési lehetőség az előadókkal és egymással.

Előadók: Bognár Katalin, Kollin Zoltán, Pataki Máté, Polgár Péter Balázs, Pónya Judit, Rung András, Szatmári Elemér.

A témákról előzetesen itt olvasható összefoglaló: http://meetoff.eu/.

Hely és idő: december 28, este 7, Gold center.

Ide talán azért is érdemes lesz eljönni, mert a #twitterkari is itt lesz, úgyhogy az est második részében némi partizás várható.

Schmidt Zoltán: A usability alapjai

A Docler Akadémián rendszeresen vannak előadások mindenféle web fejlesztős témakörben, ezúttal a használhatóságról lesz.  Másfél órás alapozó jellegű előadásnak néz ki.

Hely és idő: január 4, este fél 7, Docler irodaház.

A címben szereplő kérdés talán az egyik leggyakrabban feltett a használhatóság témakörében, pedig ökölszabály és jó néhány kutatás is van a témában. Rung András a legutóbbi Ergomániás posztjában (Teszteld a honlapod, hogy működjön!) le is írja ezt: "Minimum 4 emberre van szükségünk, de 8-10-nél nem kell több". Szerintem érdemes kicsit a mélyére tekinteni honnan is jönnek ezek az értékek.

Kezdetnek egy gyors megjegyzés. Minden ilyen esetben az x darab felhasználó kellően különböző felhasználói kategóriánként (csoportonként) értendő. Azaz ha a rendszerünknek (weblapunknak) van 3-4 jól elkülöníthető felhasználói csoportja, akkor csoportonként kell x ember - nem összesen. (Azzal együtt, hogy a fontosabb csoportokra így is érdemes több időt és energiát áldoznunk.)

A legismertebb, 5 felhasználós szabály Nielsen-től van, több mint 10 éve jelent meg cikke: Miért kell csak 5 felhasználóval tesztelni?. Érdekes, hogy az általa bemutatott összefüggés szerint 15 felhasználóval már az összes használhatósági hiba kiszűrhető, mégis a több és kisebb (3 körös, körönként 5-5 felhasználó) tesztet javasol. A több körben iteratívan tesztelhetőek a javított design-ok, így elkerülhető hogy javítás eredményeképpen még nagyobb hibák keletkezzenek.

A Measuring the User Experience is lényegében ezt az eredményt hozza ki némi matekozás után, azonban megemlít két fontos feltételt:

1. A teszt terjedelme legyen korlátozott. Vagyis tetszőleges méretű termékre, weblapra ennél több felhasználó kell. Az 5 akkor elég, ha 5-10 feladat van, és a tesztelt mennyiség 20-30 oldal.
2. A célcsoport legyen jól meghatározott és a teszten résztvevő felhasználók között jól reprezentált. Ez utal arra, hogy több csoport esetén csoportonként kell ennyi felhasználó (ezt Nielsen is írja). Itt nehéz lehet eldönteni, hogy kik tartoznak egy csoportba.

Faulkner cikke már kifejezetten tudományos szempontból közelíti meg a kérdést pont az 5 felhasználós szabályt vizsgálva. A közölt számítások egyértelműek: bár továbbra is a rendszertől, a feladatoktól és felhasználóktól (tehát a kontextustól) függ a felhasználók száma, azonban az 5 felhasználó nem elég. 5 és 10 között jelentős növekedés tapasztalható a kimutatott hibák számában, és kb. 20 felhasználó környékén kerül 95% felé a megtalált hibák száma. Ezzel együtt a konklúzió az, hogy minél több felhasználóval kell tesztelni, minél jobban meghatározott felhasználói csoportokból.

Zárszóként még annyit, hogy (Rung András szavaival) jelenleg a magyar piac ott tart - használhatóság terén - mint az US 2003-ban. Ez azt is jelenti, hogy mivel inkább még a használhatóság elfogadtatása a fontos, Nielsen használhatóság félpénzen elve egy ideig még fontosabb lehet - azaz itthon továbbra is az olcsó(nak számító) 5 felhasználós szabály ami praktikusan alkalmazható.

Ha visszatekintünk a felhasználói felülettípusok kialakulására , akár úgy is tekinthetjük hogy valami fejlődés zajlik, amit például az alábbi Wikipédia ábra is sugall:

Sőt, ezt a fejlődési folyamatot gyakran a szakmában is hangoztatják, mondván a parancssoros megközelítés rosszabb használhatósággal rendelkezik, mint a grafikus felhasználói felület. Ez persze nem igaz, hiszen a használhatóság definíciójából következik, hogy használhatóság csak adott kontextusban értelmezhető.

Ezért írok most egy rövid áttekintést a három fő típusról, illetve a CLI és GUI kombinációjáról, ami egyes kontextusokban nagyon jó használhatóságot eredményez.

CLI, GUI, NUI

Parancssoros felhasználói felület (Command Line Interface, CLI)

Aki nem az elmúlt években találkozott számítógéppel, esetleg nem csak Windows-t használ szinte biztosan találkozott már ezzel.A felhasználó parancsokat gépel be, amit a gép értelmez, végrehajt, majd jó esetben felel valamit.

A CLI-k kialakulása a számítástechnika hőskorához köthető, ekkor a gépek korlátozott képességei miatt nem is nagyon volt lehetőség másfajta kezelésre.

Használhatósági szempontból előnyük, hogy

• gyakorlott felhasználók nagyon gyorsan és hatékonyan tudnak vele dolgozni,
• ismétlődő feladatokat végezni illetve
• mind fejlesztői, mind felhasználói szempontból nagyon rugalmas.

Hátránya viszont

• a meredek tanulási görbe,
• rendkívül alacsony a felfedezhetőség (új parancsok megtanulása) és
• jelentős kognitív a terhelés a felhasználón (pontos mentális modell, terv stb. kell).

Szerencsére a kezdeti idők óta sokat változtak a CLI-k a felhasználókat segítő lehetőségek terén, pl.: automatikus kiegészítés, színes kiemelés, a parancs történet (history) kezelése.  A grafikus kezelők fejlődésével a szemet kevésébe megterhelő megjelenítés is lehetővé vált mára (szemben a régi rendszerekkel).

Szintén nagyon sokat fejlődött a parancsok értelmezése, ezáltal sokkal jobban tolerálva az ember hibázásokat.

Grafikus felhasználói felület (Graphical User Interface, GUI)

Manapság a legelterjedtebb típus, különösen a WIMP (Window, Icon, Menu, Pointer) paradigma miatt. A mostani szempontunkból a webes felhasználói felületet (WUI) is ide sorolhatjuk, bár sok tekintetben jelentős különbségek vannak a GUI-hoz képest.

A GUI használata során a felhasználó elsősorban az egeret (vagy más hasonló eszközt) használ, a képernyőn lévő elemek (gombok, ablakok, menük) segítségével végzi a feladatát.

Használhatóság szempontjából az előnye hogy

• nem az emlékezetre (rememberability) hanem a felismerésre (recognizability) épít,
• könnyen tanulható (mert a feladathoz kapcsolódó szavak egyből látszanak).

Hátránya, hogy

• gyakorlott felhasználók számára lassú,
• jó felépítéshez jelentős fejlesztői erőforrások kellenek (pl.: prototípusok stb.)

Természetes felhasználói felület (Natural User Interface, NUI)

NUI-ról beszélhetünk ha nincs egér, billentyűzet vagy más közvetett beviteli eszköz, hanem a felhasználó közvetlenül, pl.: végtagjai segítségével irányítja a számítógépet, adott esetben felhasználói felület nélkül.

Az elmúlt években kezdődtek meg a kutatások olyan eszközök iránt, amelyek semmilyen előzetes tanulást nem igényelnek, a felhasználó különösebb tanulás nélkül azonnal használni tudja az eszközt.

A mutli-touch készülékek (pl. iPhone) egy fontos lépés a NUI-k irányában (pl.: a gesztus vezérléssel), de ezek nagyrészt még mindig a régi GUI elemeit használják.

Használhatósági értékük még nem tisztázott, viszont nagyon is alkalmasak nagyon jó felhasználói élmény biztosítására, hiszen a számítógép ebben az esetben semmilyen korlátot nem állít.

Azt gondolom, hogy a közeli jövőben egyre több ilyen eszközt és főleg alkalmazást fogunk látni, amire jelzés az XBox Kinect sikere is.

Vannak további típusok is (pl.: Zoomable User Interface, Tanglible User Interface - ezek jelentősége, elterjedtsége korlátozottabb).

CLI+GUI

A CLI (jellegű interakció) és GUI összeforrasztása bizonyos alkalmazásokban jelentősen növeli a használhatóságot, még a kevésbé gyakorlott felhasználóknál is. Két példát tudok erre mondani:

1. A böngészők URL sávja, ahol a www címek bepötyögését fokozatosan felváltotta a kereső mezővel való kombinálás. Például a Chrome omnibar-ja is ilyen, és további alkalmazások is elérhetőek ilyen formán. (Én pl. a Twitterezésre is egy ilyen add-ont használok, a Twitterbar-t).
2. A Remember the Milk feladat hozzáadó mezője is értelmezhető CLI-ként, néhány paranccsal kombinálva egész bonyolult feladatokat is könnyen, lassító kattintás nélkül be lehet vinni.

Mindkét esetben egy GUI-n lévő mezőbe gépelünk, de többféle információt, amelyet egy intelligens értelmező fordít a megfelelő parancsra. A gépelés miatt a használat gyors, az értelmező segít a parancsok felismerésében (pl.: megmutatja a lehetőségeket) ezáltal építve a recognizability-re. Az olyan prediktív listák, mint amilyet a Google Instant használ tovább segítenek a sok lehetőség közti választásban, és ez a megoldás a klasszikus GUI-ban csak nehézkesen valósítható meg.

Tanulság: Egyrészről az egyes felhasználó felület típusokat a helyükön kezelni, van amire egyik, van amire másik típus alkalmasabb. Másrészről bizonyos alkalmazásokban előnyös több típus kombinálása.

Tegnap voltam egy előadáson: Vitályos Gábor: Használhatóság - egy új szakterület, egy kis beszámoló róla.

Bevallom a cím és a tartalom alapján volt bennem egy enyhe előítélet. Bár akadnak definiálási problémáink, de a használhatóság fogalma és a szemlélete elég jól meghatározott, illetve a szoftveres részen is 40-50 éves múltra tekintve (nem is beszélve a tágabb értelemben vett információ ergonómiáról), ezért kicsit meglepő a cím. Végül mondhatnám, hogy nem csalódtam, de ne szaladjunk előre.

Az előadást én három fő gondolati részre bontanám: volt egy bevezető rész az előadás scope-járól ezután példák végül a "Usability Reference Model" mint megalapozás jellegű. Bár a meghívóban volt szó legújabb kutatások bemutatásáról, erre végül nem került sor.

Eredetileg készítettem gondolati térképet az előadásról de tekintve a téma "érdekes" megközelítését inkább csak pár megjegyzést írnék le.

Scope. Elhangzott egy felosztás rutinfeladatokra és nem rutinfeladatokra, illetve ez utóbbit tovább osztotta "Populáris világra" és "Professzionális világra" mondván, hogy nem foglalkozik a rutinfeladatokkal (mert a modell nem vonatkozik rá) és a populáris világgal (mert ez kevésbé fontos). A rutinfeladatokra azt mondta, hogy ezek közé tartozik pl az orvosi rendszerek, vagy repülés szerelés, beépített rendszerek. Itt már kicsit meglepődtem, lévén pont azokban a rendszerekben kiemelten fontos a használhatóság, ahol biztonsági kockázat és emberi interakció van, konkrétan minden orvosi felhasználás ilyen. Kifejezetten szigorú szabványoknak kell megfelelni használhatóság részéről, amennyiben az ember egy orvosi terméket akar piacra dobni, hogy az emberi hibázás lehetősége minimalizálva legyen.

Ami a populáris (szabadidős), professzionális (nem szabadidős, pl.: közszolgáltatások) világot illeti, még ha egyet is értenék hogy a szoftver termékeket lehet és értelmes e szerint felosztani akkor sem tudom elfogadni, hogy a populáris alkalmazásoknál nem kell használhatóságról beszélni, hiszen ahol azt szeretnénk hogy más emberek is használjanak valamit (akár üzleti érdekből, akár lelkesedésből hozunk létre valamit), ott van helye a használhatóságnak. Sőt tágabb értelemben a használhatóság, mint az emberi minőség növelése minden élethelyzetben elérendő cél.

Az elektronikus közszolgáltatások terén katasztrofálisak a használhatósági viszonyok - ebben legalább egyetértünk. Ugyanakkor szerintem azt is látni kell hogy a sokkal mélyebb, rendszerszintű problémák és funkcionális hiányosságok vannak amikkel előbb meg kéne küzdeni (elég csak a magyarorszag.hu helyzetére gondolni, a kockablog rendszeresen beszámol róla, de ide tartozhat Rung András múltkori posztja, "Sci-fi marad az ergonomikus önkormányzati honlap?" ).

Példák. A példák nem voltak túl jók, inkább csak néhány kiragadott részlet, amelyek egy-két irányelvet sértettek meg (pl.: nincs tooltip, rossz színek stb.). Ráadásul hiányzott az a gondolkozás, hogy mi a célja ennek a honlapnak, pl.: egy iskolai honlap esetén valóban lehet "ügyfelekről" beszélni. (Pont az iskolai honlap kapcsán hangzott el az, hogy bár a gyerekek értik, de nem jól átlátható bárkinek. Ha az iskola honlapjának az a célja, hogy a gyerekeknek közöljön információkat, és a gyerekek átlátják, akkor nincs probléma, hiszen mindenkinek nem lehet tervezni.)

Modell. Először is a fogalomról. Referencia modellt többnyire rendszermérnökök szoktak készíteni, amelyhez képest történik a konkrét megvalósítás. Természetesen a használhatóság esetén is beszélhetünk modellről, de nagyon fontos hogy ezek a modellek mindig tartalmazzák az embert, mint alrendszert, hiszen a használhatóság mindig csak a használóval együtt értelmezhető. (Modellekről, szemléleti keretekről: Dr. Izsó Lajos, Dr. Antalovics Miklós: Bevezetés az információ-ergonómiába, BME, 2000, 5-14. oldal). Más használhatósági modellek inkább folyamat szemléletűek és a megvalósításra koncentrálnak (pl. a képesség-érettség modellek). Végül a használhatóságról beszélhetünk, mint egy minőségi keretről, mint a szoftver/rendszer minőség részéről (ISO 9126). Ennek fényében egy pusztán rendszermérnöki, elemeket tartalmazó keret elhibázottnak tűnik (és nem mellesleg én még nem találkoztam olyan szakirodalommal amiből hiányzott volna az emberi tényező, de legalábbis a használó adott környezetben történő értelmezése).

Ami magát a modellt illet a névből következően is elsősorban a rendszer elemeiről szólt: adatok, adatstruktúrák, munkafolyamatok. (Az olyan apróbb tévedésekről, mint az érzékelés és észlelés összetévesztése nem írok.) Ami a modell felépítésénél leginkább szembement az uralkodó használhatósági gondolkozással, az a felépítés iránya. Az ember-központú tervezés, és általában bármelyik hasonló módszertan először az emberi hasznosságot vizsgálja, majd ezután építi fel a rendszer további elemeit (a kezelőfelülettől kezdve), míg a bemutatott modell alulról indult, és a rendszer atomi elemeiből építette fel az egész rendszert. Azt gondolom ez a rendszerek tervezésnek egy jó megközelítése, de ugyanakkor a használhatóságot nem lehet részekből felépíteni. Úgyis mondhatnám, hogy az emberi tényező megköveteli (legalább részlegesen) a holisztikus szemléletet. Pusztán használható oldalakból nem következik, hogy az egész weblap használható lesz.

Talán ezért, az emberi tényező szerepe miatt sem készült eddig ilyen (elem alapú) referencia modell, a szakterületen elterjedt minden megközelítés inkább a folyamat alapú, hiszen minden felhasználó, feladat és környezet más, nem lehet egy általános modellnek megfelelni, csak az adott körülményekhez megfelelő design-t létrehozni. Ez az használhatóságban megjelenő iteratív gondolkozás alapja is.

Zárszóként nem sajnálom, hogy tegnap elmentem erre az előadásra, érdekes volt látni egy erősen rendszermérnöki megközelítését a használhatóságnak. Ugyanakkor nem látom, hogyan lehetne az ott elhangzottakat akár a napi munka, akár a kutatás-fejlesztés során hasznosítani.

Ha valami elkezd megjelenni a mainstream képregényekben is, akkor biztosak lehetünk benne, hogy az a valami immáron a szélesebb nyilvánosság előtt is ismert fogalom, sőt egyenesen a popkultúra részévé kezd válni.

Az egyik legutóbbi Vasemberben (Iron Man: Titanium #1) látható az alábbi jelenet:

A hős Vasember éppen a robotikus roszfiúkat lövöldözi halomra. Eközben titkárnője, Pepper Pots habfürdőzik és a rosszfiúktól elvett okostelefonnak látszó tárgyal próbál meg főnöke segítségére sietni. És itt hangzik el a megjegyzés: "Pillanat... a rosszfiúk programozóinál láthatólag nem élvez elsőbbséget a felhasználó barátság." (Bezzeg ami8ket mi szoktunk használni.) A végén (de legalábbis a négy részes sorozat utolsó számára) persze minden jóra fordul, rosszfiúk legyőzve, előre a végtelenbe és tovább.

Az egész sztoriból két tanulságot is levonhatunk: egyrészről a szuperhősök által írt és használt programok felhasználóbarátak, míg a rosszfiúk programjai nem. És mivel a a szuperhősök (végül mindig) legyőzik a gonoszokat, ezért azt is kimondhatjuk, hogy a jó használhatóság végül legyőzi a rossz használhatóságot. Másrészről ez mutatja a használhatóság értékét: a jóknak be kell fektetni, ha végül győzni akarnak.

Bár most csütörtökön volt a a használhatóság világnapja, a magyar közösség szerdán találkozott a Menta teraszon.

A tavalyi sörözéshez képest kicsit komolyabbra vettük a figurát, voltak előadások is. Inkább azt mondanám, hogy ezek izelítőt nyújtottak a résztvevőknek, de egyértelműen lejött, hogy mindenki több ilyet szeretne van igény a kapcsolatépítésen túl a szakmai információk megismerésére.

A szervezésre kicsit több időt és energiát szántunk, talán ezért is volt a tavalyinak majdnem háromszorosa a részvétel.

Néhány szóban az előadásokról szigorúan szvsz.

1. Polgár Péter Balázs: A használhatóság keretei
A saját előadásomat inkább nem méltatnám. A lényeg az volt, hogy egyrészről adjak egy olyan keret amiben mind a teljesen kezdők, mind a haladók jobban el tudják helyezni a fogalmakat. Másrészről a sokféle job description között is akartam egy kicsit rendet tenni. Mókás volt, hogy utána beszélgetés közben egyszerre mondták érthetőnek és bonyolultnak.

2. Judit Pónya: Ne azt add, amit kérek, hanem amit szeretnék
A másik alapozó elődás: ki kell ismerni a felhasználó szándékát ha sikeres használhatóságot szeretnénk.

3. László Vecsei : Üzleti célok és használhatóság az e-kereskedelemben
Szerintem ez és a következő előadás adhatt a legtöbbet azoknak, akik még soha sem foglalkoztak használhatósággal és most szeretnék kiegészíteni az internetes / szoftveres tevékenységüket ezzel. Még így is, a ROI számítás örök téma marad a használhatóságban.

4. Rung András: Jelentős eladási hatékonyságnövelés néhány nap munkával 
Egy konkrét példa végigmutogatva, a tanulság hogy kell és megéri használhatósággal foglalkozni. Volt egy fontos mondat, ami segít felmérni a magyar helyzetet: ott tartunk, mint a US 2003-ban - ez nekem azt mutatja, hogy még van bőven lehetőség a használhatóság terén.

5. László Laufer: Affordanciák a Preziben
Az affordanciák egy mélyebb, de jól megfogható téma. Szerintem érdekes volt hallani, hogy egy szokásostól eltérő interakciós felületen hogy javítják a használhatóságot az alapelveket jól alkalmazva.

6. Csilla Herendy: Tesztelési lehetőségek a website fejlesztése során
Kicsit túl tág téma volt a használhatósági fejlesztési ciklushoz képest, jó lett volna többet hallani az egyes módszerek előnyéről és hátrányáról. Kicsit hiányzott az is, hogy lesznek a teszt eredményekből érdemi előrelépések, amik viszik előre a folyamatot.

7. Katalin Fehér: Mire használhatók az online közvetített közösségek?
A használhatósághoz közvetlenül nem kapcsolódik a social media, azonban egyre fontosabb színtérnek bizonyul, ami jelentősen kihathat az egyéb szoftver és informatika fogyasztási szokásokra. Tetszett benne a gondolat a konfirmálásról, azaz hogy egyes baráti körökben már csak akkor létezünk, ha fent vagyunk az FB-n.

8. Dávid Udvardy: Perszónák használata az Autodesknél
A perszónák szerintem izgalmas téma, főleg hogy hallhattunk némi információt a felépítésükről is, ami nem igazán triviális. Kicsit lehetett volna több információ a perszónák menedzseléséről (pl az integrálás a bug tracking system-be), ha már megemlítésre került.

9. Csilla Almásy: Hardver amortizáció és megelőzése
Kicsit meglepő volt ("Én laptop helyett gerincsérvet hoztam"), de jó is volt, hogy volt egy kis kitekintés a szoftveres világból. Azért is jó volt, mert ennek az előadásnak valódi hatása volt a résztvevőkre: amikor Csilla a helytelen tartásról beszélt, kicsit mindenki kihúzta magát.

A tegnapi World Usability Day alkalmából tartottam előadást, ráadásul az a megtiszteltetés is ért, hogy a bevezető, tehát a "magyarázós" előadást én tarthattam.

Diák + mondanivaló hozzá:

 Az előadás célja, hogy egyrészről egy gondolati keretet adjon a használhatóságról, amiben gondolkozni lehet a témáról, másrészről hogy tisztázza néhány kapcsolatos fogalom helyét.

Nagyjából ezek a fogalmak fedik le a tágabb értelemben vett területet, bár van közös részük, lényegében ugyanarra utalnak: olyan felületre, tervezésre, amiben a felhasználónak, az embernek nagy szerepe van. Bár sokféle meghatározás és definíció létezik mindegyikre, ebben az előadásban inkább egy keretre húzzuk rá őket, így megpróbálva a viszonyaikat tisztázni.

Induljunk ki egy elég általános helyzetből: van egy termékünk, amit el szeretnénk adni, egy koncepciónk, amit meg szeretnénk valósítani. Bár a téma többnyire informatikai problémákkal kapcsolatban merül fel, szeretném hangsúlyozni, hogy a módszerek és elvek korántsem csak itt értelmezhetők.

A legfontosabb a termékhez vagy koncepcióhoz, hogy legyen egy célcsoport, aki azt majd használni fogja, és fizetni fog érte. Itt szándékosan használtam a „Felhasználó” szót a „Vásárló” helyett, szerintem ez egy optimistább nézőpont, hogy amit csinálunk, azt valaki ténylegesen is használni fogja, nem csak megvenni. Ez a fenntarthatóbb üzleti modell is.

Kicsit továbbgondolva, a „Felhasználó” szót kijavítanám „Emberre”. A használhatóságnak mindig is volt egy kicsi humanisztikus íze, ahogy az embert a középpontba helyezzük. Ugyancsak ide tartozik, hogy az ügyfélre velünk egyenrangú félként tekintünk (vagy pedig ő csak a felhasználó 1.0). Ez kicsit több, mint ha csak a felhasználóról beszélnénk, a jól megtervezett termékek fenntarthatók és többet is nyújtanak, mint a felhasználásra alkalmasságot. Funkcionális egyezőség esetén ez lesz az a plusz, ami miatt egyik vagy másik termék mellett dönt a vásárló.

Persze az ember nem csak egy dimenziós lény. Van személyisége, gondolatai, céljai, fizikai és kognitív jellemzői, amelyek befolyásolják hogyan viszonyul a világ dolgaihoz. Ezeket a termék tervezésekor figyelembe kell venni. Triviális példa: ha nem vesszük figyelembe az ember átlagos testméretét, akkor nem tudnánk neki széket vagy akár autót tervezni: vagy túl nagy lenne, vagy el sem férne benne. Hasonló dolgok vannak a szoftveres rendszereknél is, bár itt a kognitív jellemzők kevésbé kézzelfoghatók.

 Az embert körbe veszik további emberek, akikkel interakcióban van, illetve van egy fizikai világ, egy környezet amiben él. Ettől sem tekinthetünk el. Bizonyos megoldások működnek környezetben (pl.: otthon), de nem működnek máshol (pl.: az utcán).

 Ha felsorolt jellemzőket felmértük, akkor jöhet a termék és koncepció tényleges megvalósítása. Ez egy rendszer lesz, ami megfelel az igényeknek és elképzeléseknek mindkét oldalról.

 A rendszert tovább bonthatjuk részekre: szoftver és hardver, ezek jól ismert fogalmak. A szolgáltatások tartalmaznak mindent, ami nem az előbbi kettő: pl.: támogatás, adott esetben bérlés, az eladási csatornák, az üzleti modell. Végül van egy negyedik komponens, ezt jobb híján stílusnak neveztem el. Ez az a része a rendszernek, ami az érzéseket közvetíti a termékkel kapcsolatban, így ez meglehetősen szubjektív, nehezen megfogható, ugyanakkor jelentősen hozzájárulhat egy termék sikeréhez.

 Ha megvan a rendszerünk, szeretnénk ha azt a felhasználó ténylegesen is használná, ezért készítünk hozzá be és kimeneti csatornákat. Ha kicsit visszatekintünk a rendszerre, látható egy piros keret a rendszer rész elemei között. Ez a rendszer interfésze, amihez a ki és bemeneti csatornák csatlakoznak. Amikor az ember a rendszerrel interakcióban van, akkor ezt az interfészt látja. Ez azt is jelenti, hogy hiába jó a rendszer belseje, ha az interfész nem kielégítő, a felhasználónak nincs készsége / ideje / kompetenciája, hogy a dolgok mélyére nézzen. Ha a szándékainak, céljainak megtestesülését látja az interfészen, akkor elégedett lesz, egyébként nem.

Sajnos a négy rész (ember, rendszer, be és kimenet) eltérő nyelvvel rendelkezik: a felhasználó gondolatai, a be és kimenet csatornái, végül a rendszer más nyelven beszél, esetenként a részeken belül is vannak további (al)nyelvek (bár pl.: a rendszer belső nyelvei: hardver és szoftver, üzlet közti tolmácsolást ideális esetben végrehajtják a rendszer készítői). Ahhoz, hogy az egyes részek közti kommunikáció működőképes legyen fordítani kell, a jeleket meg kell feleltetni egymásnak. Ha ez a fordítást, a nyelvek egyeztetése jól működik, a rendszer meg fog felelni az embernek. Ez a megfelelés egyúttal azt is jelenti, hogy termék jó lesz.

A kezdeti fogalmakhoz, részterületekhez itt lehet visszacsatolni: az egyes részrendszerek közt a tolmácsolást a különböző diszciplínák végzik el. Mindegyiknek van része az interfészen is (itt utalunk arra, hogy pl. a hardver és szoftver közti fordítást is el kell ugyan végezni, de ez a technikai kollégák feladata), és ezáltal kis és bemeneti csatornák felé is.

Természetesen a rendszer jellegétől függően ezek tartalmazások máshogy is nézhetnek ki. A lényeg ott van, hogy melyik fordítási kapocs mivel foglalkozik inkább.

Még egy fontos dolog, amit a rajz kifejez: bár a diszciplínák kapcsolódnak az emberhez, de mégis inkább az interfészre koncentrálnak. Ez azért van, mert az embert csak nagyon ritkán és nagyon nehezen és drágán van esélyünk megváltoztatni (pl. fizikai jellemzőknél ez a változás is csaknem lehetetlen, de a tréningek, képzések hatásossága is kérdéses weboldalak esetén egyenesen kivitelezhetetlen). Éppen ezért a felhasználóktól nem várhatjuk el, hogy változzanak, csak a rendszerre tudunk koncentrálni, csak azt tudjuk megváltoztatni.

Amikor az ember kezdőként elvégzi az első használhatósági tesztjét esetleg elgondolkozik rajta, hogy akkor most mit csináljon az előtte lévő hatalmas kupac papírral, ráadásul a menedzsment többnyire a háta mögött toporog, hogy fel kéne mutatni valami eredményt, ha már egyszer időt és pénzt fordítottak a tesztekre.

Egy másik jellemző momentum az szokott lenni, amikor a GUI tervezők bent ülnek egy meetingen, amikor valaki megszólal "Rossz a használhatósága a szoftvernek, tervezzétek újra".

Mindkét esetre igaz, hogy mérni kell a használhatóságot, a teszteket és az elvárásokat lefordítani valamilyen számszerű értékre, hiszen amit nem tudunk mérni, az nincs is. Itt jönnek be a használhatósági metrikák

Korábban már írtam a Measuring the User Experience című könyvről, ami szerintem alapmű e téren. E könyv főbb gondolatait azóta egyetemi előadás formájába is feldolgoztam, és beépítettem az ELTE-s előadások közé. Íme:

A tavalyi évhez hasonlóan idén is találkozni fognak - fogunk, hogy a magyar színtéren is megemlékezzünk a használhatóság napjáról.

A tavalyi eseményhez képest kicsit szakmaibb szinezete is lesz a dolgonak, nem csak sörital közös elfogyasztása a cél, hanem rövid (max 5 perc, tehát tényleg kibírható) előadásokat is tervezünk.

Tavalyhoz hasonlósan idén is van játék, a köznap életből jó és rossz használhatóságú dolgokat lehet gyűjteni, majd A használhatóság napja Facebook oldalára feltölteni. Nyeremény: használhatósággal kapcsolatos könyvek az Akadémiai Kiadó és a HVG Könyvek jóvoltából .

Szerintem megéri benézni, kicsit beszélgetni ha érdekel a terület, és kiváncsi vagy egy kis magyar ki kicsodára.

Idő: 2010. november 10. · 18:00 - 22:00
Helyszín: Menta Terasz fedett kerthelyiség (Margit krt. 14. II. ker.)
Facebook: http://www.facebook.com/WUDhu
Twitter: #wudhu2010