A lecke végére különválasztod a felhasználó által elérni kívánt eredményt, a szolgáltató célját és a megoldás korlátait. Képes leszel egy konfliktust úgy leírni, hogy látszódjon: ki mit nyer, ki milyen kockázatot visel, és melyik állítás bizonyított, illetve melyik csak feltételezett.
Miért kell több nézőpont?
Az előző leckében láttuk, hogy az élmény a felhasználó céljától a következményig tart. Egy digitális termék azonban sosem csak a felhasználóé. Valaki megrendelte, valaki üzemelteti, valaki fizeti, és valaki egy régi rendszer fölé építi. Ha ezekből csak a felhasználói nézőpontot látjuk, akkor olyan megoldást tervezünk, amelyet senki nem tud kiszolgálni. Ha csak a szervezetét, akkor olyat, amelyet senki nem akar használni. A jó tervező ezért egyszerre három dolgot tart fejben: mit akar a felhasználó, mit akar a szervezet, és mi korlátozza a megoldást.
Három nézőpont, egy döntés
A felhasználói cél
A felhasználói cél nem felületi művelet, hanem a kívánt eredmény. A felhasználó nem azt akarja, hogy rákattintson a „Foglalás” gombra; azt akarja, hogy biztos időpontot szerezzen, amely belefér a napjába. A kattintás csak eszköz. A különbség azért fontos, mert ha a célt a műveletre szűkítjük, akkor a megoldások köre is szűk marad: ugyanazt a célt elérheti a felhasználó emlékeztetővel, naptárbeszinkronizálással vagy akár telefonon is.
Jó felhasználói cél tesztje: meg lehet-e fogalmazni anélkül, hogy a felületre utalnánk? „Regisztrálni az oldalra” nem felhasználói cél, mert a regisztráció egy lépés, amit a szervezet kér. „Megtudni, hogy mi van ma este a városban” az.
A szervezeti cél
A szervezeti cél (más néven üzleti cél) a szolgáltató vagy a megrendelő számára kívánatos eredmény. Lehet bevétel, de lehet kevesebb ügyfélszolgálati hívás, magasabb elégedettség, kisebb csalási kockázat vagy jobb adatminőség. Fontos, hogy a szervezeti cél legitim: egy szolgáltatásnak működnie kell ahhoz, hogy a felhasználó egyáltalán elérje. A tervező feladata nem az, hogy a szervezeti célt „legyőzze”, hanem hogy lássa, hol találkozik vagy ütközik a felhasználóéval.
Példa: a Mai program fenntartója azt szeretné, hogy minél több esemény kerüljön fel az oldalra, mert csak így lesz érdemes használni. A hallgató azt szeretné, hogy az eseményadatok pontosak legyenek. A két cél összefér, de hajlamos ütközni: ha a szervező számára túl bonyolult feltölteni az adatokat, akkor kevesebb esemény vagy hiányos adat kerül fel, amit a hallgató később hibaként él meg.
A korlát
A korlát a megoldás mozgásterét behatároló tény. Lehet technikai (egy régi rendszer csak éjszakánként frissít), jogi (adatvédelem), szervezeti (jóváhagyási folyamat), anyagi vagy időbeli. A korlát nem azonos a kifogással. A „technikai korlát” sokszor túl általános mondat, amit érdemes lebontani:
Melyik rendszer nem tud valamit?
Milyen adat hiányzik, és ki kezeli?
Meddig változtatható a folyamat, és ki dönthet róla?
Mi az a legkisebb kerülőút, ami a felhasználó számára még elfogadható?
Egy régi tanulmányi rendszer például lehet, hogy csak éjszakánként frissíti a férőhelyadatot. Ebből nem az következik, hogy a felhasználónak találgatnia kell. Lehet jelezni az adat frissességét („Utoljára tegnap este frissítve”), alternatív tájékoztatást adni, vagy a kritikus döntést megerősíteni. A korlát így a tervezési feladat része lesz, nem a vége.
Miért veszélyes a célok összemosása?
Ha egy csapat a saját mérőszámát nevezi felhasználói előnynek, könnyen manipulatív vagy csak rövid távon működő megoldást készít. Például a hírlevél-feliratkozások növelésére felugró ablakot tesz minden oldalra. Ez rövid távon több e-mail-címet adhat, de a tartalom első olvasását megszakítja, különösen mobilon vagy képernyőolvasóval.
Nem abból következik, hogy minden szervezeti cél rossz. Inkább abból, hogy a döntés hatását meg kell nevezni. Ha egy adat kötelező a szolgáltatás nyújtásához, mondd el, miért, mikor használják, és mi történik nélküle. A világos indoklás nem csak etikai kérdés: csökkenti a bizonytalanságot és a hibás adatbevitel esélyét is.
A döntési táblázat
A három nézőpont rendezéséhez használj háromoszlopos táblázatot. Az elsőben a felhasználói cél szerepel, a másodikban a szervezeti cél vagy működési igény, a harmadikban a korlát és annak forrása. Ezután minden sorhoz adj bizonyítékcímkét:
kutatási adat: valakitől hallottad vagy megfigyelted;
brief: a megrendelő írta le;
szakmai szabály: jogszabály, szabvány, bevált gyakorlat;
feltételezés: logikusnak tűnik, de nem ellenőrizted.
Ez azért hasznos, mert megakadályozza, hogy a feltételezés később tényként kerüljön a prezentációba. A Mai programnál például:
Felhasználói cél
Szervezeti cél / igény
Korlát
Bizonyíték
Gyorsan megtudni, mi van ma este
Minél több esemény legyen a rendszerben
Az események adatai több helyről származnak, nincs egységes formátum
feltételezés
Csak olyan eseményt látni, ami megfelel az árnak és nyelvnek
Pontos esemény-adatok
A szervezők nem mindig adnak meg árat
brief
Biztosan tudni, kell-e előre jelentkezni
Kevesebb lemondás
A jelentkezéseket külső rendszer kezeli
feltételezés
A „feltételezés” címkék kijelölik a következő fejezet, a felhasználói kutatás feladatát.
Végigvezetett példa: a regisztráció ára
A Mai program fenntartója szeretné, hogy mindenki regisztráljon használat előtt, mert így személyre szabott ajánlást adhat, és mérheti a kampányokat. A szervezeti cél érthető. A hallgató azonban csak azt akarja eldönteni, van-e ma este számára érdekes program. Ha minden használat előtt regisztráció áll, a feladat első lépése a legnehezebb.
A döntési kérdés ezért nem az, hogy „kell-e regisztráció”, hanem hogy melyik értékhez szükséges valóban azonosítás. A nyilvános böngészés működhet belépés nélkül; a kedvencek mentése és a jegyvásárlás kérhet fiókot. A terv így a szervezeti igényt is támogatja (a személyre szabás a mentéshez kötött), de nem teszi indokolatlanul nehézzé az első feladatot.
Gyakori tévhitek
Állítás
Pontosítás
„A több adat mindig jobb élményt ad.”
Csak akkor, ha az adat releváns, az előnye érthető, és a kérés arányos a helyzettel.
„A korlát miatt nincs tervezési döntés.”
A korlát kijelöli a mozgásteret; a felhasználó felé közvetített állapot, magyarázat és kerülőút továbbra is tervezhető.
„A szervezeti cél és a felhasználó érdeke mindig ellentétben áll.”
Sokszor ugyanaz a jó feladatbefejezés – például a pontos foglalás – szolgálja mindkettőt. A konfliktust azonosítani kell, nem feltételezni.
„A felhasználói cél az, amit a felhasználó kér.”
A kért funkció gyakran megoldási javaslat. A cél mögötte van (erről a 4. fejezetben lesz szó).
Röviden
A felhasználói cél kívánt eredmény, nem felületi művelet.
A szervezeti cél legitim, de nem azonos a felhasználóéval; a konfliktust meg kell nevezni.
A korlát a tervezési feladat része; bontsd le, ki, mit és meddig tud változtatni.
A bizonyítékcímkék (kutatási adat, brief, szakmai szabály, feltételezés) megvédenek attól, hogy a feltételezés ténnyé váljon.
Ellenőrző kérdések
Miért nem felhasználói cél a „regisztrálni az oldalra”?
Milyen kérdésekkel bontható le egy homályos technikai korlát?
Mondj példát olyan szervezeti célra, amelynek lehet nem kívánt felhasználói következménye.
Melyik állítás a projektedben feltételezés, amelyet kutatással vagy egyeztetéssel kellene ellenőrizni?
Felhasználói cél, szervezeti cél és korlát
Célok
A lecke végére különválasztod a felhasználó által elérni kívánt eredményt, a szolgáltató célját és a megoldás korlátait. Képes leszel egy konfliktust úgy leírni, hogy látszódjon: ki mit nyer, ki milyen kockázatot visel, és melyik állítás bizonyított, illetve melyik csak feltételezett.
Miért kell több nézőpont?
Az előző leckében láttuk, hogy az élmény a felhasználó céljától a következményig tart. Egy digitális termék azonban sosem csak a felhasználóé. Valaki megrendelte, valaki üzemelteti, valaki fizeti, és valaki egy régi rendszer fölé építi. Ha ezekből csak a felhasználói nézőpontot látjuk, akkor olyan megoldást tervezünk, amelyet senki nem tud kiszolgálni. Ha csak a szervezetét, akkor olyat, amelyet senki nem akar használni. A jó tervező ezért egyszerre három dolgot tart fejben: mit akar a felhasználó, mit akar a szervezet, és mi korlátozza a megoldást.
Három nézőpont, egy döntés
A felhasználói cél
A felhasználói cél nem felületi művelet, hanem a kívánt eredmény. A felhasználó nem azt akarja, hogy rákattintson a „Foglalás” gombra; azt akarja, hogy biztos időpontot szerezzen, amely belefér a napjába. A kattintás csak eszköz. A különbség azért fontos, mert ha a célt a műveletre szűkítjük, akkor a megoldások köre is szűk marad: ugyanazt a célt elérheti a felhasználó emlékeztetővel, naptárbeszinkronizálással vagy akár telefonon is.
Jó felhasználói cél tesztje: meg lehet-e fogalmazni anélkül, hogy a felületre utalnánk? „Regisztrálni az oldalra” nem felhasználói cél, mert a regisztráció egy lépés, amit a szervezet kér. „Megtudni, hogy mi van ma este a városban” az.
A szervezeti cél
A szervezeti cél (más néven üzleti cél) a szolgáltató vagy a megrendelő számára kívánatos eredmény. Lehet bevétel, de lehet kevesebb ügyfélszolgálati hívás, magasabb elégedettség, kisebb csalási kockázat vagy jobb adatminőség. Fontos, hogy a szervezeti cél legitim: egy szolgáltatásnak működnie kell ahhoz, hogy a felhasználó egyáltalán elérje. A tervező feladata nem az, hogy a szervezeti célt „legyőzze”, hanem hogy lássa, hol találkozik vagy ütközik a felhasználóéval.
Példa: a Mai program fenntartója azt szeretné, hogy minél több esemény kerüljön fel az oldalra, mert csak így lesz érdemes használni. A hallgató azt szeretné, hogy az eseményadatok pontosak legyenek. A két cél összefér, de hajlamos ütközni: ha a szervező számára túl bonyolult feltölteni az adatokat, akkor kevesebb esemény vagy hiányos adat kerül fel, amit a hallgató később hibaként él meg.
A korlát
A korlát a megoldás mozgásterét behatároló tény. Lehet technikai (egy régi rendszer csak éjszakánként frissít), jogi (adatvédelem), szervezeti (jóváhagyási folyamat), anyagi vagy időbeli. A korlát nem azonos a kifogással. A „technikai korlát” sokszor túl általános mondat, amit érdemes lebontani:
Egy régi tanulmányi rendszer például lehet, hogy csak éjszakánként frissíti a férőhelyadatot. Ebből nem az következik, hogy a felhasználónak találgatnia kell. Lehet jelezni az adat frissességét („Utoljára tegnap este frissítve”), alternatív tájékoztatást adni, vagy a kritikus döntést megerősíteni. A korlát így a tervezési feladat része lesz, nem a vége.
Miért veszélyes a célok összemosása?
Ha egy csapat a saját mérőszámát nevezi felhasználói előnynek, könnyen manipulatív vagy csak rövid távon működő megoldást készít. Például a hírlevél-feliratkozások növelésére felugró ablakot tesz minden oldalra. Ez rövid távon több e-mail-címet adhat, de a tartalom első olvasását megszakítja, különösen mobilon vagy képernyőolvasóval.
Nem abból következik, hogy minden szervezeti cél rossz. Inkább abból, hogy a döntés hatását meg kell nevezni. Ha egy adat kötelező a szolgáltatás nyújtásához, mondd el, miért, mikor használják, és mi történik nélküle. A világos indoklás nem csak etikai kérdés: csökkenti a bizonytalanságot és a hibás adatbevitel esélyét is.
A döntési táblázat
A három nézőpont rendezéséhez használj háromoszlopos táblázatot. Az elsőben a felhasználói cél szerepel, a másodikban a szervezeti cél vagy működési igény, a harmadikban a korlát és annak forrása. Ezután minden sorhoz adj bizonyítékcímkét:
Ez azért hasznos, mert megakadályozza, hogy a feltételezés később tényként kerüljön a prezentációba. A Mai programnál például:
A „feltételezés” címkék kijelölik a következő fejezet, a felhasználói kutatás feladatát.
Végigvezetett példa: a regisztráció ára
A Mai program fenntartója szeretné, hogy mindenki regisztráljon használat előtt, mert így személyre szabott ajánlást adhat, és mérheti a kampányokat. A szervezeti cél érthető. A hallgató azonban csak azt akarja eldönteni, van-e ma este számára érdekes program. Ha minden használat előtt regisztráció áll, a feladat első lépése a legnehezebb.
A döntési kérdés ezért nem az, hogy „kell-e regisztráció”, hanem hogy melyik értékhez szükséges valóban azonosítás. A nyilvános böngészés működhet belépés nélkül; a kedvencek mentése és a jegyvásárlás kérhet fiókot. A terv így a szervezeti igényt is támogatja (a személyre szabás a mentéshez kötött), de nem teszi indokolatlanul nehézzé az első feladatot.
Gyakori tévhitek
Röviden
Ellenőrző kérdések