Milyen a jó szoftver design? II. rész

A ux és ui design témájában rengeteg módszertani cikk és esettanulmány elérhető, azonban kevés olyan cikkel találkoztunk, ami a fejlesztési projekt sikerét a design szempontjából közelíti meg.

Milyen tehát a jó design szoftveres szemmel? Olvassátok el 10+1 gyakorlati jótanácsot és hüvelykujj szabályt összeszedő cikksorozatunk második részét.

A jó design kiegészíti a specifikációt

Egy kép többet mond ezer szónál: az IT specifikációkra hatványozottan igaz ez az elsőre elcsépeltnek tűnő mondás. Ezért rendkívül fontos tudatában lennünk annak, hogy a jó design kiegészíti a specifikációt, folyamatokat szemléltet, a specifikáció elválaszthatatlan részét képezi.

Számoljunk azzal is, hogy sok üzleti és IT stakeholder számára a design jelenti az egyetlen befogadható specifikációs eszközt. Egy szöveges, adatmodellekkel és folyamatábrákkal tűzdelt specifikáció teljes megértése majdnem olyan szakértelmet feltételez, mint ami annak megírásához szükséges. A specifikáció feldolgozása időigényes is, míg egy design átnézése jóval kevesebb időt igényel. Így sok stakeholder maximum a designt látja, vagy annak egy részét. Ha a design jó és szakértő módon van számukra bemutatva, akkor ez segít nekik megalapozott döntéseket hozni.

Mivel minden projektszereplő elemi érdeke, hogy a stakeholderek felelősen döntsenek, ezért akkor járunk a legjobban, ha a designt a specifikáció kivonataként is kezeljük. A design természetesen nem pótolja a specifikációt, hiszen egy webshop-designon nem lesz rajta, hogy „az árakat minden éjjel 2:00-kor szinkronizáljuk”, de mégis rengeteg, a stakeholderek számára fontos információt lazán átadhat. Rendkívül fontos, hogy a design pontos legyen és mindenben megfeleljen a specifikációnak, ne legyenek ellentmondások a kettő között.

• A designerek és a specifikáció készítői – BA-k, konzulensek – dolgozzanak együtt, rendszeresen nézzék át egymás anyagait, hivatkozzanak egymás dokumentumaira!
• A két szerepkör lássa be, hogy mi az, amihez a másik eszközkészlete jobban passzol: mi az, amit nem lehet írásban definiálni és mi az, ami nem fér rá a képernyőtervre!

Minden lényeges esetet lefed, de nem akar minden állapotot meghatározni

A jó design – a specifikációhoz hasonlóan – tartalmazza a pozitív eseteket, amikor minden úgy történik, ahogy szeretnénk: minden adat tökéletes, az ügyfél nem hibázott el semmit, a háttérrendszerek közül mind elérhető stb.

Gyakran előfordul azonban, hogy a design nem tér ki a problémás, macerás esetekre. Jellemző, hogy a design jól néz ki addig, ameddig egy meghatározott adatmennyiséget tartalmaz, de hosszú nevek, szövegek esetén szétcsúszik, elveszik az összeszedettsége. A jó design kitér ezekre az esetekre is.  

Ugyanakkor egy designban lehetetlen minden screen minden lehetséges változatát megrajzolni. Tegyük fel, hogy egy regisztráció során van 5, kötelezően kitöltendő mezőnk Ezt az egyszerűnek tűnő feladatot nagyon sok módon el lehet rontani: ha az első mezőt nem töltöm ki, az egy másik eset (és screen állapot), mintha a második és negyedik mezőt nem töltöm ki. Ha jók vagyunk kombinatorikában, akkor kiszámolhatjuk, hogy ez 32 képernyő-változat. Ha ehhez hozzávesszük, hogy validáció is van az adott mezőkre, a lehetséges screenek száma hirtelen 200 fölé nő. Ebből jól érthető, hogy a designnak nem kell kétszáz esetet megrajzolnia, ugyanakkor elvárás, hogy a jellemző hibaeseteket kezelje, és olyan formában tartalmazza, hogy abból a szoftver az összes állapotot képes legyen generálni.

• Koncentráljatok az esetek 80%-ára, amit 20%-nyi effortból meg lehet rajzolni, ez a happy path!
• Utána iteráljatok egyet, a maradékból keressétek meg a legjellemzőbb hibaeseteket és ehhez legyenek screenek. Itt hagyjátok abba! :)
• Fordítsatok időt a fejlesztői supportra, amikor azokat az eseteket kezelitek, amik nem jutottak senki eszébe vagy nem tartottátok fontosnak, de mégis azok!

Styleguide-ot is tartalmaz

Egy jó designnak része egy styleguide, ami összegyűjti a felhasználói felületen használt atomi elemeket, űrlapmezőket, gombokat, szövegstílusokat, hibaüzeneteket, színeket stb. Ez hosszú távon rendkívül hasznos:

• pontos információ a fejlesztőknek, hogy minek hogyan kell kinéznie,
• a designerek számára közös nevezőt jelent,
• egy hosszabb távú fejlesztés megjelenése egységes marad,
• ha több designer dolgozik a projekten, akkor összehangolja a munkájukat,
• arra is alkalmas, hogy kisebb fejlesztéseket, amelyekhez csak wireframe készül, a styleguide alapján a fejlesztők az alkalmazásba organikusan illeszkedő módon létrehozzanak.

Kapcsolódva az előző ponthoz, egy styleguide segít abban is, hogy azokban az esetekben vezesse a fejlesztők vagy product ownerek kezét, amelyek megrajzolása nem elvárható. Mivel a modern tervezőprogramok már támogatják azt, hogy maga a design ténylegesen a styleguide-ból építkezzen – például egy szín kivezetése egy központi változóba, amelynek módosítása az összes terven azonnal jelentkezik –, ezért a styleguide a tervezés folyamatát is egy magasabb szintre emeli.

• Legyen elvárás egy olyan styleguide elkészítése, amely az oldal összes lényeges elemét részletes dokumentációval tartalmazza!
• A designerek folyamatosan gondozzák a styleguide-ot, ahogy a projektbe egyre több dolog kerül!
• Készítsétek olyan eszközzel a designt, amely a styleguide-ot strukturáltan használja!

Figyelembe veszi a technológiai kereteket

A design készülhet úgy, hogy nem vesz tudomást arról, hogy milyen technológiával fogják megvalósítani, ez a költségek felesleges növelésének nagyon egyszerű módja. Ha így készül a designunk, akkor biztosak lehetünk abban, hogy a frontend fejlesztőink felesleges időt égetnek el arra, hogy kész, jól működő megoldások helyett kicsit másmilyen, de egyedi megoldásokat készítsenek. A probléma itt az, hogy a fejlesztés után az apró-cseprő hibákat kell javítgatni ahelyett, hogy kész, tökéletesen működő elemeket használnánk.

Az igazán jó designer tekintettel van a technológiára, amelyet a fejlesztők használnak és ennek figyelembevételével olyan megoldásokat tervez, amelyek az adott technológiához illeszkednek. A technológia lehet egy frontend / komponens keretrendszer, mint például Bootstrap, Vuetify, Prime, Quasar, Flutter vagy natív mobil, de lehet egy termék is, például Drupal, Magento vagy LogiShop. Ha komponens keretrendszerről beszélünk, akkor az abban elérhető UI elemek paraméterezésével megoldható designt kell tervezni. Ha termékről beszélünk, akkor feltételezhetjük, hogy abban a design olyan best practice-ekből épül fel, amelyeket érdemes követni. Logikai változásokat maga után vonó design változtatásokat pedig csak azoknál a funkcióknál érdemes alkalmazni ahol ennek világos célja van. A checkoutot például csak akkor tervezzük át egy webshop termékben, ha az az eltérés indokolt, különben használjuk a meglévő beépített flowt, amely minden bizonnyal tesztelt, jól működő és kiváló minőségű.

A folyamat során a designereknek gyakran kell egyeztetnie a fejlesztőkkel, és meg kell tanulniuk azt is, hogy az adott technológiában mit könnyű és mit nehéz megcsinálni - és ennek fényében kell dönteniük az egyes megoldásokról. Ha a fentieket betartjuk, akkor a fejlesztésen rengeteget spórolunk, mert egyrészt könnyebb lesz implementálni a felületet másrészt a keretrendszer gyári - alapostan kitesztelt, userek százezrei-milliói által használt - elemeinek alkalmazásával sokkal kevesebb UI hibával számolhatunk.

• A designerek rendszeresen egyeztessenek a felület fejlesztőivel! Ez a későbbi technikai csapat buy-inben is segít!
• Képezzétek a designereket, tartsatok közös workshopokat a fejlesztőkkel, használjátok az írott és videós formában elérhető rengeteg oktatóanyagot!

Ha szeretnél kimagasló digitális megoldással a piacra lépni, vagy szeretnél többet kihozni webes vagy mobil alkalmazásodból, UX designer szakembereink és tanácsadóink a segítségedre vannak. Szoftverfejlesztő cégként teljes körű IT szolgáltatást nyújtunk, a tervezéstől a megvalósításon át az üzemeltetésig és supportig. Vedd fel a kapcsolatot szakértőinkkel, hogy közösen megtaláljuk a legkedvezőbb megoldást!