Drótváz vagy szöveg?
A webes fejlesztésben végre hazánkban is eljutottak cégek (távolról sem mind) arra a szintre, hogy a fejlesztés egyes szakaszaiban drótvázakat (mockup, wireframe) készítsenek. A drótváz fogalmát természetesen értelmezhetjük nagyon tágan, akár minden firkát tekinthetünk annak, amit valami vezetőszerűség vagy marketinges készített, de csak az igazi drótváz alkalmas arra, hogy a designernek és a programozónak egyaránt útmutatóul szolgáljon. Ha ezt a szerepet betölti, akkor lényegtelen, hogy kézzel rajzoltuk, drótvázkészítő programmal (pl. Axure, Omnigraffle, Balsamiq stb.) vagy akár kedvenc programunkkal (pl. Photoshop, Illustrator, Keynote vagy akár Excel!) készítettünk ilyet. Szintén nem a leglényegesebb az, hogy ez Móricka rajz-szerű, mérnöki terv, vagy designközeli színes-szagos layout.
Ennél sokkal fontosabb, hogy tudjuk, miért készítjük a drótvázakat, és mikor használjuk fel őket. A drótvázak ugyanis annak illúzióját kelthetik, hogy készen vagyunk, mindent elmondtunk egy oldalról, amit kell, innentől megy minden magától. Sőt sokkal többet értünk el, mint amikor korábban homályosan leírtuk, hogy mire hogyan van szükség, hisz azok könnyedén félreértelmezhetőek voltak, míg egy jól megrajzolt drótváz magáért beszél. Minden egyértelmű rajta. A designer tudja, hogy milyen menüt hova rakjon, hol van a gomb, hol van a szöveg. A programozó a design alapján pedig könnyedén összerakja a dolgokat.
Az ilyen gondolkozással abban hibázunk már az elején, hogy a weblap tervezés nem arról szól, hogy képeket rajzolgatunk, aztán azokat valahogy összekötögetjük és ettől az egész jól fog működni. Elsőként a folyamatokból kell kiindulnunk, amelyeket végrehajthatnak a felhasználók, és ezen folyamatok egyes állomásainak környezetét kell megterveznünk, megalkotnunk. Ha ezek nem tiszták a tervező fejében, akkor oldalunk működése döcögős, esetleges lesz. A gördülékeny folyamat természetesen önmagában még nem hoz tökéletes felhasználói élményt, de legalább azt biztosítjuk, hogy az egyes lépések értelmesen, a felhasználó számára befogadható módon kapcsolódnak össze.
A drótvázak mellett így szükséges folyamatábrákat is készítenünk, de ez még mindig nem elég. A leírásokhoz kell visszalépnünk. A programozó és a designer számára el kell magyaráznunk, hogy miképp működik az oldal, hogyan lépnek interakcióba az egyes drótvázak. Természetesen készíthetünk dinamikus drótvázakat is, de ha minden működését egyértelművé akarunk tenni, akkor lényegében meg is csináltuk a weboldalt (=rengeteg munkaóránkba kerül), azonban ez csak demó változatban működik. A programozó létrehozhatja újra. Másrészt számos olyan megoldásra szükségünk lehet, amelyeket még a legprofibb tervező programokkal sem tudunk előállítani.
Egy igazán jó minőségű leírásnak az összes olyan helyzetet le kell fednie, ami a drótvázon változhat a felhasználóval való interakció során. Mindent le kell írnunk a legapróbb részletekig. Hogyan működnek a gombok, a tabok, a szűrések, hol jelennek meg a hibaüzenetek és mi ezeknek a szövege. Ha ezeket nem tesszük meg, akkor a designer és a fejlesztő ad hoc módon fogja megvalósítani ezeket. Ahogy ő szokta, vagy ahogy az adott pillanatban a legjobbnak tartja, mivel gyakran nem kérdeznek vissza a homályos részleteknél. És ez nem is az ő hibája, hisz mi trehány anyagot adtunk le neki, így egyáltalán nem várhatjuk el tőle, hogy a fejünkben lévő homályos ideát leprogramozza, megdesignolja. Ne bízzuk a véletlenre! Ha tervezünk, akkor adjunk át precíz drótvázakat, folyamatábrákat és mindenre kiterjedő részletes leírásokat.
Dr. Rung András
Ügyvezető, UX Vezető
Rung András 2002 óta foglalkozik UX-szel. Az innovációt és az üzleti fókuszt mindig szem előtt tartja. Az első magyar webergonómiai könyv a Felhasználóbarát honlapok társszerzője. Cikkei a nemzetközileg is jelentős Smashing magazinban is megjelentek.
Mind a 23 hozzászólás mutatása
Kedves Ergo,
ajánlott
cikkek
Tudj meg többet a témáról
Lépj velünk kapcsolatba!
Alkossunk együtt felejthetetlen dolgokat!
Kedves Ergo,
Bartók Béla út 39.
1114 Budapest
Látogatóknak
23 hozzászólás
Oszd meg velünk véleményed
Rung András | 2011. Feb. 20.
Ez igaz, csak néha a sok meetingezés a szétfolyáshoz is vezethet. Meg kell találni az optimumot a munka és a kommunikáció közt, de ezzel nem mondok sok újat:)
Bővíz László - JUEX | 2011. Feb. 20.
@Rung András: Nem, nem szükséges céges forma a scrumhoz. Egynél több ember esetén már érdemes csinálni. Valójában annak nagyobb a költsége, ha nem tart egy csapat demót az megrendelőnek, ugyanis nagyságrendekkel növeli a távolságot az elvárt és a megszületendő eredmény között.
Rung András | 2010. Nov. 04.
@Bővíz László - JUEX: Laci, természetesen félreérthető minden. Vannak amikor eltérő a szóhasználat, nem tiszták a fogalmak. Teljesen igazad van abban, hogy ezek előfordulhatnak és a megbeszélések tisztázhatják. A legbiztosabb módszer azonban ezek után a memók, hogy mindenki valóban ugyanezt értette ez alatt, mint a többiek, hisz félreértések még így is adódhatnak.
SCRUM-ot ti rendszeresen csináltok. Érdekes módszer, de egy kisebb csapat folyamatos és intenzív jelenlétét igényli, azaz céges formák szükgések hozzá nem?
A demó is jó dolog, bár nekem a tapasztalatom, hogy olvasni még olvasnak az emberek, de egy tiszta érthető demó, prezi segíti a könnyebb befogadhatóságot. Természetesen a munka idejét és költségeket növeli, hisz a demót is el kell készíteni. De megérheti.
Bővíz László - JUEX | 2010. Nov. 03.
@András: A részletes leírásokat is simán félre tudja érteni a programozó csapat. Ennek kiküszöbölésére én most fogom bevezetni a fejlesztés előtti részletes prototípus ismertetést. Ha vannak tesztelők ők segíthetnek a kontrollálásban még.
Bővíz László - JUEX | 2010. Nov. 03.
Egy pontos interakciókat részletező leírás elolvasását nem lehet elvárni az ügyféltől sem, demózni kell neki.
A hozzászólásokban felvetett ügyfél, programozó csapat és projekt kezelési problémákra kiváló megoldást tud adni, ha például SCRUM módszerrel dolgozik a fejlesztő csapat, ugyanis az nagyon kiterjedt kommunikálást vár el a csapattagoktól és a megrendelőtől is. Tapasztalatból mondom, hogy szuper, ha jól csinálják.
Rung András | 2010. Oct. 04.
@prometheus_X: Köszi a nagyon értékes bejegyzést. Igazán csak annyit fűznék a megbeszélésekhez, hogy nagyon jók és hasznosak valóban mérföldköveknél, viszont arra is figyelni kell, hogy ne legyenek felesleges semmiről szóló meetingek. Azaz egy anyagot fontos átbeszélni, de nem rossz előtte meggyőződni arról, hogy az illető valóban normálisan elolvasta-e vagy csak beleturkált és azért kérdez, mert nem olvasott.
prometheus_X | 2010. Oct. 04.
@Zebra12: Most lehet, ez csak a saját maximalizmusom, de én amikor egyedül dolgozom egy munkán is szétválasztom a saját szerepeimet egymástól. Ehhez hozzátartozik az is, hogy nem igazán jegyzek meg sokszor sokmindent, így aztán külső memóriára kell támaszkodjak (papír, txt, bármi). Az András által leírtakat már külön-külön alkalmaztam többször is, így egyben még nem. Jó módszernek tűnik.
Sokan hangsúlyozzák a kommunikációt, és ez helyes is. Mint sok programozó sajnos ezen a ponton nekem is van mit behoznom, mert hajlamos vagyok a Rambo-típusú dzsungelharcra... ugyanakkor sok pozitív tapasztalatom van arról, hogy a jókor és jól feltett kérdések mennyit lendíthetnek a munkán. Igen fontos dolognak tartom azt, hogy már akkor készüljön vázlat a projektről, amikor az első megbeszélések vannak. Egy egyszerű skiccet már az első tárgyalás alatt fel lehet rajzolni, de legalábbis jegyzetelni KELL. Nem csak magad miatt, hanem azért is, hogy az ügyfél lássa az érdeklődést. Ha a skicc van annyira jól sikerült, vagy jól modellezi a megbeszélésen elhangzottakat, akkor már ott érdemes egyeztetni az ügyféllel, hogy valami ilyesmire gondolt-e. Alapvető felismerésem szerint az ügyfél mindig "ideges", ezért fontos megnyugtatni - ezt pedig csak úgy lehet, hogy ha fizikailag látja, hogy a munka gőzerővel halad előrefelé.
A tervezésbe mindig be kell vonni a grafikust és a UI developert (vagy bármelyik fejlesztőt, aki felületek működésének leprogramozásáért felel). Sokszor itt születnek a hatékonyságot fokozó kompromisszumos javaslatok. A programozó féken tarthatja a grafikust, ami időnként fontos. Nyilván, amikor egymagam vagyok minden, akkor is meg fogom vitatni magammal, hogy mi a hatékonyabb - hangozzék ez akármennyire is hülyén így első olvasatra. Ilyenkor először azt nézem meg, milyen kész eszközök állnak a rendelkezésemre, a tervet pedig eleve ehhez próbálom majd igazítani. Bármi olyat, ami nem egyészen fedi az ügyfél elvárásait az előzetes vázlatok alapján, külön is érdemes kigyűjteni, ezek amúgyis ütközőpontok lesznek előbb vagy utóbb. Érdemes listába szedni, tételesen indokolni, hogy mit és miért javaslunk ahelyett, amit az ügyfél mondott. Személyesen leülni megbeszélni, kifejteni, megmutatni. Mondok egy jó példát: amikor megjelent az IE 7-es, az akkori munkahelyem a javaslatomra már úgy egyeztetett az ügyfelekkel, hogy az IE 6-ra optimalizálás 40-70%-kal emeli a fejlesztésre fordítandó időt és ezzel együtt a költségeket. Nem kötöttük ki, hogy nem vállaljuk, csupán döntés elé állítottuk az ügyfelet, hogy megéri-e neki a presztizsért cserébe kifizetni a másfélszeres árat. Meglepően sokan léptek vissza az IE 6-os optimalizálástól! Végül persze volt olyan ügyfél, aki kérte a projekt után az optimalizálást is, de addigra az oldal már át volt adva, és egy elégedett ügyfél tért vissza. És persze volt olyan is, aki kifizette az emelt költséget és tudomásul vette, hogy a fejlesztési idő ezzel együtt meg fog emelkedni - cserébe elvárta, hogy az oldal takkra hibátlan legyen. Negatív hozománya ennek sem volt.
Fontos, hogy amikor szakmai érveket hozunk fel az ügyfélnek, mindig világos legyen, ha az befolyásolja a fejlesztési időt, akkor mennyivel és mennyi pénzért. Ha nem befolyásolja a fejlesztési időt (például mert csak usability javaslat) akkor lehet támaszkodni közimert példákra (meg is lehet mutatni egy jól megválasztott példán keresztül, így az ügyfél érezni fogja a kényelmet/egyéb előnyt). Amikor ütközünk az ügyféllel, mindig legyenek eszközeink: számok, idők, kézzel fogható (kipróbálható) példák!
A másik fontos dolog pedig, hogy az ügyfél általában nem a mi dolgunkkal van elfoglalva, ezért amikor anyagot küldünk neki, mindig el kell érni, hogy legyen tőle visszacsatolás, hogy megkapta, megértette! Bármi olyat, ami több, mint 1 A4-es oldal terjedelmű, személyesen is meg kell beszélni. Ennek elég sokféle oka van, nekem az a tapasztalatom, hogy nem érdemes kockáztatni.
Ezeket a problémákat pedig nem fogja helyettünk megoldani sem a HTML 5 (vagy akármennyi), sem a Google :) A garanciáinkról magunknak kell gondoskodnunk.
"ebben az országban, ahol a cégek nagyrésze azt hiszi a weblap ugyanúgy ingyen van, mint a Windows :)"
A jelenség annak köszönhető, hogy ma már mindenki, aki be tud kapcsolni egy gépet, automatikusan webfejlesztő és grafikus is egyben :)
Ebből is látszik, hogy egyikünknek sincs igazunk. A szakma nagyon híg, az ügyfelek a legolcsóbbat akarják választani. Az a mi felelősségünk, hogy megindokoljuk, miért nem mi vagyunk a legolcsóbbak. A másik örökérvényű felismerés pedig: tudni kell nemet mondani. Én is láttam már nem fizető, meg rosszul teljesítő ügyfelet, de ezeknek a többsége kivédhető lett volna egy rendesen megfogalmazott szerződéssel. De ez már egy másik téma, a lényeg, hogy kár általánosítani.
Rung András | 2010. Sep. 30.
Teljesen igazad van abban, hogy ez egy távoli ideál, de nekem nagy példaképem Kazinczy. Ugyanazt kell megcsinálni, mint 200 valahány évvel ezelőtt. Előbb örülhetünk a másodkategóriás német románcok lefordításának is, mielőtt valami nagyba kezdenénk. De végén mégiscsak lettek nagy regényíróink is. Ugyanez van a weblapokkal. Tudjuk a célt, azt is tudjuk, hogy borzasztó messze vagyunk ettől, és ezért keményen harcolunk. A html5 szintén még egy jó idő amíg elterjed, meg még le kell mennie a htm5 flash háborúnak is valamennyire. Én ebben a ráöntésben nem teljesen hiszek. Szerintem a kettő jobban összefügg, semmint hogy ez mindig-többnyire lehetséges legyen, de a technikai függetlenség mindenképp előnyös.
Zebra12 | 2010. Sep. 29.
Mókás ilyen elemzéseket olvasni ebben az országban, ahol a cégek nagyrésze azt hiszi a weblap ugyanúgy ingyen van, mint a Windows :) Ezeknek próbálj meg eladni egy ennyi szereplős fejlesztést...
Annyit fűznék hozzá még, hogy remélhetőleg a HTML5-el és talán a Google különböző termékeivel végre el fogjuk érni, hogy a design és a kód teljesen elválik egymástól, és akkor a drótváz önmagában akár a kész program is lehet, csak még nem szines, szagos, hanem csak szöveges formában, amire a designer függetlenül is ráöntheti, akár a többféle megjelenést is.
Rung András | 2010. Sep. 28.
@Pethő Szabolcs: Ezek nagyon jók! Én már olvasom is..)
Pethő Szabolcs | 2010. Sep. 28.
@Illyés Edith: Szerintem a megrendelői nyomás nagyrészt azzal csökkenthető, ha az elején tisztázzátok, hogyan dolgozol, az egyes fázisoknak mi az értelme, és kinek mi a szerepe.
A miértek megválaszolása főleg az ügyfél dolga, a hogyan pedig a jómunkás emberé. Kommunikáció, kommunikáció, kommunikáció.
András után Paul Boag az én egyik hősöm :) Több előadást is tartott arról, hogyan javítsuk a kapcsolatunkat az ügyféllel. Itt az egyik: boagworld.com/talks/educating-clients-to-say-yes
Ez pedig egy írása a Smashing Magazine-on:
www.smashingmagazine.com/2010/02/19/is-john-the-client-dense-or-are-you-failing-him/
Rung András | 2010. Sep. 28.
@Illyés Edith: Ez a szemcukor jó, még ebben a formában nem hallottam. Hát ja, sokszor a megrendelő mivel nem ért hozzá, nem abba az irányba tolja, ami megfelelő lenne. Talán azért évről évre egy kicsit tisztul a helyzet és lassan itt is kialakulnak a szerepek.
Illyés Edith | 2010. Sep. 28.
@Rung András: Igen, ez egy ideális állapot, hogy van projektmenedzser, van egy team, amiben van legalább ergonómus, programozó, és designer, a drótvázból előbb tesztelhető prototípust építünk és utána jön a design, stb. Kisebb fejlesztéseknél általában egy ember több szerepkört is betölt, és a munkafolyamatok hajlamosak összegubancolódni.
Ebben nagy szerepe van a megrendelői nyomásnak, ő minél előbb szeretne valami szemcukrot, és sokkolja a drótváz vagy a prototípus puritánsága. Ezt az ellentmondást -- legyen már az elején szemcukor, de azért ne a tapétával és a csempével kezdjük a ház tervezését -- nekem eddig nem sikerült feloldani.
Rung András | 2010. Sep. 28.
@Illyés Edith: A második bekezdésben nagy igazságot mondtál. Abszolút, az ergonómus nem projektmenedzser, habárt többször olyan feladatok a nyakába szakadnak, amelyek projektmenedzseriek, de ez alapvetően nem helyes. Persze, ha még ergonómus sincs, akkor a designer ergonómus és marketinges! is egyben sokszor.
A megvalósítási lehetőségeket illetően valóban túlzóan fogalmaztam. Csak annyit akartam mondani, hogy még ha a működés egyértelműen le is van írva, akkor is lehet többféle módon leprogramozni. Arra, hogy a programozó jó tervet kapjon az a garancia, hogy folyamatosan konzultálnak vele, és már az elején is hallatja a hangját. Így mondhatja a marketingesnek, projektvezetőnek, ergonómusnak és designernek, hogy lányok-fiúk ezek a tervek csodásak, meg is tudom csinálni, csak az 10-szer annyiba fog kerülni időben/pénzben, mint amit ti szeretnétek. Nem lehetne így vagy úgy inkább?
Rung András | 2010. Sep. 28.
@Pethő Szabolcs: Köszönöm, igen, én sem élem ki a kreativitásomat a programozásban. Még ha tudnék is kódot írni, messze lenne a tökéletestől:)
Illyés Edith | 2010. Sep. 28.
@Rung András:
"végtelen megvalósítási lehetősége van"
LOL, én sokszor örülök, ha van 1 (egy). De elég gyakran kapok olyan terveket -- méghozzá design szinten, aprólékosan kidolgozott terveket --, amelyeket nem lehet ésszerű határidőn, költségkereten belül megvalósítani, vagy gazdaságosan működtetni.
Egyetértek, mindenki csinálja azt, amihez ért. Fejlesztési projekteket pl. nagy tudású, a technológiai lehetőségeket és korlátokat jól átlátó projektmenedzser irányítson. Attól, hogy valaki a fejlesztési folyamat elején dolgozik, pl. drótvázakat készít, felületi elemeket tervez, még nem biztos, hogy alkalmas rá, hogy az egészet átlássa és kézben tartsa.
Pethő Szabolcs | 2010. Sep. 28.
Az interakciók nagyon fontosak. Az egyes weboldal elemek viselkedése meghatározó a felhasználói élményben, ezért ahogy András írta, tervezéskor ezeket a részleteket is rögzíteni kell. Nem szabad a "véletlenre bízni". Ez persze nem azt jelenti, hogy a programozó, designer vagy bárki, aki hozzátesz a kész munkához teljesen kimarad a tervezésből, és ők már csak ütik a billentyűzetet, helyezgetik a pixeleket.
Szerintem megint sikerült jót írnod!
Rung András | 2010. Sep. 28.
@Illyés Edith: A programozó természetesen nem csak egy végrehajtó személy. A jó tervezésben folyamatos konzultáció van azokkal az emberekkel, akik a következő munkafázisban dolgoznak. Másrészt, ha megmondjuk, hogy ez meg ez hogyan működjön annak végtelen megvalósítási lehetősége van, azaz a kreativitását ki tudja élni, csak épp abban, amihez ért a legjobban. Programozó, designer ne tervezzen weblapot, hanem programozzon designoljon. Természetesen bizonyos esetekben ezeket ők is végezhetik, de akkor ők egy személyben ergonómusok is. A feladatsor, amit írtál teljesen rendben van. Annyit fűznék hozzá, hogy az interakció mindig nagyon fontos, másrészt ez az ideális szekvencia legfeljebb csak a nagy fejlesztéseknél valósul meg. Kis és középvállalkozások ilyet nem nagyon csinálnak itthon. Tudomásom szerint legalábbis. A divatmárka honlapjánál az arculat valóban döntő, de attól még nagyon sok féle megvalósulás lehet tervezésileg is. Másrészt ez is csak részben köti meg a designer kezét is. Azaz adott színvilág, látványelem készlet sokféleképpen realizálódhat.
Illyés Edith | 2010. Sep. 28.
"A designer tudja, hogy milyen menüt hova rakjon, hol van a gomb, hol van a szöveg. A programozó a design alapján pedig könnyedén összerakja a dolgokat."
Nem tudom, honnan jött ez, hogy a programozó az kb. egy kőműves, az utolsó a sorban, csak odaadjuk neki a kész színes-szagos a tervet, aztán húzza fel, ahogy tudja.
1. Drótváz.
2. Működő, tesztelhető prototípus megépítése.
3. Design a prototípus HTML-kimenetének figyelembe vételével (elemekből, modulárisan felépítve a látványt).
4. Design implementálása.
Vannak teljesen látványalapú, kevés tartalmat mozgató, kevés funkciót megvalósító webhelyek (pl. divatmárka kampányhonlapja), ahol a design jön előbb.
De 10 esetben 9-szer nem így kellene dolgozni.
Rung András | 2010. Sep. 28.
@Bajnok: Értem, így egyben nem tudom. Talán a Jakob Nielsen oldalán, de szerintem ilyet részletesen leírva leginkább könyvekben találsz. Esetleg egy későbbi bejegyzésben tudok közölni valami fiktív leírást, ha hasznos, csak nem ígérem 100%-ra.
Bajnok | 2010. Sep. 28.
@Rung András: Nem is olyanra gondoltam, amit Te csináltál, hanem bíztam benne, hogy van valamilyen külföldi példa.
Köszi a tippeket.
Üdv
Zsolt
Rung András | 2010. Sep. 28.
@Bajnok: Sajnos ilyenem nekem csak úgy van meg, hogy nem publikus, azaz megrendelésre készült. A wireframes.linowski.ca/ alatt töméntelen drótvázas cikket találsz, amiben hasonló szemléletet nyomnak mint én, és ott esetleg találsz további izgalmas morzsákat is. Az árfogóbb folyamatok megszervezésében Peter Morville könyve segíthet: www.amazon.com/Information-Architecture-World-Wide-Web/dp/0596527349
Bajnok | 2010. Sep. 28.
Nem vagyok profi ebben a témakörben, viszont érdekes.
Tudnál a posztban említettekre egy jó példát linkelni? Köszi szépen.