Šiuo straipsniu siekiu glaustai pateikti ir tuo pat metu sau išgryninti aktualiausius mitus apie unikalių IT sistemų naudotojo sąsajos dizainą (toliau UI dizainą, angl. user interface). Straipsnis turėtų būti aktualus visiems, kurie kuria, perka ar domisi unikaliais IT sprendimais. Jaučiu atsakomybę kalbėti apie tai, nes matau, kad supratimas skiriasi ne tik perkančiųjų, bet ir sprendimų kūrėjų tarpe.
Šiuo straipsniu siekiu glaustai pateikti ir tuo pat metu sau išgryninti aktualiausius mitus apie unikalių IT sistemų naudotojo sąsajos dizainą (toliau UI dizainą, angl. user interface). Straipsnis turėtų būti aktualus visiems, kurie kuria, perka ar domisi unikaliais IT sprendimais. Jaučiu atsakomybę kalbėti apie tai, nes matau, kad supratimas skiriasi ne tik perkančiųjų, bet ir sprendimų kūrėjų tarpe.
Vis dar yra manančių, kad naudotojo sąsajos (angl. User interface, toliau – UI) dizainas yra vienkartinis, kosmetinis informacinės sistemos „pagražinimas“. Dažniausiai taip galvoja su profesionaliu dizainu nieko bendro neturintys žmonės. Iš tikrųjų, jie nei klysta, nei yra teisūs. Informacinės sistemos naudotojai ar užsakovai neprivalo žinoti koks turi būti dizaino procesas, kas jame turi dalyvauti ir kaip turi būti pasiekiamas rezultatas, svarbiausia – kad dizaino kūrimo procesas keltų teigiamas emocijas, o sukurtas rezultatas – puikų patyrimo jausmą naudojantis sistema. Čia labai svarbi mūsų, dizainerių, misija – paaiškinti, iš kokių veiklų susideda UI dizaino procesas, kaip kiekvienas etapas veda į tikslą ir kaip geru sistemos veikimu suinteresuoti žmonės gali prisidėti prie siekiamo rezultato.
Žemiau aptariu keletą UI dizaino mitų, su kuriais dažnai susiduriu savo kasdieniame darbe.
Mitas nr. 1: UI dizainas kuriamas tam, kad suteiktų klientui malonų pirmąjį įspūdį apie sistemą
Pirmasis įspūdis yra neabejotinai svarbus (jį suformuoti turime tik vieną šansą) – ir jam labiausiai daro įtaką sistemos išvaizda. Visgi, klaidingai manoma, kad UI dizaino esmė yra tai, kaip sistema atrodo, o ne kaip veikia naudotojo sąsaja. Koks yra jos atsakas į naudotojo veiksmus atliekant užduotį? Kaip ji padeda naudotojui atlikti užduotį? Ar parinkti naudotojui suprantami terminai, frazės? Ar naudotojui akivaizdu, kaip išsaugoti užpildytą formą, sugrįžti į pradinį langą ir pan. Kuriant UI dizainą, visas sistemos veikimo modeliavimas yra paremtas atsakymų į šiuos klausimus paieška, o tais atvejais, kada tenka rinktis, ar aukoti subjektyviai gražią sistemos išvaizdą vardan patogesnės vartotojo sąsajos, UI dizaineris visuomet pasisakys už pastarąjį pasirinkimą.
Iš tiesų geras sistemos veikimas yra ilgas ir sudėtingas, glaudaus tarpusavio bendradarbiavimo reikalaujantis uždavinys, o ne vienkartinis „gražaus“ lango sudėliojimas. Pirmiausiai, įsigilinama į naudotojo tikslus ir veiklas, suprantama jų esmė, suvokiama, kokiame kontekste bus naudojamas produktas. Iš to gali kilti papildomi reikalavimai UI dizainui, pvz. – turi būti galimybė tam tikras veiklas atlikti naudojantis mobiliais įrenginiais. Atlikus pradinę naudotojų ir jų veiklos analizę, kuriami eskizai, kuriuose bandoma eskizuoti tos pačios problemos sprendimą skirtingais būdais, kad vėliau, diskusijų metu, išsiaiškintume, kuris būdas geresnis. Galiausiai, kuriamas interaktyvus HTML prototipas, kuris testuojamas su naudotojais, prašant jų atlikti realias užduotis ir taip atrandami prototipo trūkumai, kurie vėliau taisomi, kol pasiekiamas galutinis rezultatas.
Tuo metu skirtingas dėmesys UI išvaizdai labai priklauso nuo konkretaus atvejo. Pvz., jei kuriamas masinio naudojimo produktas rinkai, kurioje jau yra panašių produktų su stipriu dizainu – suprantama, kad, siekiant sėkmės, reikės skirti daug dėmesio detalėms ir dizainui. Jei produktas kuriamas naudojimui uždaroje naudotojų grupėje, neturi konkurentų su stipriu dizainu ir ypatingų reikalavimų išvaizdos prasme – UI išvaizdai galima skirti mažiau dėmesio.
Taigi, nors estetika yra svarbus veiksnys, tačiau patogumas UI dizaino procese visuomet yra pirmoje vietoje.
Mitas nr. 2: Klientas geriausiai žino kokia turi būti UI išvaizda
Taip, kliento žodis lemiamas, bet greičiausiai klientas neturi grafikos/dizaino/UI kūrimo žinių ir patirties, kitaip jis neprašytų mūsų pagalbos. Bet kokios srities profesionalų darbas yra įsigilinti į tikruosius kliento poreikius ir, remiantis žiniomis, patirtimi ir sveika nuovoka, suformuluoti jo poreikius geriausiai atitinkantį sprendimą. Būtent tokia, mano nuomone, yra ir UI dizainerių atsakomybė – įsigilinti į problemą, rasti geriausią įmanomą sprendimą ir padėti klientui suprasti, kodėl vienokia ar kitokia UI išvaizda jiems tinkamiausia.
Kuriant naudotojo sąsają, pirmiausiai reikėtų atlikti namų darbus, kad nesulauktume pirminės atmetimo reakcijos – išnagrinėti kliento firminį stilių, tinkamas/patinkančias spalvas ir panašius, daugiausiai emociškai vertinamus, elementus. Naudotojo sąsajos demonstracijos metu turėtume papasakoti kūrimo ir pasirinkimų kontekstą, istoriją, kodėl priėmėm vienokius ar kitokius UI išvaizdos sprendimus per aktualiausią klientui prizmę – kaip tai padės jiems pasiekti savo tikslus.
Taip pat, pirmąkart demonstruojant naudotojo sąsajos išvaizdą labai svarbūs tinkami klausimai, padedantys toliau vystyti sistemos išvaizdą, o ne vedantys į abstrakčius, subjektyvius ir, paprastai, ilgai bei nuobodžiai trunkančius apmąstymus. Šioje vietoje labai svarbus konkretumas. Prašydami grįžtamojo ryšio apie išvaizdą turėtume formuluoti konkrečius klausimus, pvz., ar šis dizaino variantas pakankamai gerai atspindi jų firminio stiliaus spalvinę gamą? Ar šios besikeičiančios nuotraukos pradiniame lange pakankamai gerai atspindi jūsų lūkestį išsiskirti iš konkurentų inovatyvumu ir kūrybingumu?
Mitas nr. 3: Dizaineris gali sukurti patogią naudotojo sąsają be naudotojų įtraukimo. Jam užtenka veiklos diagramų ir susitikimų su klientais
Jei dizaineris užsiima UI dizainu nepažinęs naudotojų, nesuprasdamas jų tikrųjų problemų ir nežinodamas konteksto – kas, kokiomis aplinkybėmis, su kokia motyvacija naudosis sistema, tai rezultatas geriausiu atveju gali vadintis „skaitmeniniu menu“ (šį taiklų terminą pamėgau perskaitęs puikų Paul Adams straipsnį), o ne UI dizainu.
Dizainas prasideda tada, kai yra ketinimas išspręsti konkrečią naudotojų grupės problemą, suprantant jos esmę ir nuolat ieškant geriausio sprendimo būdo.
Nuolat galvoti apie naudotojus priimant UI dizaino sprendimus nėra lengva. Naudotojų ir Užsakovų įsivaizdavimas apie problemas ir jų sprendimus greičiausiai skirsis. Todėl efektyviam naudotojų įtraukimui rekomenduojama naudoti personų aprašymus. Persona – tai vienos naudotojų grupės apibūdinimas realiais duomenimis aprašant vieną fiktyvų asmenį, labiausiai atspindintį visos grupės charakteristikas. Aprašymai pradedami kurti analizės etape ir vėliau projekto eigoje nuolat papildomi. Personų nauda atsiskleidžia priimant dizaino kompromisus tarp dizainerių ir programuotojų. Jos įgalina komandą susitelkti ties naudotojų tikslais ir iš tikrųjų jais remiantis priimti sprendimus. Priešingu atveju, paliekama galimybė daugumą dizaino sprendimų priimti remiantis subjektyvia asmenine komandos narių patirtimi ir įsivaizdavimu.
Mitas nr. 4: Patogi naudotojo sąsaja sukuriama iš pirmo karto
Iš patirties supratau, kad iš pirmo karto dažniausiai gaunasi variantas, kuris greitai tampa atspirties tašku tobulinimui, nes tik jį sukūręs pamatai, ką jame galima patobulinti. O ką patobulinti būna visada. Todėl svarbu iteruoti. O naudotojo sąsajos iteracijų iniciatorius turi būti naudotojo sąsajos dizaineris. Pagrindinis klausimas – ar tam numatyta pakankamai laiko. Geram UI dizainui sukurti reikia aiškaus problemos matymo, o jis gilėja tik laikui bėgant, suvokiant, kaip tą pačią problemą mato skirtingi žmonės ir taip praplečiant savo suvokimą. Patirtis rodo, kad projekto pradžioje nepavyks išsiaiškinti visų dalykinės srities niuansų, todėl – sukurti ir geros naudotojo sąsajos. Praktika rodo, kad net bandomosios eksploatacijos etape atsiranda tobulinimo galimybių. Jų atsiranda ir sistemą paleidus, jų bus visada. Deja, kai projektai turi fiksuotą biudžetą ir užbaigimo terminus, naudotojo sąsajai, kaip ir bet kuriai kitai su sistemos kūrimu susijusiai veiklai, yra griežtai apribotas laikas. Tad svarbu realiai įvertinti, ką galima padaryti per tą laiką ir parinkti tinkamiausias veiklas.
Mitas nr. 5: Naudotojo sąsają galima kurti be realių duomenų
Būtent ši prielaida projekto eigoje gali tapti dideliu galvos skausmu, kai į sistemą pagaliau pradedami vesti realūs duomenys.
Todėl būtina naudoti realius, nuasmenintus duomenis jau projektavimo etape, kuriant eskizus ir prototipus, nes:
- realūs duomenys parodo tuos naudotojo sąsajos trūkumus, kurių be realių duomenų neatrastume. Dažnai tai susiję su UI elementų išdėstymu;
- naudotojai testavimų metu greičiau orientuojasi sistemoje pagal jiems pažįstamą turinį ir tokiu būdu prototipo komunikacija tampa efektyvesnė.
Čia labai tinka pacituoti Jeffrey Zeldman „Dizainas yra turinio išdava. Dizainas be turinio tėra dekoracija“ („Content precedes design. Design in the absence of content is not design, it‘s decoration“):
Skaitytojams turėtų kilti logiškas klausimas: Kaip greitai įkelti į prototipą realius duomenis? Labai priklauso nuo to, kaip prototipas kuriamas. Aš kuriu statinius HTML puslapius ir duomenis juose įkeliu rankiniu būdu. Pvz., jei tai sąrašas, užtenka keleto skirtingų duomenų eilučių, kurios toliau kartojasi. Tai atima laiko. Bet tuo pačiu jį sutaupo, nes prototipai tampa suprantamesni.
Tai, apie ką rašau, man pačiam kiekviename projekte yra siekiamybė. Nelengva pasiekti tikruosius sistemos naudotojus, nelengva rasti teisingus argumentus, kodėl parinktas dizainas yra geriausias.
Kiekviena programinius sprendimus kurianti įmonė laikui bėgant praeina tam tikrus brandos lygius dizaino atžvilgiu. Iš pradžių siekiama, kad naudotojo sąsaja būtų graži, vėliau siekiama, kad ji būtų patogi naudotis ir galų gale siekiama sukurti produktą, kuris ne tik padeda pasiekti naudotojo tikslus, bet dar ir suteikia puikų patyrimą. Labai daug priklauso ir nuo įmonės vadovų požiūrio į dizaino svarbą, o požiūrį keičia ne tik laikas, bet ir argumentai. Tikiuosi, šioje apžvalgoje pateikti argumentai padės geriau suprasti, kaip kuriamos patogios naudotojo sąsajos ir kodėl tai yra svarbu.
