Daugelis organizacijų bent kartą yra bandžiusios įsidiegti vidinę sistemą. Tai gali būti klientų registravimo platforma, dokumentų valdymo įrankis, CRM ar specializuota sistema konkrečiam verslo procesui.
Pradžioje viskas atrodo logiška. Nauja sistema turėtų supaprastinti darbą, sumažinti klaidų skaičių ir automatizuoti pasikartojančias užduotis.
Tačiau realybė dažnai būna kitokia.
Po kelių mėnesių dalis darbuotojų vis dar dirba Excel lentelėse, informacija siunčiama el. paštu, o pati sistema tampa dar vienu papildomu sluoksniu vietoje realaus palengvinimo. Kartais ji naudojama tik formaliai, o tikrasis darbas vyksta kitur.
Tokiais atvejais problema retai būna technologija. Daug dažniau problema slypi tame, kaip sistema buvo suprojektuota ir kokią realią darbo logiką ji bandė perkelti į skaitmeninę formą.
TL;DR
Daugelis vidinių sistemų organizacijose neprigyja ne dėl technologijos, o dėl projektavimo klaidų. Sistema dažnai kuriama nuo funkcijų, o ne nuo realių darbo procesų. Vartotojai, kurie su ja dirbs kasdien, į projektavimą įtraukiami per vėlai arba visai neįtraukiami.
Kai ignoruojamas UX, sistema tampa sudėtinga, lėta ir sunkiai naudojama. Tokiais atvejais darbuotojai pradeda ieškoti alternatyvų – Excel, el. pašto ar kitų įrankių.
Tam, kad sistema veiktų, svarbu pradėti nuo procesų analizės, atlikti esamos sistemos UX auditą, remtis patikrintais metodais (pvz., Nielsen heuristikomis ar Baymard tyrimais) ir į projektavimo procesą įtraukti realius vartotojus. Gerai suprojektuota sistema sumažina kasdienį darbo krūvį ir tampa natūralia organizacijos darbo dalimi.
Problema dažnai prasideda dar prieš programavimą
Didelė dalis vidinių sistemų projektų prasideda nuo sprendimo, kad organizacijai „reikia sistemos“. Tačiau retai iki galo išsiaiškinama, kaip realiai vyksta darbas.
Kas įveda duomenis?
Kas juos tikrina?
Kas priima sprendimus?
Kur atsiranda daugiausia klaidų?
Kuriose vietose darbuotojai priversti kartoti tuos pačius veiksmus?
Jeigu šie klausimai nėra iki galo išanalizuoti, sistema tiesiog perkelia esamą procesą į skaitmeninę formą. Kartais net sukuria papildomų žingsnių.
Tokiu atveju skaitmenizacija neišsprendžia problemos – ji tik ją institucionalizuoja.
UX ignoravimas – viena dažniausių vidinių sistemų klaidų
Vidinės sistemos dažnai projektuojamos su mintimi, kad UX nėra kritiškai svarbus.
Kartais manoma, kad vartotojai yra darbuotojai, todėl jie „vis tiek turės naudotis“. Tačiau realybėje net ir privalomos sistemos gali būti apeinamos.
Jei sistema:
- sudėtinga
- reikalauja daug žingsnių
- sunkiai suprantama
- lėta
žmonės natūraliai pradeda ieškoti alternatyvų.
Čia labai tinka principas, kurį savo knygoje „Don’t Make Me Think“ išpopuliarino Steve Krug. Pagrindinė idėja paprasta: geras skaitmeninis produktas neturėtų versti vartotojo galvoti apie tai, kaip juo naudotis. Veiksmai turi būti akivaizdūs, logiški ir intuityvūs.
Šis principas galioja ne tik viešiems produktams ar e. komercijai. Jis galioja ir vidinėms sistemoms, kurios dažnai naudojamos daug intensyviau nei vieši įrankiai.
Jeigu darbuotojas kasdien praleidžia kelias valandas sistemoje, net mažos UX klaidos gali sukelti didelę frustraciją.
Kodėl svarbus senos sistemos UX auditas
Viena iš dažnai praleidžiamų projektavimo fazių yra esamos sistemos analizė.
Organizacijos dažnai nori kuo greičiau sukurti naują sprendimą, tačiau neįvertina, kas iš tikrųjų neveikė ankstesnėje sistemoje.
UX auditas leidžia įvertinti sistemą remiantis pripažintais standartais, pavyzdžiui:
- Nielsen Norman Group heuristikomis
- Baymard Institute UX principais
Tokie vertinimai padeda identifikuoti problemas, kurios dažnai nėra matomos iš pirmo žvilgsnio:
- neaiški navigacija
- informacijos perkrova
- per sudėtingi procesai
- nenuoseklūs veiksmai
- klaidų prevencijos trūkumas.
Tai leidžia ne tik suprasti, kas neveikia, bet ir išsiaiškinti, kokie sistemos elementai iš tikrųjų veikė gerai ir turėtų būti išsaugoti.
Realūs vartotojai dažnai pamirštami
Dar viena dažna priežastis, kodėl sistemos neprigyja, yra ta, kad projektavimo procese nedalyvauja žmonės, kurie sistema naudosis kasdien.
Sprendimus dažnai priima vadovai, IT komanda arba išoriniai tiekėjai. Tačiau tikrieji vartotojai įtraukiami tik projekto pabaigoje.
Tokiu atveju sistema gali atrodyti logiška projektavimo dokumentuose, bet realybėje neatitikti kasdienio darbo.
Labai vertinga informacija dažnai slypi ten, kur jos mažiausiai tikimasi – supporto komandoje, administracijoje ar klientų aptarnavime. Būtent šie žmonės kasdien susiduria su problemomis ir geriausiai mato, kur procesas stringa.
Pavyzdžiui, nekilnojamojo turto platformose labai svarbus vartotojas yra administratorė, kuri kelia skelbimus į sistemą. Jei naujoji sistema padidina darbo kiekį – reikia daugiau žingsnių, daugiau laukų ar daugiau rankinio darbo – ji iš karto pradeda kelti pasipriešinimą.
Tačiau jei sistema suprojektuota gerai, efektas būna priešingas. Darbas tampa paprastesnis. Informacija įvedama greičiau. Mažiau klaidų. Mažiau pasikartojančių veiksmų.
Tokiu atveju sistema pradeda veikti kaip tikras pagalbininkas, o ne papildomas darbas.
Usability testavimas – paprastas, bet labai efektyvus metodas
Dar vienas dažnai nepakankamai naudojamas metodas yra usability testavimas.
Net keli testai su realiais vartotojais gali atskleisti daug daugiau nei ilgi dokumentai ar techninės specifikacijos.
Testavimo metu galima stebėti:
- kaip vartotojai ieško informacijos
- kur jie pasimeta
- kokius veiksmus tikisi atlikti vienoje vietoje
- kur atsiranda klaidų.
Dažnai paaiškėja, kad sistema veikia visiškai kitaip, nei buvo planuota.
Tokios įžvalgos leidžia pataisyti produktą dar prieš jį įdiegiant visoje organizacijoje.
Gera sistema sumažina žmonių vargą
Galų gale verta prisiminti paprastą principą: sistemos kuriamos ne dėl technologijos.
Jos kuriamos tam, kad sumažintų žmonių vargą kasdienėje veikloje.
Kai sistema suprojektuota remiantis realiais procesais, vartotojų patirtimi ir nuoseklia UX logika, ji tampa natūralia darbo dalimi. Ji nebereikalauja papildomų pastangų – priešingai, ji pradeda taupyti laiką.
Todėl dauguma vidinių sistemų žlunga ne dėl technologijos ar programavimo klaidų. Jos žlunga todėl, kad bandoma automatizuoti procesą, kuris dar nėra iki galo suprastas.
Kai organizacija pradeda nuo procesų analizės, vartotojų patirties ir realaus darbo konteksto, sistema turi daug didesnę tikimybę tapti ne dar vienu projektu, o kasdieniu įrankiu, kuris iš tikrųjų padeda dirbti.
D.U.K.
Kas yra UX auditas ir kodėl jis svarbus kuriant naują sistemą?
UX auditas leidžia įvertinti esamą sistemą pagal pripažintus naudojamumo principus, pavyzdžiui Nielsen Norman Group heuristikas. Tai padeda identifikuoti vietas, kur vartotojai stringa, kur atsiranda klaidų ar nereikalingų žingsnių. Tokia analizė leidžia kurti naują sprendimą remiantis realiomis problemomis.
Ar būtina į projektavimą įtraukti realius vartotojus?
Taip. Žmonės, kurie sistema naudosis kasdien, dažnai geriausiai supranta realius darbo procesus. Be jų įžvalgų sistema gali būti techniškai teisinga, bet praktiškai nepatogi.
Kas yra usability testavimas?
Usability testavimas lietuviškai dažniausiai verčiamas kaip naudojamumo testavimas. Tai metodas, kai realūs vartotojai bando atlikti konkrečias užduotis sistemoje ir stebima kaip jiems sekasi ja naudotis.
Tokio testavimo metu vertinama, ar sistema yra aiški, ar vartotojai lengvai randa reikiamas funkcijas, kur jie pasimeta ir kokiose vietose atsiranda klaidų. Net keli trumpi testai gali atskleisti problemas, kurios projektavimo metu nepastebimos.
