Milyen az ideális UX érintettségű projekt?

Az alábbi írás designereknek és projektgazdáknak is szól. Előbbinek segít a UX érintettségű projektek egészét átlátni és mankót nyújt, utóbbinak pedig segít megérteni a részfolyamatok szükségességét, mivel gyakori, hogy “húzni kell a projekten”, így számos fontos rész, illetve szakasz kimarad.

Az utóbbi években szerencsére egyre több vállalat von be a projektjeikbe UX szakértelmet kisebb-nagyobb sikerrel, hol házon belüli kompetencia alkalmazásával vagy kiépítésével, hol pedig külső csapat segítsége révén, viszont sokszor kimaradnak a jelentős lépések ahhoz, hogy megfelelő produktumot, illetve szolgáltatást adjunk ki a kezünkből és elégedett célközönségünk / végfelhasználónk legyen.

Na de vegyük is sorra, milyen egy ideális UX projekt.

Felmérések, brief, módszerek

Ideális esetben egy projekt indulásakor felmérjük az alábbiakat: projekt életképessége, kivitelezhetősége, ütemezés, stb. Meghatározzuk a projekt céljait és, hogy mit szeretnénk elérni (KPI-ok), kik lesznek a felhasználóink és ki a célcsoport, miért van szükség az adott termékre / szolgáltatásra, miért lehet jobb a mi termékünk / szolgáltatásunk, mint másoké, mit várunk a projekttől (pl. használható-e, mi számít sikernek, stb.). Fontos, hogy a projekt kezdetekor és a tervezés végén is megvizsgáljuk a projekt életképességét (Viability).

Akkor születik meg egy optimális projekt, ha az üzlet (Stakeholder) képes kollaborálni és kompromisszumokat kötni a tervezői csapattal. Pl. ha az szükséges, akkor élesedjen a projekt később.

A briefben meghatározandóak az alábbiak, a teljesség igénye nélkül (természetesen mindig az adott projektre szabva, nem kötelező érvényű az alábbi lista):

• Projekt scope: új termék / meglévő termék
• Mi a projekt MVP-je, ami által az adott szolgáltatás/termék piacra bocsátható?
• Mi a projekt tervezésén belül a UX szerepe?
• Ki írja a szöveget (UX copy)? Ki validálja? Hogyan bizonyosodunk meg a közérthetőségről?
• Ütemezés alapos összeállítása és feladatok idejének felmérése (frusztrációk elkerülése), belső határidők összeállítása
• Hol van a helye az adott év roadmap-jén a projektnek?
• Fel kell mérni, hogy a kívánt technológia rendelkezésünkre áll-e, esetleg megvalósítható, mennyi idő van rá, stb. Ezekhez a fejlesztői csapat bevonása elengedhetetlen.
• Milyen átalakításokat igényel a projekt megvalósítása?
• Van-e szabad erőforrás a kivitelezéshez? Illetve mikor?
• Van-e a projektnek anyagi kockázata?
• Szükség van-e új / külső eszköz / technológia beszerzésére? Ha igen, mi az indok rá, illetve milyen alternatívák lehetnek?
• Vannak jogszabályi előírások? Ha igen, mik azok?
• Hogyan illeszthető a meglévő rendszerbe a projekt?
• Milyen szervezeti egységek érintettek?
• A projekt mit ad a felhasználóknak, milyen előre vélt hatással lesz rájuk?
• Hogyan szerzünk user feedbacket a projekt tervezése során?
• Milyen op. rendszerre optimalizálunk?
• Van-e böngésző verzió amit figyelmen kívül hagyunk?
• Tárolunk-e adatokat? Hogyan védjük azokat? Hogyan lesz biztonságos?
• Hogyan kezeljük a hibákat?

Részletes információt és anyagot a témában ebben a cikkemben találsz :)

Alap- és tervezési elvek (másnéven Design Principles)

A brief, illetve a kutatások, felmérések után érdemes ezeket meghatározni, hiszen a teljes szolgáltatás / termék fejlesztése során végigkíséri a csapatot:

Alapelvek, ami a termék/szolgáltatás kulcs funkcióit határozzák meg, segítenek a döntések meghozatalában és iránymutatást adnak, melyekhez érdemes folyamatosan vissza nyúlni a projekt folyamán.

Ezek lehetnek pl: a hangvétel (tone of voice) meghatározása, bizonyos megoldások (design és technológiai) előnyben részesítése, bizonyos felhasználók előtérbe helyezése, stb.

Termék-, üzleti-, illetve a felhasználói előnyök meghatározása is elengedhetetlen ezen szakasz során.

A tervezők célja az elégedett felhasználó, míg az üzletnek többnyire a profit, a kiszámíthatóság, az időben való projekt indulás, stb., a fejlesztőknek pedig a megfelelő kód. Az igényeket fontos összhangba hozni, hogy az érdekek ne ütközzenek, és ne sérüljön a projekt, nem szabad(na) egyik területet sem mellőzni a döntések meghozatalában.

A projekt során fontos hangsúlyozni, hogy a folyamatos iteráció elkerülhetetlen (nem ér véget a projekt > visszamérések > iterációs körök).

Scrum módszertan használata: legyenek sprintek, squadokban dolgozzunk, meglegyenek a szerepkörök, stb. Ezáltal csökkentjük a projekt kockázatokat és biztosítjuk, hogy a megfelelő részfeladatokon dolgozzunk, elkerülve a kommunikáció hiányát és a félre kommunikálást.

Probléma meghatározás és brand pozícionálás

Mi a probléma-meghatározás?

A probléma-meghatározás, más néven “problem statement / problem definition maga a probléma, feladat, kihívás tiszta meghatározása. Azon kihívások összefoglalása, melyekkel meg kell küzdeni a tervezés során.
A probléma azonosítása során a kutatásból kinyert fájdalompontok, kielégítetlen felhasználói igények felismerésére és megértésére összpontosítunk.
Legfontosabb célja, hogy az egész csapat figyelmét egy helyre összpontosítsa, és közös alapot hozzon létre, mely hivatkozási alap lehet egy tervezés során. Ezekre a választ kutatási eredmények alapján tudjuk megadni.
Ahhoz, hogy a csapat megoldási javaslatokkal, lehetőségekkel, tervekkel álljon elő, először biztosan és egyértelműen érteniük kell a problémát. A probléma-meghatározást úgy kell megfogalmazni, hogy minden csapattag átláthassa a probléma összes lehetséges oldalát, és hogy mindannyiukat ösztönözze a megoldás keresésére. A jó probléma-meghatározás egyesíti a csapatot, és hitelesen mutatja be a felhasználók problémáit, valamint 1–3 mondatban leírható.

Mi a brand pozicionálás?

A probléma-meghatározást segítheti vagy kiegészítheti a “brand positioning statement”, ami egy mondatban összefoglalja a tervezett termék célját és szerepét. Kérdéses esetekben mindig rá lehet nézni erre a mondatra ami segít eldönteni amin gondolkodunk fontos-e a cél szempontjából. Pl: A [projekt neve] olyan [típusa], ami [kulcs-funkciók megjelölése] azoknak a [célközönség]-nek, akik [szükséglet vagy lehetőség meghatározása].

A Double Diamond modell / Módszer

Ugye a Design Thinking problémamegoldásra fekteti a hangsúlyt, melyben technikailag alkalmazza és hasznosítja a meglévő ismereteket, valamint az innovatív megoldásokat. Problémákból és igényekből indulunk ki, melyekre megoldásokat keresünk. Főbb lépései a Double Diamond modellként elterjedt „útmutatóban” találhatóak meg.

A Double Diamond (magyarul dupla gyémánt, de az angol kifejezést szoktuk használni) egy design tervezési módszertan, ami szerencsére egyre több helyen alkalmazott. A módszer első kettőse arra szolgál, hogy a megfelelő design-t tervezzük meg, míg a másik fele arra, hogy azokat jól tervezzük meg!

Forrás: researchgate.net

Röviden az alábbiakat tartalmazza:

• Discover (felmérés) – kutatások, igényfeltárások
• Define (Meghatározás) – Projekten belüli szükségletek meghatározása
• Develop (Fejlesztés) – Koncepció, iterációs körök, megvalósítás (design tervek)
• Delivery (Átadás) – prototípusok elkészülése, fejlesztőknek átadandó anyagok, stb.

Számos jó szakcikk fellelhető a módszerről, érdemes rákeresni.
Szintén eltérő változatai lehetnek a cég működési mechanizmusától függően, alább két saját ábra található a témában.

Projekt folyamatok (saját ábra)

Projekt folyamatok (saját ábra)

Kutatás célja és szerepe a UX folyamatokban

A kutatások a megfelelő (felhasználói és üzleti) igények feltárása mellett a célcsoport fájdalompontjainak meghatározásában segítenek. Ez a szakasz elengedhetetlen a megértéshez, ám sokszor találkozunk sajnos azzal, hogy az üzleti területek ezt a szakaszt meg akarják spórolni a megfelelő információ hiányában (hogy ez mire is való, miért jó a projektnek, miért jelentős lépés, „van szakemberünk, tehát mindent tudunk a felhasználóinkról ugye”, stb.). Természetesen itt is fenn áll, hogy nem minden projekt esetében van módunk egy ideális kutatási szakaszra, ám a később felsorolt módszerek némelyikét mégis bevethetjük a megfelelő tovább lépéshez.

Maga a UX kutatás célja, hogy mélyen megértsük az üzleti és felhasználói igényeket és a célcsoportunk, felhasználóink viselkedését. Magában foglalja a felhasználókról, viselkedésükről, motivációikról és fájdalompontjaikról történő megfigyelést és adatgyűjtést.

Segítségével validálhatjuk és priorizálhatjuk az azonosított problémákat és biztosítani tudjuk, hogy a megoldások valós felhasználói igényeken alapuljanak és tervezési döntéseink felhasználó-központúak legyenek.

Fontos, hogy a kutatás kezdeti szakaszában meghatározzuk a kutatási célt, összeállítsunk olyan kérdéseket, amikre válaszokat szeretnénk kapni, illetve meghatározzuk a konverziós pontokat is (események, ahol valami fontos történik és valamilyen hatást generál). Célszerű a felvetéseinket és a projekt limitációit is összeszedni (pl. akadályok az interjúalanyok toborzásában).

A kutatási szakaszban érdemes az alább felsorolt megoldások mellett az aktuális trendeket is feltérképezni.

Kutatási típusok / módszerek:

• Kvalitatív & kvantitatív kutatás

Nem mindegy, hogy a mérések üzleti céllal nagy mintából táplálkoznak de kevésé mélyre hatóan, vagy pedig kis mintában, de alaposabban a viselkedésekről, élményekről, stb.

Kvalitatív kutatási módszer segítségével mélyebb betekintést lehet tenni az adott téma/kérdéskör felé, feltérképezhetjük a felhasználók gondolkodásmódját, motivációit. Az eredménye, hogy válaszokat kapunk a miértekre, hipotéziseket tudunk állítani belőle, értelmezzük és pontosítjuk a problémát, meghatározhatjuk az egyéni fájdalompontokat és igényeket, stb.
Kvalitatív kutatások kiértékelésénél az összefüggések keresésén van a hangsúly. Az interjú / fókuszcsoportos megbeszélés is ilyen, esetleg a kérdőív is beletartozhat a kérdések függvényében. Kvalitatív kutatás továbbá történhet személyesen vagy írásban is. Önmagában csak a múltbeli értékekről tudunk eredményt kapni, visszamérések és elemzések tekintetében hasznos lehet, de önmagában kevés.

Kvantitatív kutatás során a számszerűsített, meglévő statisztikai adatokra hagyatkozunk, melyekből mennyiségi eredményeket nyerhetünk ki, és akár néhány kattintással lekérhetjük a meglévő felületünkből (pl: Google Analytics). Megtudhatjuk pl. a látogatói forgalmat, az átkattintási, visszafordulási arányokat, mérni tudjuk a konverziót, stb. Általában nagy elemszámú minta áll a rendelkezésünkre.
Kvantitatív kutatási módszer lehet egy kérdőív is és a közvélemény-kutatás is.

• Desk research & field research

Desk research: Objektív megfigyelésekre fókuszál, melyben a már létező piaci szereplők és egyéb megoldások feltérképezése kap jelentőséget. (Ilyen amúgy a best practice kutatás és a versenytárs elemzés is.) Szekunder kutatási típusba tartozik bele, mivel másodkézből, meglévő adatokból táplálkozunk.

Field research (terepkutatás): A direkt megfigyelésre és vizsgálódásra fókuszál. Az interjú, a fókuszcsoportos megbeszélés, az esettanulmányok is ebbe a kategóriába esik. Elsődleges kutatásnak minősül. Elsődleges kutatási típusba tartozik bele, mivel saját tapasztalatokból gyűjtjük az információt.

• Best practice kutatás & versenytárs elemzés

Mindkettő a „desk research” kategória alá eső módszer.

Best practice kutatás: meglévő, létező jó megoldások összeszedése, melyben funkcionális megvalósításokra keresünk példákat, ám a best practice kutatás során szinte elengedhetetlen, hogy a rossz példákat is megvalósításokat is összeszedjük. Fontos, hogy a szubjektivitást ki kell zárni, amikor a hasonló megoldásokat keressük. Iparágtól függetlenül is célszerű példákat keresni a megoldásokra vagy egy funkcionális részletre.

Versenytárs elemzés: legfontosabb lépés a versenytársak meghatározása (közvetlen és közvetett, illetve. elsődleges és másodlagos versenytársak), mely után az adatgyűjtés következik, ahol a meglévő termékeket és szolgáltatásokat, módszereket elemezzük. Amennyien elegendő adat áll a rendelkezésünkre, úgy a konkurencia stratégiáját is meghatározhatjuk. A SWOT analízis jó módszer a versenytársak kiértékelésére. Arra keresünk válaszokat, hogy a kompetitorok milyen megoldásokat használnak.

• Piackutatás & felhasználói kutatás

Piackutatás: a piacon levő szereplők helyzetéről, erősségeiről, gyengeségeiről készítünk elemzést. Fontos, hogy ez nem egy UX kutatás!
A SWOT analízis jó módszer az adatgyűjtés kiértékelésre. Jó részt átfedés lehet a versenytárs elemzés eredményével. Segít az üzleti döntések meghozatalában. A visszajelzések gyűjtése is a piackutatás része, pl: weboldalon elhelyezett kisebb CSAT-okkal = Customer Satisfaction és / vagy NPS méréssel. Célszerű meghatározni a mérés tárgyát, a kérdéskört, a kérdés módjait (pl. skálázás), pro és kontra listát. Kutatási eszközökre gyakori példa lehet a Google Analytics, valamint a Hotjar, követhetjük a szemmozgást (itt min. 30–40 főtől kaphatunk reprezentatív eredményt).

Felhasználói kutatás: segít meghatározni a célcsoport / felhasználók kérdéseit, fájdalompontjait, félelmeit. Jól használt eszköz erre az interjú / kérdőív / fókuszcsoportos megbeszélés

• Usability teszt

Bár nem a projekt elején levő kutatási szakaszba tartozik, mégis egy elengedhetetlenül fontos módszer a meglévő terveink használhatóságának és érthetőségének elemzésére, melyet a tervezési szakaszok közben célszerű alkalmazni, melyről részletesebben később foglalkozunk. Praktikus pl. Zoom-on keresztül készíteni, ott van videórögzítés is. A viselkedést figyeljük. Minimum 5–6 fő bevonásával érdemes elvégezni, akkor kapunk használható eredményt reprezentatív eredményt viszont 5–15 fővel kaphatunk.

• A/B teszt

Lényege, hogy különféle megvalósításokat teszteljünk, mely történhet a tervezés elején, pl. két eltérő drótváz felépítéssel, esetleg éles környezetben, már UI megjelenéssel ellátott megoldással. gyors mód arra, hogy melyik design megoldás a megfelelő, segítségével ösztönös választásokra fókuszálunk. 5–15 fős teszteléssel kaphatunk reprezentatív eredményt.

Megjegyzés:
Vannak elsődleges és másodlagos kutatási típusok is, angolosan „Primer” és „Szekunder” kutatásnak is nevezzük ezeket. A primer kutatások saját magunk által gyűjtött adatok, míg a szekunder kutatások esetében mások által már összegyűjtött adatokról beszélhetünk.

A terepkutatás, mint pl. az interjúzás, kérdőívezés, esettanulmány az elsődleges kutatási kategóriába tartozik, mivel saját tapasztalás útján szerezzük meg az információt; míg egy best practice, és versenytárs elemzés a másodlagos kutatási kategóriába esik, mivel ezeket már meglévő adatokból szerezzük másodkézből, amik analitikus jellegűek.

Ideális kutatási lépések egy projekt kutatási szakasza során:

1. Kutatási célok és felvetések (hipotézisek)
   A fentieket meg kell határozni a felhasználók viselkedésével kapcsolatban, a termék / szolgáltatások funkcióival kapcsolatban, stb.
2. Desk research (best practice és versenytárs elemzés) & Piackutatás & Kvalitatív mérések (ha egy meglévő projekt UX élményének a növelése a cél, és vannak már statisztikai adataink).
   Ebben a szakaszban SWOT analízis segítségével meghatározhatjuk a saját szolgáltatásunk és a konkurencia erősségeit (strength), gyengeségeit (weakness), lehetőségeit (opportunity) és veszélyeit (threat), ami hasznos lehet a további lépések szempontjából.
   A saját szolgáltatásunk SWOT analízisét a projekt elején célszerű meghatározni, míg a konkurenciáét csak a kutatási szakasz révén tudjuk meghatározni.
3. Interjúk / Fókuszcsoportos kutatás / kérdőívek
   Interjúk: Ehhez szükséges kutatási terv összeállítása, kutatási célok meghatározása, kérdések összeállítása, interjú forgatókönyv elkészítése, interjúalanyok felkutatása, adatvédelmi nyilatkozat aláíratása, interjú lebonyolítása (rögzíteni szükséges az interjút). Az interjúk lehetnek a projekt stakeholdereivel és a célcsoport alanyaival is. Megfelelő eredményt minimum kb. 6 fővel tudunk elérni, ettől kevesebb interjú készítése használhatatlan, nem reprezentatív eredményt ad.
   Mit? Mikor? Hogyan? Miért? Milyen? jellegű kérdések. Célja az interjúalanyok szokásainak, attitűdjeinek, motivációinak, problémáinak megértése. Érdemes hangfelvételt / videót is készíteni a jegyzetelés mellett, mivel ezek alapján lehet a mintázatokat megtalálni.
   Fókuszcsoportos kutatás: csoportos interjúzás, ami egy vezérelt metodika mentén zajlik, és hosszabb, mint egy mélyinterjú, moderáció szükséges közben, nehezebb műfaj. Előnye, hogy olyan álláspontokra derülhet fény a fókuszcsoportos interjú során, amiket lehet egyénileg nem osztanának meg, viszont ha csoporton belül vélemények különböznek, akkor az ösztönös reakcióikra fény derül. Megfelelő eredményt minimum kb. 5 fővel tudunk elérni, ált. 15 főnél nem érdemes több emberrel. Usability tesztre semmiképp se használjuk.
   Kérdőívek: magas számú minta nyerhető ki belőle. A kérdőívek összeállítása szakértelmet igényel, legalább annyi idő összeállítani, mint pl. egy interjú szkriptet. Mintegy 100 fő kitöltőtől kapunk szignifikáns mintát (fontos, hogy ez nem piackutatás). A kérdésfajták módja sem mindegy, pl: személyes kérdések (nem, demográfiai adatok, foglalkozási terület, végzettség, korosztály, stb. – ált. radio buttonos választós), Ellenőrző kérdések (szabad szavas), nyitott kérdések (szabad szavas – döntések miértjeire vagyunk kiváncsiak, vagy arra, hogy bizonyos érzéseket mivel magyaráz a kitöltő), zárt kérdések (feleletválasztós, a kérdés függvényében checkbox-os vagy radio button-os, stb.)
4. Kutatás szintézis (Definiálási szakasz)
   Kutatási szakasz összegzése, illetve annak a kérdésnek a megválaszolása, hogyan lesz az interjúkból termék / szolgáltatás. Emellett ebben a szakaszban pontosítjuk, hogy kinek is tervezzük az adott szolgáltatást.
   A szintézis az a definiáliási szakasz, amiben az alábbi elemek, módszerek, lépések hasznosak a tervezési szakasz előkészítéséhez:

• Mind mapping (pl. jó megoldás az interjú összegzésre), segít kategorizáltan átlátni a kinyert információt, későbbi elképzeléseket a tervezéshez.
• Empathy map (interjúk alapján megalkotható, rendszerezzük az eredményeket). Mit mond, gondol, érez és tesz a felhasználó (négyes felosztású mátrix). Viselkedésre koncentrálunk és készíthetjük egy szituációra, egy felhasználóra és egy felhasználói csoportra is. Felírjuk az interjúkon hallottakat és csoportosítjuk. Majd keressük az összefüggéseket. Segítségével a felhasználó gondolkodásmódjára hangolódunk.
• Affinity diagram elkészítése (interjúk alapján megalkotható). Segít megtalálni a mintázatokat és kapcsolódási pontokat, segítségével a megfigyeléseket csoportosíthatjuk, majd megtalálhatjuk az összefüggéseket. Pl: Mit csinál, mi a problémája, mi a motiváció, stb.
• Viselkedés párok felállítása (interjúk alapján megalkotható)
  A résztvevők (interjúalanyok vagy az abból kinyert és megalkotott user minták) egy skálán helyezkednek el és azon látjuk a viselkedési eltéréseket egy egy szituáció esetén. Pl: skála egyik végén: „hétvégén használja”, vs. másik végén „Hétköznap használja” az adott szolgáltatást. A mintázatok segítenek a persona-k kialakításában és elnevezésében.
• Persona-k meghatározása
  Ők azok a személyek, akik képviselik a mintafelhasználókat. Ekkor meghatározzuk, kinek is tervezünk. Interjúk alapján megalkothatóak ezek a felhasználói modellek. A termékcsapaton belül egy jó hivatkozási alap, jobb mint az adatmennyiség maga, mivel a viselkedésre koncentrál és ez sokkal jobban használható. A célcsoport részletesebb definiálására ad jó szemléltetést és közelebb viszi a tervező csapatot a célközönséghez.
• User journey megalkotása (persona-k alapján megalkotható)
  Mi a felhasználó sztorija? (főszereplője 1–2–3 persona, aki megpróbálja elérni a célját, ennek során használ egy terméket/szolgáltatást.)
  Fontos elemek: Ki, mit csinál, hol, mikor, miért, hogyan. A journey-ben kitérünk a hangulati görbére is > ezáltal a problémákat is feltérképezzük. Storyboarding – Kontextust is érdemes hozzá alkotni (pl: napszak, helyszín, stb.)
• Empátia térkép
  Mit gondol és érez, mit hall, és mit lát, mond és tesz az interjúalanyunk, vagy az adatokból generált mintafelhasználónk?
  Lényege, hogy kategorizálva átlátjuk a felhasználók problémáit, motivációit. Megjegyezném, hogy számtalan Empátia térkép típus létezik

Empátia térkép minta

• Fájdalompontok meghatározása (Pain points)
  Azoknak a kihívásoknak a meghatározása, amikkel meg kell küzdeni a tervezés folyamán. Ahhoz, hogy egy problémát megoldjunk, először is meg kell értenünk azokat. A teljes csapat figyelmét ezeknek a pontoknak a megoldására kell irányítani. Ahhoz pedig, hogy jó megoldási javaslatokkal álljunk elő, egyértelműen és érthetően kell megfogalmazni a user problémákat. A jó probléma meghatározás emberközpontú és a célcsoport / felhasználók igényeire épül, tevékenységekre épít, nélkülözi a feltételezéseket, mert tényekre alapoz. Ezek a tények pedig a kvalitatív kutatási eredményeink alapján határozhatóak meg.
• Jobs to be done meghatározása
  Lényege, hogy mit akarnak a felhasználóink elérni (cél) és hogyan érik azt el a folyamaton belül (kontextus és motiváció). A JTBD abban ad segítséget, hogy a kutatási eredmények alapján meg tudjuk határozni azokat az eseteket, amikor az emberek el szeretnének érni egy célt (ez egy fájdalompont kiküszöbölése is lehet), mely érdekében valamilyen szituáción végigmennek. Ha belegondolunk, egy terméket / szolgáltatást azért használjuk / vesszük igénybe, hogy segítsen egy konkrét “feladatot” elvégezni és a végső célunkat elérni. Ezek a célok kisebbek és nagyobbak, rövid időt vagy hosszabbat felölelők is lehetnek.
• How might we
  Definiált problémák megoldásaira ad javaslatot, hogy hogyan segíthetünk azok kiküszöbölésén. Ezek a kérdések sokat segítenek a tervezési szakasz elején, könnyen átkonvertálhatóak a kutatási kérdéseinkből és az interjú/kérdőív eredményekből.
• Impact-effort mátrix megalkotása
  Arra jó, hogy meghatározzuk a projekt lehetőségeit többféle szempontból (pl: üzleti, ügyfél, befektetett idő, stb. szempontjai mentén).

Ötletelés és Tervezés a UX folyamatokban

Lényege a kutatási eredmények (szintézis) alapján a koncepció megalkotása, illetve kidolgozása, validálása, illetve a koncepcióból tervvé történő alakítás.

Fontos az MVP (Most Viable Product) meghatározása illetve kialakítani az „emotional design-t”, hogy miként hatunk a termék/szolgáltatás közben a felhasználók érzelmeire, viselkedésére, milyenek legyenek a mikro interakciók, stb.

Ötletelési és tervezési szakasz részei:

1. Közös ötletelés
   (interdiszciplináris szinten, különböző hátterű csapattagokkal) workshop keretén belül. Itt pl. a Design Studio módszertan elég hasznos. Itt is lehet Mind mappinget alkalmazni
2. User flow megalkotása
   Kapcsolódik a journeyhez, viszont itt objektív folyamatról van szó, az adott termék használata során. Több flow-t is meghatározhatunk, de legyen egy master, amit alaposan kidolgozunk, megnézzük a döntési pontokat és azok lehetőségeit.
3. Információs Architektúra kidolgozása Flow alapján kialakítható. Módszerek lehetnek erre pl: csoportosítás és címkézés (jó program erre az Optimal Workshop)
4. Usability teszt az IA validálására (javasolt lépés)
5. Célirányos ötletelés, vázlatozás (Low fidelity skiccek)
6. Wireframe (mid fidelity)
7. Kezdeti UX copy
8. Usability teszt a drótvázakra
9. Iterálási körök
10. High fidelity tervek és UI tervezési szakasz
11. Végleges UX copy
12. Prototípus készítés
13. Használhatósági- és kivitelezési tesztek
    User tesztnek és Feasibility tesztnek is nevezzük angolosan, ilyenkor a tényleges működést lemodellezve végezzük a prototípus tesztet. (Lentebb kifejtve)
14. Iterálási körök
15. UI elkészítése és Design system megalkotása

Használható Módszertanok az ötletelési szakasz során:

• Crazy 8 módszer
  Egy gyors vázlatozási technika, mely egy A4-es lapon kifér. Használat: A4-es lapot 8 felé hajtogatunk vagy 8 felé osztunk fel. Van ún. crazy 6 módszer is, ami annyiban tér el, hogy az A4-es lapot 6 felé hajtogatjuk (vagy 6 egyenlő részre osztjuk.)
  A felosztások lényege, hogy ennyi különféle ötletet, megvalósítási módot vázlatozzon minden résztvevő (nem a szépségen, hanem az érthetőségen van a hangsúly, mint az Activity társasjátékban is) és minél rövidebb idő alatt vázlatozzunk / írjuk fel az ötleteket. Ezek lehetnek 0.5 ill. 1 percesek /ötlet. Izgalmas módszertani megoldása egy workshopnak.
• Mind mapping
  Rendszerezésre alkalmas módszer, ahol az ötleteket csoportosítani tudjuk, illetve a kapcsolati pontokat is megtaláljuk. Miro jó platform rá
• Card sorting módszer
  Hasznos pl. az IA kialakításához/teszteléséhez akár. Az elemeket logikus elv szerint csoportosítjuk és kategorizáljuk, majd rendszerezzük. Bizonyos esetben userek bevonásával is tesztelhetjük a kártyarendezési elvet. Alapja, hogy a tatalmi elemeket cetlikre írjuk, majd megkérjük a részvevőket, hogy rendezzék logikus csoportokba őket.
  Online szoftver pl: Optimalworkshop
  Megjegyzés: Reprezentatív eredményt 15–30 fővel kaphatunk.
• Tree testing
  Kb. ugyanaz, mint a card sorting módszer, csak itt fordítva kell a csoportosítást végezni, a meglévő kategóriák alá kell az elemeket elhelyezni. Kézi vázlatozás (sketch)
• A/B tesztek
  Nem csak proto tesztelésekre alkalmas, hanem egy gyors mód arra, hogy melyik design megoldás a megfelelő, ösztönös választásokra fókuszálunk a legrövidebb idő alatt. Pl: Melyik megoldást tudod a legkönnyebben értelmezni / használni?
  Megjegyzés: Reprezentatív eredményt 5–15 fővel kaphatunk.
• Workshop
  A workshop során ne feledkezzünk el arról, hogy minden ötlet jó és hasznos, de közben nem szabad megfeledkezni a célcsoportról és azok céljairól, fájdalompontjairól! Mindig kell egy moderátor, aki a workshopok menetrendszerű lebonyolításáért felel, sokszor megegyezhet magával a facilitátor szerepével, aki magát a workshopot tartja.
• Design Studio módszere:
  Célszerű a projekten részvevőket közös ötletelésre ösztönözni, ez egy jó módszer rá. Minden résztvevő egy megoldási javaslattal jön egy adott probléma körre. Akár a problémakörök meghatározásai is közös ötleteléssel történhetnek, eltérő módszerek alkalmazásával (pl. crazy8, vagy csak 1–2 ötlet összeírásával, stb.). Az egyéni ötletelős szakasz után mindenki megosztja az elképzeléseit és közösen értékeljük. Megvitatjuk azok erősségét, gyengeségét egy skálán, majd a kiválasztott ötleteket rendszerezzük.

Használható módszertanok és tesztelési megoldások a tervezés során:

• A/B tesztek
  Nem csak proto tesztelésekre alkalmas, hanem egy gyors mód arra, hogy melyik design megoldás a megfelelő, ösztönös választásokra fókuszálunk a legrövidebb idő alatt. Pl: Melyik megoldást tudod a legkönnyebben értelmezni / használni?
• Usability teszt
  Másnéven használhatósági teszt, mely az adott termék / szolgáltatás hiányosságait és logikai pontatlanságait kívánjuk feltérképezni azáltal, hogy embereket kérünk meg arra, hogy használják a terméket / szolgáltatást és mondják el a véleményüket.
  Amiket validálni lehet: navigáció, CTA-k, szövegezés érthetősége, maga a prototípus használhatósága, stb. Usability tesztet alkalmazhatunk pl. már az Információs Architektúra validálására is.
• Feasibility teszt
  A terveknek a megvalósíthatóságát és kivitelezhetőségét teszteljük, ahol már a fejlesztésnek is nagy szerepe van. Ezzel a teszttel feltérképezhetjük a lehetséges buktatókat, ezáltal kevesebb felesleges munka vár ránk a későbbieken.
  Minimum 5–6 emberrel érdemes tesztelni, ettől kevesebb személy után még nem kapunk reprezentatív eredményt. Fontos, hogy nem a szubjektív véleményalkotás a lényeg, hanem a viselkedés, hogy mit csinál a felhasználó (célszerű a videós rögzítés!)
  A tesztelés során célszerű többen is részt venni a projektből, mivel a csapattagok jegyzetei nagyon hasznosak. Pl: a pozitív és a negatív megfigyeléseket elkülönítjük, card sorting módszert használhatunk, stb.

Tervezés során felmerülő fontos témák:

Tervezési alapok (nem az alaplevek, arról fentebb írtam):
Nem mindegy, hogy mit akarnak a felhasználók és mire van ténylegesen szükségük, ezt meghatározni pedig csak alapos kutatással lehet, hogy kiderítsük, hogy miért is akarnak valamit! Figyeljünk oda a stabil alapokra, pl: grid rendszer, tartalmi struktúra és logika kialakítása.

Design System:
Egységes UI komponensek (layout elemek, form elemek, gombok, szöveges blokkok, navigáció, alakzatok, tipográfia, képanyag & illusztráció, stb.) reszponzivitás.

Amiket figyelembe kell venni:

• Miként jelenik meg reszponzívan az adott részelem? A tervező szoftverben az adott elem méretezhető, áthelyezhető?
• Mi történik, ha nincs megjelenítendő adat (pl. minialkalmazások esetén), mi jelenik meg helyette, mi az üzenet? (Űrlapoknál és egyéb alkalmazásoknál fontos, hogy pl. egy hibaüzenet miként jelenik meg és mi az üzenet.) Mennyire rugalmas a design és a kód maga?
• Figyelni kell az eltérő készülékekre (színek, méretek, op. rendszerek, stb.)
• Akarunk animációt?

UX szövegírás szabályai, tone of voice meghatározása:
Nem mindegy, hogy tegezünk, magázunk, milyen stílusban írjuk, mi a hangnem, milyen kifejezéseket használunk, mi a tartalom maga.
A felhasználói felületekre nem hosszú, túlbonyolított szövegezés szükséges, el kell felejteni a berögzült terjedelmes, sokszor nehezen értelmezhető körmondatokat, hiszen a felhasználók többsége nem érti a bonyolult kifejezésekkel tarkított termékleírásokat.
Célszerű számukra érthető és világos, tömör, és lényegre törő, szeparálható szövegeket alkotni, hogy megértsék a terméket magát és a mondani valót, illetve számukra releváns kérdésekre kapjanak választ az adott oldalon.
Hiszen a szövegírás lényege, hogy a termék / szolgáltatást közelebb hozzuk a felhasználóhoz, ezáltal elengedhetetlen, hogy érthető és tartalmilag hasznos, sallangtól mentes szövegeket használjunk. Emellett azt is figyelembe kell venni, hogy attól, hogy a szöveg érthető lesz, meg kell vizsgálni a használhatóságát az adott felületen.

UX szöveg írásához a felhasználók helyébe kell képzelni magunkat. Nem jó, ha a felhasználónak ki kell találnia, hogy vajon mire is gondoltunk, egyértelműsíteni kell a szövegeket és egyszerűsíteni, amennyire csak lehet!
Egy szöveget is lehet és javasolt is tesztelni projekt élesítés előtt. Azon csiszolni, iterációs lépéseken végig menni mindenképpen hasznos. Design logikusan tervezett szöveg alapján tud készülni, viszont azon is még alakítások szükségesek az adott termék / projekt élesítéséig, mivel sokszor a designból jönnek egyéb módosítási igények ,hogy vlaami legyen rövidebb / hosszabb, ide vagy oda kellene még szöveg, stb.

Ahol nem mindegy a kifejezés: gombok (legyen látható, jelezzük, hogy mit várunk a felhasználótól (akár a gomb előtt), legyen rövid, lehetőleg E/1-ben fogalmazzunk, ahol lehet. Ilyenek az űrlapok, értesítések, hibaüzenetek (próbáljunk pontosan fogalmazni), címek, alcímek, navigáció. Példaként egy hibás jelszó esetében az „újra próbálom”, “jelszó újra”, stb. gombok mellett a „jelszó visszaállítás” akciógombok együttes alkalmazása praktikus.

Összesszefoglalva:

• Fogalmazzunk minél rövidebben (tömörség!).
• Használjuk az olvasó szókincsét és a számára érthető kifejezéseket.
• Rövid mondatok, amikben egy fontos gondolat szerepel.
• A mondat elején szerepeljen a lényeg, vagy a bekezdés elején, különben „elveszítjük” a felhasználót.
• Kerüljük a sallangot.
• Figyeljünk a szakzsargonokra (kerüljük el, amennyire lehet).

Retro

Érdemes a projektek végén a részvevőkkel ún. retrospektív módon egyeztetni a projektről; kiértékelni, hogy milyen folyamatok működtek jól, miken érdemes javítani, hogy alakult a csapat hangulata, mikben lehetne fejlődni, mik lehetnek a következő lépések, stb. Szerencsére erre is számos segítő eszközt/template-t találni (pl: Miro-s template).

A folyamatos fejlődés sosem árt és csak ezáltal tudunk jobbak és hatékonyabbak lenni.

Köszönöm, hogy elolvastad, és dobj egy 👏🏻-t, ha tetszett, hogy másokhoz is eljusson.