A design kutatás, ami megmutatja, mi folyik a szervezetedben

A design folyamat, pontosabban a design discovery a szervezeti kutatással veszi kezdetét, nem pedig a végfelhasználói interjúkkal, mint azt sokan gondolnák.

A felhasználó-centrikusság mantrája eléggé jelen van a product design világban és emiatt főként a junior designereknek esetenként eltorzul a látásmódjuk, és minden megnyilvánulásukat a usernek rendelnek alá. Ennek a téves szemléletnek a kutatás is áldozáául is eshet, azaz annak fókusza kizárólagosan a végfelhasználóra szűkülhet.

Pedig a humán-centrikusság – ami eleve jobb kifejezése a szemléletnek – azt jelenti, hogy az adott szolgáltatás minden érintettjének szükségleteit és problémáit figyelembe vesszük: nem csak a végfelhasználót, hanem a termék mögött álló stakeholdereket is kutatjuk, és ez alapján szállítjuk iteratívan az ideális megoldást. 

Sajnos még senior designerek között is akadnak, akik hangoztatják, hogy “csak a user számít”, amit rendkívül káros meggyőződésnek gondolok, ezzel ugyanis a problémát csak félig érthetjük meg, így a design megoldás sem lehet jó. 

Nem véletlenül beszélgettünk a Product Design Stories podcastben sokat mostanában kutatásokról, például Barcsi Vikivel vagy Ágoston Lacival. Éppen Laci volt, aki úgy vélekedett, hogy a felhasználó-központúság nem tud megvalósulni, ha nem kutatod le az összes érintettet (50:50-nél zajlik erről a beszélgetés):

Organisational kutatás: Minden érintett perspektívája számít

Valójában ugyanis a product design szemléletben mindenkit felhasználónak tekintünk: a terméket használó embert és a projekt stakeholdereit is. Ha ugyanis csak azokra az emberekre tekintünk júzerként, akik végül használják a terméket, nem vesszük figyelembe azokat, akiktől nagyban függ az élmény.

És ezzel el is érkeztünk az úgynevezett organisational researchöz, ami a klasszikus végfelhasználókkal végzett UX kutatások vállalatra, szervezetre formált verziója.

A design folyamat lényegében a szervezet megértésével indul, mert például ha kibukik, hogy az “evidence based” döntéshozatal nem is létezik az adott vállalatban, akkor még időben döntési ponthoz érkezünk, hogy beszállítóként tovább menjünk-e – de akkor egy masszívabb transzformációs projektben találjuk magunkat – vagy inkább hátraarcot teszünk. 

A szervezeti kontextus megértése

A design folyamatot alapjaiban meghatározza az adott cég működésének kontextusa: büdzsék, jóváhagyások, határidők, források elérhetősége, a döntéshozatal mind az adott szervezettől függenek. 

A termék végső sikere, amin dolgozunk attól függ, mennyire illeszkedik ahhoz, amit a szervezet csinál, vagy hogy egyáltalán mennyire támogatja. Ha nem érted meg a szervezetet, akkor előfordulhat, hogy egy olyan megoldással állsz elő, ami remek lenne a végfelhasználó szempontjából, de a szervezet nem tudja előállítani, nem támogatja vagy egyenesen ellenáll. 

Szerencsére minden szervezet – legyen az akár nagyvállalat, vagy startup – lényegében emberek összessége, akik meghatározott szabályokat követnek, jól körülhatárolható céljaik vannak, és adott kihívásokkal küzdenek. Ez azt is jelenti, hogy ismert kutatási módszerekkel megismerhetők. Ha megérted a helyzetüket és ezzel a szervezeti kontextust, akkor lesz esélyed jó terméket készíteni. 

Szervezeti interjúk

Talán nagy újdonságot nem fogok elárulni azzal, hogy az organisational research alapja jellemzően az interjú, pontosabban, amit a UX/product designban stakeholder interjúnak hívunk. 

Stakeholder az az illető, akinek a munkája, vagy felsősségi köre befolyásolja a projektet. A velük történő lehetőleg 1on1 interjúztatás bevett szokás a design ügynökségeknél, mely lépés voltaképpen elkerülhetetlen is, ha totál új céggel kell együtt dolgozni. 

A stakeholder interjú szabályait most mélyebben nem ismertetném, hiszen kutatási szempontból echte ugyanaz, mint a felhasználó interjú, azzal a különbséggel, hogy más a kutatás tárgya. Ugyanúgy nyílt végű kérdéseket kell feltenni, és interjúztatóként sokat kell hallgatni. 

A stakeholder interjúk során derülhet ki, hogy az egyes érintetteknek mit jelent a siker, milyen rejtett problémák vannak a szervezetben. Mégis a legnagyobb erőssége ennek kutatásnak, hogy általa mindenki szóhoz juthat.

Nem a funkciókról beszélgetünk

Ezeknek a beszélgetéseknek a célja, hogy a szervezeti kultúráról, kihívásokról, célokról, és nem pedig a funkciókról beszélgessünk, ez nagyon fontos szabály. A design területeken mi nem végzünk ún. követelmény elemzést – ami az agilis szoftverfejélesztés egy lépése – , hanem emberi problémákat értünk meg, és csak ezt követően hozunk lehetséges megoldásokat. 

Az interjúalanyunkat hagyjuk tehát bármiről beszélni, ami szűkebben vagy tágabban a scopehoz tartozik – a funkciók kivételével. A megoldás ezen a ponton még tabu, csak a szervezeti és a felhasználókkal készített kutatások után kerülhet terítékre, tehát a probléma mély megértését követően, követve a designban gyakran alkalmazott double diamond elvet:

Időnként persze nagyon nehéz leállítani egyes részvevőket, hogy funkciókról beszéljenek, de még ekkor is egy jó kérdéssel vissza kell irányítani a probléma felé.

Mire való valójában a stakeholder interjú?

Amikor ugyanarról a témakörről beszélgetsz a különböző stakeholderekkel, akkor számos választ fogsz hallani, ezáltal pedig széles körből ismerhetsz meg perspektívákat az adott szervezetről. 

Ennek köszönhetően megértheted a szervezet alapvető struktúráját, kiderülhet, ebbe miként illeszkedik a munkád, és nem mellékesen a jóváhagyási folyamatok is idejekorán kitisztulnak. 

Ugyanakkor van a stakeholder interjúknak néhány más, nem magától értődő, mégis rendkívül fontos hatása. 

Politikai semlegesítés

A legfontosabb előnye a stakeholder interjúknak politikai. Előfordulhat például, hogy az adott szervezetben valaki iszonyatosan ellenzi a munkádat. Ha sikerül kiásni, hogy miért áll ellen, megeshet, hogy végül mégis a te oldaladra tudod állítani az illetőt: erre pedig csak egy személyes beszélgetés keretében van esély.

Voltaképpen a stakeholderekkel való beszélgetés remek alkalom, hogy eladd nekik a munkádat, olyan szempontból, ami fedi az ő igényeiket. Azaz azáltal, hogy meghallgatod őket, közelebb kerülsz az elfogadtatásodhoz. 

Egyébként újdonsült in-house designerként is érdemes ezzel kezdeni a munkát, mert így kiderülhetnek időben kik az ellenzők, és idejekorán átforgathatod őket, illetve szövetségesekre is ilyen módon találsz. Úgy is szólhatna ez a tanács, hogy nagy megmondások helyett kérdéssekkel kezdj egy új szervezetben. 

Szervezeti prioritások megértése

A stakeholder interjúk révén derülhet ki projektünk prioritásának mértéke is, ami nagyon nem egy mellékes kérdés. Nagyon egyszerű a képlet, minél fontosabb egy projekt egy szervezet számára, annál sikeresebb lesz. Lehet, hogy ugyan stresszesebbek lesznek az emberek egy high prio projeken való munka során, de az is garantált, hogy igen jelentős figyelmet fognak ráfordítani. 

Design process testreszabása

A UX-es könyvekben írtaktól eltérően nagyon ritkán fordul elő, hogy egy ideális design process pörög ki. Inkább az jellemző, hogy az adott szervezetre szabottan kell felépíteni a folyamatot, használva a design thinking, design sprint etc elemeit ötvözve. 

A stakeholder interjú során ezért alaposan fel kell térképezni, hogy miként hoznak döntéseket a csapaton és a szervezeten belül. Ez különösen akkor kritikus, ha a szóban forgó projekt összekapcsol különböző cégen belüli csoportokat, vagy azokat a teameket, amelyek még nem dolgoztak együtt, vagy esetleg egy belső csapatot és egy vagy több külső szállítót.

Nem mindegy az sem, hogy milyen a döntéshozatalok formalitása: előfordulhat, hogy egyik részleg erősen együttműködik vagy konszenzusra törekszik a döntéshozatalban, a másiknak pedig autokratikus vezetője van. 

Annak megértése, hogyan hatunk a szervezetre 

Ha valami újat hozunk létre, akkor az új rendszerhez a szervezetnek is változnia kell  –  és fordítva, ezek az emberek hatással lesznek az új produktumra. Még akkor is, ha te vagy egy új termék egyetlen fejlesztője, mások részvétele esszenciális a sikerhez.

A kutatás révén kiderülhet, hogy megvan-e erre a szervezeti támogatás egységesen, esetleg áthatolhatatlan falakba ütköztél, és ennek tudatában dönthetsz a továbbiakról.

Mennyi az elegendő stakeholder interjú?

Akkor jutottál elegendő interjú adathoz, ha

• Azonosítottad az összes stakeholdert
• Feltártad a felelősségi körüket és perspektíváikat
• Kiderült, hogyan hat rájuk a közös munka sikere, vagy kudarca
• Tudod mennyi erőforrás áll rendelkezésre a projekthez
• Minden üzleti követelmény és korlát ismert
• A stakeholderek és ti egyetértésre jutottatok a siker mibenlétében
• Sikerül mérhető célokat meghatározni (enélkül a design megoldás sem mérhető)

A szervezeti kutatás kimenete

Összefoglaló doksi

Alap esetben nem igazán kell túlgondolni a stakeholder interjúk kimeneti formátumát, hiszen jellemzően ez egy belsős anyag lesz. Szóval az egyik jellemző kiment egy összefoglaló doksi lesz, amely összegzi az interjúk során látott képet. Tartalmazza a célokat, a siker mutatókat, a scopeot, összegzi a kockázatokat.

Stakeholder map

Egy másik érdekes kimenet lehet a stakeholder map, ami lényegében a projekt érdekelt feleinek azonosítására, elvárásaikat és egymással fennálló kapcsolatainak ábrázolására szolgáló technika. Jellemzően egy rövid – átlag 30 perces – workshop eredménye.

A stakeholderek azonosítása azért fontos, mert ha nem azonosítunk időben minden érintettet később az visszaüthet, például – valahol érhető módon – megfúrhatják a projektet, amin dolgozunk. 

A stakeholder mapping a kutatás előtt is megtörténhet, akkor a hipotéziseinket rakjuk ki, és a szervezeti kutatás után validáljuk. Olyan workshop variáció is lehet, hogy a kutatás előtt rakunk ki egy mapet, majd a stakeholderkkel végezzük el ugyanezt, s azt vetjük össze a mienkkel. Egyszóval számos variáció van, a projekt elején és végén egyaránt bedobható.

A lépései az alábbiak (az IBM verzióját követve):

1. Azonosítsuk az érintetteket

Először a workshop minden résztvevője minél tágabban gondolkodva valamennyi szóba jöhető érintettet írja össze – ha ismerjük a titulusukkal együtt -, akik résztvevői a projektnek.

2. Ellenőrzés

A következő lépésben nézzük meg közösen, hogy mindenki felkerült-e a táblára, aki érintett lehet.

3. Célok

Azonosítsuk, hogy melyek az egyes stakeholdeker céljai, mi motiválhatja őket.

4. Csoportosítás

Ha bizonyos stakeholderek csoportokba rendezhetők azt tegyük meg, és címkézzük fel.

5. Kapcsolatok feltárása

Nagyon fontos azonosítani, hogy mely stakeholderek – illetve csoportok – állnak kapcsolatban egymással. Azt kell nagyjából belőnünk, hogyan függenek egymástól az érintettek és miképpen interaktálnak egymással. Az erősebb kapcsolatokat célszerű vizuálisan is megjelölni, illetve akár azt is ábrázolhatjuk, ha személyek/részlegek konfrontációban állnak egymással.

6. Playback

Egy személyt kérjünk meg a workshop során, aki felolvassa a stakeholdereket, a céljaikat és egymáshoz való viszonyukat. Ezen a ponton kibukhatnak még esetleges gapek. 

7. Dokumentálás 

Az egész folyamatnak a lényege, hogy fennmaradjon a projekt során ez a map, így később is hasznos útmutatóul szolgáljon, például utólag csatlakozók számára.

Bármilyen design projekt sikerességéhez elengedhetetlen a szervezet és annak üzleti működésének alapos megértése és őszinte elemzése. A szervezeti szokások, nehézségek, igények ugyanannyira fontosak mint a végfelhasználói viselkedés, és nagyban hasonló módszerekkel kutathatók.