A lecke végére képes leszel megoldási ötlet helyett felhasználói problémát megfogalmazni, a problémát bizonyítékra épülő feltételezésekre bontani, és olyan sikerkritériumot írni, amelyet prototípuson vagy teszten valóban ellenőrizni lehet.
Miért nem elég egy jó ötlet?
Majdnem minden tervezési munka egy ötlettel indul: „Kell egy mobilapp”, „tegyünk be chatbotot”, „legyen egy modernebb dashboard”. Ezek a mondatok természetesek, de van bennük egy csapda: megoldást neveznek meg, mielőtt a probléma ismert lenne. Ha túl korán ragaszkodunk egy megoldáshoz, a kutatás csak azt keresi majd, miért jó a már kiválasztott ötlet. Ezt hívják megerősítési torzításnak, és a csapatok nagy része ebbe esik bele. A védekezés: a megoldás helyett a problémát fogalmazzuk meg, mégpedig úgy, hogy ellenőrizhető legyen.
A megoldás nem probléma
Hasznos keret, amelyet a féléves projekt során végig használni fogsz:
[Felhasználó] [helyzetben] [célt] szeretné elérni, de [akadály] miatt [következmény] éri.
Például: „Az elsőéves hallgató tárgyfelvételkor össze szeretné hasonlítani az ütköző kurzusokat, de az időpontok több külön nézetben jelennek meg, ezért bizonytalan döntést hoz.” Ez még nem megoldás. Viszont kijelöli a vizsgálatot: tényleg ez okozza-e a gondot, kiknek, milyen gyakran, és milyen információ segítene.
A probléma elemei
A problémakeretezés a felhasználó, helyzet, cél, akadály és következmény világos megfogalmazása. Nézzük meg elemenként, miért kell mind az öt.
Felhasználó: nem „mindenki”, hanem akinek a helyzetét meg tudod figyelni. Például „elsőéves hallgató”, nem „diákok”.
Helyzet: ugyanaz az ember mást igényel akkor, amikor először tájékozódik, és mást közvetlenül egy határidő előtt. A helyzet adja a feladat kontextusát (idő, eszköz, érzelmi állapot).
Cél: a kívánt eredmény, nem a felületi művelet (az előző lecke szerint).
Akadály: ami a célt nehezíti. Ez a tervezés tárgya; ide jönnek a tartalmi, szerkezeti és vizuális megoldások.
Következmény: ez mutatja meg a súlyt. Egy félreérthető címke bosszantó lehet, egy rossz lemondási feltétel pénzvesztést vagy elveszett időpontot okozhat. A következmény segít priorizálni.
A probléma mérete is számít. „Az egyetemi ügyintézés bonyolult” igaz lehet, de egy féléves projekt számára kezelhetetlen. A „hallgató nem tudja megállapítani, kell-e még dokumentumot feltöltenie a kérvény elküldése előtt” már vizsgálható és tervezhető feladat. Ha a problémád túl nagy, szűkítsd addig, amíg egyetlen felhasználó egyetlen feladatát le tudod írni.
Feltételezések és bizonyítékok
Minden kezdeti problémakeret tartalmaz feltevést. Ez nem hiba, hiszen az elején még nem tudhatunk mindent. A hiba az, ha a feltevést tényként kezeljük. Ezért készíts feltételezési térképet: sorold fel a problémakeret állításait, és mindegyikhez írd oda, honnan származik.
Állítás
Forrás
Ha téves, mi változik?
A hallgatók telefonon keresnek programot
feltételezés
Közepes: a mobilra optimalizálás akkor is fontos, de nem a fő kérdés
Az emberek nem értik a szervezők szakzsargonját
feltételezés
Nagy: az egész navigáció és tartalom érintett
Az esemény ára a legfontosabb döntési szempont
megfigyelés
Közepes
A harmadik oszlop (kockázat) kijelöli, mit kell előbb ellenőrizni. Az a feltételezés, amelynek tévedése a teljes tervet megváltoztatná, kutatási prioritás.
A feltételezésekből később tervezési hipotézis lesz (ellenőrizhető állítás egy változtatás hatásáról); erről a 9. fejezetben tanulunk. Most elég, ha megkülönbözteted: a feltételezés még nem ellenőrzött állítás a helyzetről.
Sikerkritérium: miből tudjuk, hogy jobb lett?
A sikerkritérium megfigyelhető jel, amelyből eldönthető, elérte-e a felhasználó a célt. Miért kell előre kitalálni? Mert ha a teszt után döntünk arról, mi számít sikernek, akkor akaratlanul is a kapott eredményhez igazítjuk. A sikerkritérium a kutatás „mérőrúdja”.
Jó sikerkritérium jellemzői:
viselkedéshez vagy megértéshez kapcsolódik, nem ízléshez („legyen letisztult”, „szeressék”);
egyértelműen leírja a feladatot és a siker jelét,
lehetőség szerint a hibát vagy a ráfordítást is, például külső segítség nélkül, két percen belül.
Példák:
A résztvevő külső segítség nélkül kiválaszt egy számára megfelelő időpontot, és meg tudja mondani a lemondás feltételét.
A résztvevő első próbálkozásra helyesen tölti ki a kötelező mezőket, vagy a hibaüzenetből javítani tudja az adatot.
A résztvevő a foglalás után biztosan meg tudja mondani, hogy a foglalás létrejött-e, mikor, hol, és mi a következő lépés.
Kis kutatásnál nem kell statisztikailag általánosítható mérőszámot ígérni. Az is értékes eredmény, ha három releváns résztvevő ugyanazon a ponton elakad, és a módosított prototípusban ez az elakadás megszűnik. A fontos az, hogy az állítást a minta korlátaihoz igazítsd: „a vizsgált három résztvevő közül mindhárman…”, nem „a felhasználók…”.
Végigvezetett példa: a Mai program problémája
Kiinduló ötlet: „kell egy térképes eseményapp”. Ez megoldás. Kutatási kérdés lehet: hogyan talál a hallgató ma esti, hozzá illő programot? Tegyük fel, hogy az első beszélgetésekből kiderül: nem a helyszín hiánya a fő gond, hanem az, hogy az eseményoldalakból nem derül ki gyorsan az ár, a kezdési idő, a nyelv vagy az előzetes regisztráció.
A probléma új kerete: „A spontán programot kereső hallgató kevés idő alatt szeretné összehasonlítani a ma esti eseményeket, de a döntéshez szükséges alapadatok szétszórtan vagy hiányosan jelennek meg, ezért feladja a keresést vagy rossz programot választ.” Itt megvan a felhasználó (spontán programot kereső hallgató), a helyzet (kevés idő, ma este), a cél (összehasonlítani), az akadály (szétszórt, hiányos adatok) és a következmény (feladja vagy rosszul választ).
Ebből még nem következik, hogy térkép kell. Első prototípus lehet egy jól szűrhető lista, amelyben az összehasonlításhoz fontos adatok előre láthatók. A teszt sikerkritériuma: a résztvevő két percen belül talál saját feltételeinek megfelelő eseményt, és meg tudja magyarázni, miért felel meg neki. Ez a kritérium viselkedéshez kötött, ellenőrizhető, és a mért érték (két perc) is jelzi, hogy a sebesség valóban számít ebben a helyzetben.
Gyakori tévhitek
Állítás
Pontosítás
„Minél részletesebb a problémamondat, annál jobb.”
A részlet akkor hasznos, ha kutatható vagy döntést befolyásol. A költött háttértörténet nem bizonyíték.
„A sikerkritérium azonos a projektcélunkkal.”
A projektcél tág lehet; a sikerkritérium a konkrét tervezett feladat ellenőrzési módja.
„Ha a résztvevő megoldotta, nincs probléma.”
Figyeld a kerülőutakat, bizonytalanságot, hibákat és azt is, hogy értette-e a következményt.
„A problémakeret végleges.”
Az első verzió munkahipotézis. A kutatás után valószínűleg módosul, és ez normális.
Röviden
Megoldás helyett problémát fogalmazunk: felhasználó, helyzet, cél, akadály, következmény.
A feltételezési térkép megmutatja, mi bizonyított és mi nem, és melyik tévedés lenne a legdrágább.
A sikerkritérium előre rögzített, megfigyelhető jel viselkedésre vagy megértésre, nem ízlésre.
Kis mintánál is lehet tanulni, ha a megfogalmazás igazodik a minta korlátaihoz.
Ellenőrző kérdések
Miért nem problémafelvetés a „készítsünk letisztult felületet”?
Melyik sikerkritérium lenne megfigyelhető a saját projektedben?
Melyik feltételezésed lenne a legkockázatosabb, ha tévesnek bizonyulna?
Hogyan szűkítenéd egy túl nagy problémát egyetlen tesztelhető feladatra?
Problémakeretezés és sikerkritérium
Célok
A lecke végére képes leszel megoldási ötlet helyett felhasználói problémát megfogalmazni, a problémát bizonyítékra épülő feltételezésekre bontani, és olyan sikerkritériumot írni, amelyet prototípuson vagy teszten valóban ellenőrizni lehet.
Miért nem elég egy jó ötlet?
Majdnem minden tervezési munka egy ötlettel indul: „Kell egy mobilapp”, „tegyünk be chatbotot”, „legyen egy modernebb dashboard”. Ezek a mondatok természetesek, de van bennük egy csapda: megoldást neveznek meg, mielőtt a probléma ismert lenne. Ha túl korán ragaszkodunk egy megoldáshoz, a kutatás csak azt keresi majd, miért jó a már kiválasztott ötlet. Ezt hívják megerősítési torzításnak, és a csapatok nagy része ebbe esik bele. A védekezés: a megoldás helyett a problémát fogalmazzuk meg, mégpedig úgy, hogy ellenőrizhető legyen.
A megoldás nem probléma
Hasznos keret, amelyet a féléves projekt során végig használni fogsz:
Például: „Az elsőéves hallgató tárgyfelvételkor össze szeretné hasonlítani az ütköző kurzusokat, de az időpontok több külön nézetben jelennek meg, ezért bizonytalan döntést hoz.” Ez még nem megoldás. Viszont kijelöli a vizsgálatot: tényleg ez okozza-e a gondot, kiknek, milyen gyakran, és milyen információ segítene.
A probléma elemei
A problémakeretezés a felhasználó, helyzet, cél, akadály és következmény világos megfogalmazása. Nézzük meg elemenként, miért kell mind az öt.
A probléma mérete is számít. „Az egyetemi ügyintézés bonyolult” igaz lehet, de egy féléves projekt számára kezelhetetlen. A „hallgató nem tudja megállapítani, kell-e még dokumentumot feltöltenie a kérvény elküldése előtt” már vizsgálható és tervezhető feladat. Ha a problémád túl nagy, szűkítsd addig, amíg egyetlen felhasználó egyetlen feladatát le tudod írni.
Feltételezések és bizonyítékok
Minden kezdeti problémakeret tartalmaz feltevést. Ez nem hiba, hiszen az elején még nem tudhatunk mindent. A hiba az, ha a feltevést tényként kezeljük. Ezért készíts feltételezési térképet: sorold fel a problémakeret állításait, és mindegyikhez írd oda, honnan származik.
A harmadik oszlop (kockázat) kijelöli, mit kell előbb ellenőrizni. Az a feltételezés, amelynek tévedése a teljes tervet megváltoztatná, kutatási prioritás.
A feltételezésekből később tervezési hipotézis lesz (ellenőrizhető állítás egy változtatás hatásáról); erről a 9. fejezetben tanulunk. Most elég, ha megkülönbözteted: a feltételezés még nem ellenőrzött állítás a helyzetről.
Sikerkritérium: miből tudjuk, hogy jobb lett?
A sikerkritérium megfigyelhető jel, amelyből eldönthető, elérte-e a felhasználó a célt. Miért kell előre kitalálni? Mert ha a teszt után döntünk arról, mi számít sikernek, akkor akaratlanul is a kapott eredményhez igazítjuk. A sikerkritérium a kutatás „mérőrúdja”.
Jó sikerkritérium jellemzői:
Példák:
Kis kutatásnál nem kell statisztikailag általánosítható mérőszámot ígérni. Az is értékes eredmény, ha három releváns résztvevő ugyanazon a ponton elakad, és a módosított prototípusban ez az elakadás megszűnik. A fontos az, hogy az állítást a minta korlátaihoz igazítsd: „a vizsgált három résztvevő közül mindhárman…”, nem „a felhasználók…”.
Végigvezetett példa: a Mai program problémája
Kiinduló ötlet: „kell egy térképes eseményapp”. Ez megoldás. Kutatási kérdés lehet: hogyan talál a hallgató ma esti, hozzá illő programot? Tegyük fel, hogy az első beszélgetésekből kiderül: nem a helyszín hiánya a fő gond, hanem az, hogy az eseményoldalakból nem derül ki gyorsan az ár, a kezdési idő, a nyelv vagy az előzetes regisztráció.
A probléma új kerete: „A spontán programot kereső hallgató kevés idő alatt szeretné összehasonlítani a ma esti eseményeket, de a döntéshez szükséges alapadatok szétszórtan vagy hiányosan jelennek meg, ezért feladja a keresést vagy rossz programot választ.” Itt megvan a felhasználó (spontán programot kereső hallgató), a helyzet (kevés idő, ma este), a cél (összehasonlítani), az akadály (szétszórt, hiányos adatok) és a következmény (feladja vagy rosszul választ).
Ebből még nem következik, hogy térkép kell. Első prototípus lehet egy jól szűrhető lista, amelyben az összehasonlításhoz fontos adatok előre láthatók. A teszt sikerkritériuma: a résztvevő két percen belül talál saját feltételeinek megfelelő eseményt, és meg tudja magyarázni, miért felel meg neki. Ez a kritérium viselkedéshez kötött, ellenőrizhető, és a mért érték (két perc) is jelzi, hogy a sebesség valóban számít ebben a helyzetben.
Gyakori tévhitek
Röviden
Ellenőrző kérdések