A lecke végére a célfelhasználót a feladat szempontjából tudod leírni, a kimondott kérést meg tudod különböztetni a mögöttes szükséglettől, és user story-t tudsz írni, amely célt és értéket rögzít, nem képernyőt. Felismered, miért veszélyes egyetlen elképzelt „átlagfelhasználóra” optimalizálni.
Miért fontos ez a brief után?
A brief megnevezte a célfelhasználót, a 2. fejezetben pedig készítettél egy personát. Itt azt vizsgáljuk meg, hogyan használjuk ezeket a tervezési döntésekben. A persona a kutatás sűrítménye; a célfelhasználó-leírás a projekt döntési szűrője; az igény és a user story pedig az a nyelv, amellyel a felhasználó céljából feladatot teszünk. A három szorosan összefügg, de más szerepet tölt be.
A célfelhasználó nem demográfiai címke
A célfelhasználó az a felhasználói helyzet vagy szereplő, akinek a feladatára a megoldást optimalizáljuk. „Első alkalommal kérvényt beadó hallgató, aki kevés ideje alatt szeretné megérteni, milyen dokumentumokra van szüksége, és fél attól, hogy elmulasztja a határidőt” már használható leírás. Kijelölheti, hogy a rendszernek egyértelműen kell kommunikálnia a követelményeket, a határidőt és a beadás sikerét. Nem jelenti azt, hogy mindenki pontosan ilyen; azt jelenti, hogy erre a nagy jelentőségű helyzetre tervezzük az első változatot.
Elsődleges és másodlagos szereplők
Egy folyamatban több embernek lehet más feladata. Az elsődleges szereplő az, akinek a fő feladatára optimalizálunk. A másodlagos szereplő olyan érintett, aki a folyamatban más céllal vagy feladattal vesz részt: például az ügyintéző, aki ellenőrzi az adatot, vagy a támogató személy, aki segítséget ad. Konfliktus esetén mondd ki, kié az elsőbbség az adott képernyőn. A hallgatói űrlap például a hallgató feladatát segíti; ettől még az ügyintéző igényét (teljes, értelmezhető adat) figyelembe kell venni.
Különböző képességek és körülmények
A célfelhasználó-leírásban gondolj az eltérő hozzáférési helyzetekre is. Van, aki telefonon, rossz hálózaton intézi a feladatot; van, aki képernyőolvasót vagy nagyítást használ; van, aki szakzsargont ismer, más pedig először találkozik vele. Nem kell minden kombinációt personává alakítani, de a kritikus kizáró feltételeket azonosítsd. Ha egy feladat csak egérrel és gyors hálózaton végezhető el, a szolgáltatás valós célközönsége szűkebb, mint gondolnánk.
Kérés, cél és szükséglet
A felhasználói igény a felhasználó által elérni kívánt érték vagy elkerülni kívánt kockázat. A felhasználó által kimondott kérés nem mindig a mögöttes igény. „Küldjetek több emlékeztetőt” mögött lehet az a szükséglet, hogy a felhasználó ne maradjon le egy fontos lépésről. Az egyik megoldás valóban lehet értesítés, de lehet határidő-naptár, folyamatállapot, előrejelzés vagy egyszerűbb feladatlista is. Ha csak a javasolt funkciót fogadjuk el, könnyen elszalasztjuk a jobb megoldást.
Három lépcsőfokot érdemes megkülönböztetni:
Szint
Példa
Megjegyzés
Kérés
„Legyen egy zöld pipa.”
Megoldásötlet
Cél
„Tudni akarom, hogy a jelentkezésem sikerült.”
Kívánt eredmény
Szükséglet
„Biztosnak lenni abban, hogy a helyem megvan, hogy ne maradjak le.”
Mögöttes érték és kockázat
Kutatásban ezért kérdezd meg: milyen helyzetben hangzott el a kérés? Mit próbált akkor elérni? Milyen következményt akart elkerülni? Milyen kerülőutat használt? A szükségletet úgy fogalmazd meg, hogy ne tartalmazza a felület konkrét formáját. „A felhasználónak biztosan tudnia kell, hogy a kérelme hiánytalan” szükséglet; a „kell egy zöld pipa” megoldásötlet.
User story: szándék, nem specifikáció
A user story rövid megfogalmazás a felhasználó szerepéről, céljáról és várt értékéről. Általános alakja:
[Szerep]ként szeretnék [célt], hogy [érték vagy következmény].
Például: „Első alkalommal ügyintéző hallgatóként szeretném ellenőrizni, hogy minden szükséges dokumentumot feltöltöttem-e, hogy ne utasítsák el a kérelmemet hiányosság miatt.” A user story nem sorolja fel a gombokat, oldalakat és adatbázismezőket. Azok későbbi megoldási döntések.
Egy jó story nem túl tág. A „hallgatóként szeretném intézni az ügyeimet” nem segít prioritást választani. Egy féléves projekthez a storyból ki kell tudni jelölni egy kezdőpontot, egy sikeres végállapotot és azokat az információkat, amelyek a döntéshez szükségesek.
Hogyan kapcsolódik a story a többihez? A kutatás megmutatja az igényt és a személyt, a story rögzíti a célt és az értéket, a sikerkritérium (1. fejezet) megmondja, honnan tudjuk, hogy teljesült, a user flow (5. fejezet) pedig lépésekre bontja. A tesztfeladatot (8. fejezet) már a story-ból és a sikerkritériumból fogjuk levezetni.
Végigvezetett példa: a Mai program célfelhasználója és story-ja
A Mai program csapata először „fiatal városlakóknak” készítene oldalt. A kutatásból azonban kiderül, hogy a fontos különbség nem az életkor, hanem a tervezési mód: egyesek spontán, aznap esti programot keresnek kevés idővel; mások hetekkel előre szerveznek társaságnak. A két helyzet más információt igényel. A spontán keresőnek az idő, helyszín és elérhetőség azonnal kell; a szervezőnek a csoportméret, lemondás és megoszthatóság lehet fontos. Egy féléves projekt válasszon elsődleges helyzetet: a csapat a spontán keresőt választja.
Kérés: „Legyen térkép!” Cél: gyorsan látni, mi van a közelben. Szükséglet: ne kelljen sokat utazni egy olyan eseményért, ami végül nem felel meg.
User story: „Spontán programot kereső hallgatóként szeretném egy listán összehasonlítani a mai eseményeket az ár, a nyelv és a jelentkezési feltétel alapján, hogy gyorsan eldönthessem, melyikre érdemes elmennem.”
Sikerkritérium (az 1. fejezet szerint): két percen belül talál megfelelő eseményt, és meg tudja mondani, kell-e előre jelentkeznie.
Gyakori tévhitek
Állítás
Pontosítás
„A persona minden részletét ki kell tölteni.”
Csak azt rögzítsd, ami tervezési döntést változtat.
„Ha a felhasználó funkciót kér, azt kell megépíteni.”
A funkció a megoldási javaslata; a mögöttes cél és akadály vizsgálata a tervező feladata.
„Az inkluzivitás külön célcsoportot jelent.”
Sok hozzáférési döntés a teljes célcsoport számára robusztusabbá teszi a feladatot.
„A user story a fejlesztési feladatlista rövid változata.”
Nem; a szándékot és értéket rögzíti, nem az implementációt.
Röviden
A célfelhasználót helyzet, cél, tudás, idő, eszköz és kockázat jellemzi, nem a demográfia.
A kimondott kérés mögött cél és szükséglet van; a szükségletet felületi forma nélkül fogalmazd meg.
Az elsődleges szereplőre optimalizálunk; a másodlagos szereplők igényeit is látni kell.
A user story szerepet, célt és értéket rögzít, nem megoldást.
Ellenőrző kérdések
Milyen helyzet teszi különösen fontossá a fő feladatot a projektedben?
Melyik funkciókérés mögött lehet más, mélyebb szükséglet?
Ki a fő felhasználó egy kiválasztott képernyőn, és ki az érintett másodlagos szereplő?
Célfelhasználó, igény és user story
Célok
A lecke végére a célfelhasználót a feladat szempontjából tudod leírni, a kimondott kérést meg tudod különböztetni a mögöttes szükséglettől, és user story-t tudsz írni, amely célt és értéket rögzít, nem képernyőt. Felismered, miért veszélyes egyetlen elképzelt „átlagfelhasználóra” optimalizálni.
Miért fontos ez a brief után?
A brief megnevezte a célfelhasználót, a 2. fejezetben pedig készítettél egy personát. Itt azt vizsgáljuk meg, hogyan használjuk ezeket a tervezési döntésekben. A persona a kutatás sűrítménye; a célfelhasználó-leírás a projekt döntési szűrője; az igény és a user story pedig az a nyelv, amellyel a felhasználó céljából feladatot teszünk. A három szorosan összefügg, de más szerepet tölt be.
A célfelhasználó nem demográfiai címke
A célfelhasználó az a felhasználói helyzet vagy szereplő, akinek a feladatára a megoldást optimalizáljuk. „Első alkalommal kérvényt beadó hallgató, aki kevés ideje alatt szeretné megérteni, milyen dokumentumokra van szüksége, és fél attól, hogy elmulasztja a határidőt” már használható leírás. Kijelölheti, hogy a rendszernek egyértelműen kell kommunikálnia a követelményeket, a határidőt és a beadás sikerét. Nem jelenti azt, hogy mindenki pontosan ilyen; azt jelenti, hogy erre a nagy jelentőségű helyzetre tervezzük az első változatot.
Elsődleges és másodlagos szereplők
Egy folyamatban több embernek lehet más feladata. Az elsődleges szereplő az, akinek a fő feladatára optimalizálunk. A másodlagos szereplő olyan érintett, aki a folyamatban más céllal vagy feladattal vesz részt: például az ügyintéző, aki ellenőrzi az adatot, vagy a támogató személy, aki segítséget ad. Konfliktus esetén mondd ki, kié az elsőbbség az adott képernyőn. A hallgatói űrlap például a hallgató feladatát segíti; ettől még az ügyintéző igényét (teljes, értelmezhető adat) figyelembe kell venni.
Különböző képességek és körülmények
A célfelhasználó-leírásban gondolj az eltérő hozzáférési helyzetekre is. Van, aki telefonon, rossz hálózaton intézi a feladatot; van, aki képernyőolvasót vagy nagyítást használ; van, aki szakzsargont ismer, más pedig először találkozik vele. Nem kell minden kombinációt personává alakítani, de a kritikus kizáró feltételeket azonosítsd. Ha egy feladat csak egérrel és gyors hálózaton végezhető el, a szolgáltatás valós célközönsége szűkebb, mint gondolnánk.
Kérés, cél és szükséglet
A felhasználói igény a felhasználó által elérni kívánt érték vagy elkerülni kívánt kockázat. A felhasználó által kimondott kérés nem mindig a mögöttes igény. „Küldjetek több emlékeztetőt” mögött lehet az a szükséglet, hogy a felhasználó ne maradjon le egy fontos lépésről. Az egyik megoldás valóban lehet értesítés, de lehet határidő-naptár, folyamatállapot, előrejelzés vagy egyszerűbb feladatlista is. Ha csak a javasolt funkciót fogadjuk el, könnyen elszalasztjuk a jobb megoldást.
Három lépcsőfokot érdemes megkülönböztetni:
Kutatásban ezért kérdezd meg: milyen helyzetben hangzott el a kérés? Mit próbált akkor elérni? Milyen következményt akart elkerülni? Milyen kerülőutat használt? A szükségletet úgy fogalmazd meg, hogy ne tartalmazza a felület konkrét formáját. „A felhasználónak biztosan tudnia kell, hogy a kérelme hiánytalan” szükséglet; a „kell egy zöld pipa” megoldásötlet.
User story: szándék, nem specifikáció
A user story rövid megfogalmazás a felhasználó szerepéről, céljáról és várt értékéről. Általános alakja:
Például: „Első alkalommal ügyintéző hallgatóként szeretném ellenőrizni, hogy minden szükséges dokumentumot feltöltöttem-e, hogy ne utasítsák el a kérelmemet hiányosság miatt.” A user story nem sorolja fel a gombokat, oldalakat és adatbázismezőket. Azok későbbi megoldási döntések.
Egy jó story nem túl tág. A „hallgatóként szeretném intézni az ügyeimet” nem segít prioritást választani. Egy féléves projekthez a storyból ki kell tudni jelölni egy kezdőpontot, egy sikeres végállapotot és azokat az információkat, amelyek a döntéshez szükségesek.
Hogyan kapcsolódik a story a többihez? A kutatás megmutatja az igényt és a személyt, a story rögzíti a célt és az értéket, a sikerkritérium (1. fejezet) megmondja, honnan tudjuk, hogy teljesült, a user flow (5. fejezet) pedig lépésekre bontja. A tesztfeladatot (8. fejezet) már a story-ból és a sikerkritériumból fogjuk levezetni.
Végigvezetett példa: a Mai program célfelhasználója és story-ja
A Mai program csapata először „fiatal városlakóknak” készítene oldalt. A kutatásból azonban kiderül, hogy a fontos különbség nem az életkor, hanem a tervezési mód: egyesek spontán, aznap esti programot keresnek kevés idővel; mások hetekkel előre szerveznek társaságnak. A két helyzet más információt igényel. A spontán keresőnek az idő, helyszín és elérhetőség azonnal kell; a szervezőnek a csoportméret, lemondás és megoszthatóság lehet fontos. Egy féléves projekt válasszon elsődleges helyzetet: a csapat a spontán keresőt választja.
Kérés: „Legyen térkép!” Cél: gyorsan látni, mi van a közelben. Szükséglet: ne kelljen sokat utazni egy olyan eseményért, ami végül nem felel meg.
User story: „Spontán programot kereső hallgatóként szeretném egy listán összehasonlítani a mai eseményeket az ár, a nyelv és a jelentkezési feltétel alapján, hogy gyorsan eldönthessem, melyikre érdemes elmennem.”
Sikerkritérium (az 1. fejezet szerint): két percen belül talál megfelelő eseményt, és meg tudja mondani, kell-e előre jelentkeznie.
Gyakori tévhitek
Röviden
Ellenőrző kérdések