Nagy munkában ég az Onlinemarketing.hu, B2B szoftvert tervezünk!
Részleteket persze nem mondhatok, de alapvetően néhány folyamatot próbálunk egyszerűsíteni az ügyfeleinknek.
(Ez csak a vázlat..)
Egy ilyen munka mindig a célközönség definiálásával kezdődik, ami UX-es módszertanban perszónákat jelent. Őszintén megmondom, nem készültek külön mélyinterjúk ügyfelekkel a perszónák létrehozásához: eleget beszélek, interjúzok velük minden más ügyben. Legfeljebb annyi történt, hogy amíg Konrád beszélt, igyekeztem ezzel a szemmel is figyelni a reakciókat, esetleg egy-két ártatlannak tűnő mellékes kérdést tettem fel.
Ezután összeültünk a vezetőséggel, és megvitattuk ezen perszónák igényeit, rajzoltunk pár nagyon egyszerű filctollas wireframe-et közösen.
Az elkészült wireframe-eket azonban ehhez a dokumentumhoz még nem használtam fel.
A számítógép ugyanis egy interaktív médium, a hangsúly a folyamatokon van. Hiszek abban, hogy a dolgok egymásra következése sokkal jobban számít nagytotálban, mint hogy konkrétan mi is van a képernyőn. Az, hogy a felhasználó milyen kulcsképernyőkkel, milyen e-mailekkel (!) találkozik, milyen döntésének milyen következményei lesznek az interakció további menetére vonatkozóan sokkal jobban számít, mint hogy pontosan milyen elemek is szükségesek ehhez a döntéshez – azzal is foglalkozunk, előtte ÉS utána.
Az itt használt ábrarendszer megkülönböztet
- fő forgatókönyvet
- mellékforgatókönyveket
- felhasználói kulcsképernyőt
- felhasználói értesítést
- adminisztrációs kulcsképernyőt
- adminisztrációs értesítést.
Bármennyire is szeretnénk, ez utóbbi kettőn hajlamosak leszünk vágni: nem cél se a mobilkompatibilitásuk, se a tipográfiai egységességük. Mentségünkre legyen mondva: magunkat szivatjuk a puritán, jól kezelhető de kidolgozatlan felületekkel, nincsenek adminisztrátorhadak akik 8 órában szenvednek ezzel…
Csak és kizárólag a folyamatokban szereplő képernyők alapján állhat össze az oldaltérkép, oldalstruktúra. A felhasználó nem azért jött, hogy a menüt nézze, hanem hogy a céljait elérje. A térkép csak ahhoz kell, hogy megtalálja az ehhez szükséges ajtókat, de először azt kell tisztázni, hány szobán is kell átmennie annak, aki a király fele lányát szeretné?
Az oldaltérkép (sitemap) már betekintést nyújt a projekt méreteibe – de ha irtani akarunk, akkor nem az oldalakat írtjuk!
Irtani csak úgy lehet, hogy vagy kevesebb folyamatot támogatunk (pl. nem lehet majd cukorkát venni az oldalon mégse), vagy a folyamatokat próbáljuk meg egyszerűsíteni, egységesíteni.
Ezekhez készül aztán el wireframe: mind asztali, mind mobil változatban.
Az RWD ugyanis nem jelent egyszerűsítést tervezési szempontból: mi felhasználói élményt tervezünk, azaz meg kell terveznünk a mobilélményt és az asztali élményt is. A többiről csak reméljük, ez a kettő (vagy több) kifeszíti jól azt a teret, ahol az élmény jó, élvezhető.
A Mobile First nem lehet ekvivalens azzal, hogy megtervezzük mobilra, asztalon a maradék 90%-nak meg majd valamilyen lesz. Nyilván nem fogunk külön explorer és firefox élményt tervezni, ha nem muszáj, de valamilyen szintig végig kell gondolnunk a média különbözőségét, legyen az mobil, tablet, vagy felolvasóprogram.
Ha nem is mindenben dupla a RWD, jelentős többletterhet okoz. Gondolni kell persze a színvakokra is, meg egy csomó más dologra, de a leginkáb az a fontos, hogy a többféle találkozási mód többféle interakciót, így több élményt, több tervezést jelent.
