Egy UX design feladat buktatói

Bartha Gizella
Works.
Published in
4 min readMar 19, 2018

--

Szakértőként részt venni egy UX design folyamatban szakmailag igazán felemelő érzés. Azt bizonyítja, hogy a vállalatnak nemcsak az üzleti célok fontosak, hanem a felhasználói igények is. Szerencsére ez ma már nem számít újszerű megközelítésnek, egyre többen vonnak be UX szakértőket, UX designereket a jobb végeredmény érdekében.

De annyi minden közbejöhet még egy tervezési folyamatban, ami miatt nem biztos, hogy a végén a UX designért felelős szakemberek büszkén vállalják az elkészült eredményt.

Ennek okaként felmerül egyrészt az, hogy a designhoz mindenkinek szokott lenni „hasznos” gondolata. A legtöbben bizonyára találkoztunk már ilyen projektekkel, ahol egyes szakértőktől a feladat teljes ismeretének hiányában, kontextus nélkül érkeznek kritikák, javaslatok, mondván, hogy az máshol „jól működik”.

Másrészt azonban vannak olyan buktatók, amelyek az előzőnél sokkal konkrétabbak, kézzelfoghatóbbak, és ezáltal könnyebben el is kerülhetők.

Nézzük, mik ezek!

1. Architektek, fejlesztők kihagyása a UX design folyamatból

Az IT rendszerek nemcsak képességet hoznak a vállalatok életébe, de komoly korlátokat is

A folyamat a legtöbb esetben úgy zajlik, hogy megkapjuk a briefet, azt követően egy workshopon pontosítjuk, véglegesítjük az igényeket, egyeztetjük a felmerült kérdéseket, és aztán elkezdünk dolgozni. Napok, néha hetek telnek el úgy, hogy együtt dolgozik a brief alapján UX designer és a UX kutató és amikor elkészülünk, akkor az elégedettség érzésével mutatjuk meg az elkészült prototípusokat a megbízónknak azzal a meggyőződéssel, hogy mindent (értsd MINDENT, tényleg MINDENT) a megbízónk igényeinek megfelelően alakítottunk ki.

De aztán jön a fekete leves. Megnézi a terveket az IT, és hosszas listát kapunk vissza arról, hogy mit miért nem lehet úgy megvalósítani, ahogy szerettük volna vagy ahogy a felhasználóknak célszerű lenne. Még akkor is előfordul ilyen eset, ha a briefelési folyamatnak is részese volt IT, mert valahogy mindig előkerül néhány további szempont, amire tekintettel kell lenni: Az egyik funkciót egy teljesen más rendszer kezeli, és nem tudja megjeleníteni a szükséges adatokat, a másik funkciót egy külön alkalmazás biztosítja, amit nem lehet a projekt keretein belül áttervezni, a harmadiknál van néhány olyan kötött lépés, amit nem lehet kihagyni.

Elsőre ennyit értünk az IT rendszerek működéséből

2. A UI design és az arculati illetve egyéb vizuális kötöttségek

Az arculati guideline-ok ne akadályt jelentsenek, hanem valós segítséget

Szintén tipikus probléma, hogy létezik ugyan egy dokumentum vagy guideline, ami a tervezési és arculati alapvetéseket, elvárásokat tartalmazza, de az nem vagy csak részben követhető a tervezési projektekben.

Ennek oka, hogy ezek az előírások általában néhány éve készültek, és az akkori trendekhez igazodtak. Ezek pedig rengeteget változtak azóta, teljesen más elvek szerint zajlik ma a felületek alakítása. Bizonyára emlékeztek, hogy néhány éve hatalmas betűméretekkel, hatalmas eltartásokkal, jól széthúzott tartalommal jelentek meg a felületek, amik mára jórészt eltűntek, de legalábbis jelentősen átalakultak.

A tervezés során persze sokszor felmerül az igény, hogy ez így nem az igazi, és változtatni kellene, de ez többnyire nem az előírások változását hozza magával, hanem a felületekét. A designerek itt-ott egy picit mindig megpróbálnak változtatni, és ezek közül néhányat jóvá is hagynak. Tehát az írott szabályok mellé bekerülnek íratlanok is, és aztán ember legyen a talpán, aki egyrészt érti, hogy mit lehet és mit nem, másrészt pedig aki ezek mentén tényleg felhasználóbarát felületet tud kialakítani.

Szóval kedves érintettek! Ha van bármilyen arculati előírás, akkor azt frissítsétek rendszeresen!

3. Szövegezési problémák

A UI design behúzza a felhasználót, a tartalom eladja a terméket

A UX és UI design kialakításán sokszor nagyobb a hangsúly, mint a tartalmon. Pedig végső soron a kontent fogja eladni a terméket vagy szolgáltatást.

A szövegírás általában egy sokkal egyszerűbb, rövidebb idő alatt teljesíthető feladatnak tűnik, mint a vizuális rész kialakítása. Ezért sokszor csak a tervezési folyamat közepén, a tervezői csapat sürgetése miatt kerül fel a feladatlistára, hogy ki, mikor és vajon mennyi idő alatt tudja felmérni a szöveg mennyiségét, megírni és jóváhagyatni azt.

Ezért fordulhat elő, hogy az élesítés után olyan szövegek maradnak egy felületen, amelyet a designer csak azért rakott oda, hogy érzékeltesse, valami ilyesmiről kell majd szólni ennek a szövegrésznek.

És a legnagyobb szövegezéssel kapcsolatos kihívást még nem is említettük: ez pedig a jogi osztály.

A felületi tervek jóváhagyását követően a jogi osztály képviselőjéhez is elér a feladat, majd jön a verdikt, hogy ide még ennyi szöveget kell elhelyezni, oda annyit, itt még ezt kötelező megjeleníteni, ott még azt. Ami sajnos nem segíti a felület használhatóságát, sőt…

Sokán mondják, hogy „ugyan, ez csak szövegezés!”, de pontosan tudjuk, hogy ha ezek nem a jó helyen és nem jól vannak megjelenítve, akkor az pont elég arra, hogy összezavarja az olvasót, vagy hogy ne jusson el hozzá a megfelelő információ, De ha jogilag megfelelő és érthető is a szöveg, az még mindig lehet problémás, pl: a továbblépéshez szükséges gomb eltűnik a hajtás alatt elbizonytalanítva ezzel a látogatókat.

A felhasználónak sokszor ilyen a jogi szöveg

Mi tehát a megoldás ezekre a buktatókra?

  1. A UX design folyamatban az elejétől a végéig legyen bevonva egy olyan IT szakértő, aki jól ismeri a háttérrendszereket!
  2. A különböző guideline-ok frissítését kezeljétek magas prioritással! Viszont, ha ennek kezelésére nem áll rendelkezésetekre megfelelő erőforrás, akkor csak annyi megkötést foglaljatok a guideline-ba, ami adhat némi rugalmasságot a UI design során.
  3. A UX design projektek tervezésénél ne felejtsétek ki a szövegezés tervezését (megírás, iterálás, jóváhagyatás), és építsétek be mindezt úgy a folyamatba, hogy a végleges szöveg álljon készen addigra, mire a UI design megkezdődik.

Ha ezek megvalósulnak, akkor a UX szakértőknek is sokkal könnyebb dolga lesz és biztosra vehető, hogy a felhasználók is elégedettebbek lesznek.

Ti mit gondoltok? Kihagytam esetleg valamit?

Élményszerű digitális felületek és kiszolgálási folyamatok létrehozásában segítjük ügyfeleinket. Ez a Testbirds.

--

--

Bartha Gizella
Works.

Egy igazán jó termék fejlesztése során a felhasználó mielőbbi bevonása nélkülözhetetlen.