#4 prispevok…UX vs. eGOV v SR

Dna 21.6.2016 sa konal pod hlavickou Slovenskej user experience asociacie diskusny panel (SUXA) zamerany prave na UX a jeho miesto v informacnych systemoch a elektronickych sluzbach statu. Diskusia priniesla zaujimave pohlady na danu temu a otvorila viacero otazok. Cely event bol planovany na cca 90 minut, no nakoniec diskusia trvala cez 120 minut. Osobne ma tesi, ze eventu sa zucastnilo viacero ludi za stranu statu, otvorene priznali svoju ucast a ich pracovne zaradenie.

Bol som jednym z ucastnikov panelovej diskusie, reprezentoval som prave stranu statu, nakolko v ramci projektu ITMS2014+ realizujeme aktivity spojene s UX testovanim priamo na koncovych pouzivateloch.

Moje skusenosti, poznatky, faily z oblasti UX som uz dlhsie planoval zdielat aj v ramci samostatneho blogoveho prispevku. Tento prispevok teda reaguje na temy a otazky, ktore sa otvorili v ramci diskusneho panelu, ale aj na take, ktore sa v ramci diskusie neotvorili alebo sa iba jemne nacrtli.

Preco sme robili UX testovanie?

UX sme realizovali v podstate na zaklade tychto podnetov:

• trapeni sa mojej mamky s inymi informacnymi systemami verejnej spravy (napr. www.drsr.sk, www.statistics.sk) a jej ustavicnym vysvetlovanim mi, ze “hento a tamto” by mohlo byt inak, ze “tamtomu” nerozumie, a pod.,
• “osvietenim/uvedomenim si”, ze podobne asi reaguju aj nasi pouzivatelia na nas system,
• a potom obkukavanim aktivit, ktore sa robia v zahranici, napr. v ramci GDS alebo 18F.

Ale primarny dovod bol naozaj ten, ze chceme lepsie spoznat nasho pouzivatela, overit si, ci danemu rieseniu rozumie a ak nie, tak preco mu nerozumie, co mozeme spravit a zlepsit, aby rieseniu porozumel a pod. Proste ziskat feedback priamo od koncoveho pouzivatela, dodat lepsi produkt a minimalizovat riziko neuspechu. Plus ukazat, ze aj v ramci statneho IT projektu a to dokonca v SR je mozne taketo aktivity realizovat a z podnetu statu ako zakaznika.

Kedy je efektivne realizovat UX?

My sme zrealizovali viacero typov a metod UX testovani. Testovali sme najdolezitejsie formulare a funkcionality systemu, s ktorymi pracuje verejnost. Testovali sme informacnu architekturu formularov, s ktorymi pracuju zamestnanci statu.

Testovane boli teda formulare, funkcionality systemu, ktore v case testovania uz boli uvolnene do produktivnej prevadzky.

Uz na tomto mieste musim povedat, ze tieto testovania mali byt realizovane ovela, ovela skor. Idealne by tieto testovania mali byt realizovane uz pri draftovani a dizajnovani formularov, pri nastavovani procesov, metodik a legislativy, t.j. testovane by mali byt vsetky tie elementy, na zaklade ktorych nejake IT riesenie vznika. Cize v ramci UX nejde len o testovanie finalneho IT riesenia.

Dovody su velmi jednoduche:

1. ovela skor vychytate chyby, nezrozumitelnosti navrhovaneho formularu, procesu a to hlavne zo strany realneho pouzivatela,
2. identifikujete vela poziadaviek zo strany realneho pouzivatela a prave tieto poziadavky zasadne ovplyvnia pohlad pouzivatelov na vas system, sluzbu,
3. lepsie si zprioritizujete poziadavky,
4. a usetri vam to vyrazny objem financnych prostriedkov na projekte.

Ako som pisal vyssie, my sme robili testovanie na uz existujucich formularoch a funkcionalitach systemu. Kazda chyba, nejasnost, nezrozumitelnost alebo navrh na zmenu identikovany v ramci UX testovania pre nas teraz znamena dodatocne naklady. Cize v tejto chvili uz vyberame iba tie najkritickejsie a potom tie najlahsie implementovatelne zistenia, odporucania. Niektore uz v tomto stadiu projektu ani nie je mozne zapracovat, nakolko je uz na ne “neskoro” a znamenalo by to velku prerabku systemu a znacne mnozstvo finanych prostriedkov vynalozenych neefektivne. Pri tych, ktore sa nakoniec rozhodneme implementovat, tak automaticky narazame na dalsi z problemov a to je zaradenie do planu a co najrychlejsie uvolnenie do produktivnej prevadzky.

Cize nacasovanie tejto aktivity je velmi dolezite. Idealne je UX testovanie realizovat este pred startom projektu alebo v jeho rannych fazach, ale urcite najneskor pred zacatim vyvoja, programovania konkretnej casti, funkcionality systemu. Co najmenej UX aktivit by malo byt realizovanych na tych castiach a funkcionalitach systemu, ktore uz su v produktivnej prevadzke.

Ake vyhody/nevyhody UX prinasa zakaznikovi/projektu?

Vyhody (vypisane random a urcite ich je viac ako uvadzam):

• lepsie spoznanie pouzivatela a typologizacia pouzivatelov,
• feedback priamo od realnych pouzivatelov,
• lepsie pochopenie potrieb a poziadaviek realnych pouzivatelov,
• lepsie planovanie, prioritizacia vyvoja systemu a moznost agilnejsieho fungovania projektu,
• vytvorenie si backlogu z poziadaviek realnych pouzivatelov,
• vychytanie majoritnej vacsiny nejasnosti, chyb, nezrovnalosti a pod. systemu — statistiky dokazuju, ze testovanie na 6 pouzivateloch identifikuje viac ako 70% zakladnych nejasnoti, chyb systemu,
• overovanie, testovanie si planovanych funkcionalit, uprav systemu priamo na vzorke pouzivatelov — ked uz mate databazu pouzivatelov/testerov, tak na nich mozete testovat prototypy, navrhy novych funkcionalit, nazvoslovie a pod.,
• uspora casu a financnych prostriedkov,
• a teda vytvaranie produktu, ktory “sedi” pouzivatelom, nakolko vznika na zaklade ich poziadaviek,
• a urcite dalsie…

Nevyhody:

• pripravte sa na kritiku a nie iba konstruktivnu,
• pripravte sa na caste sklamanie — pouzivatel casto vasu “super funkcionalitu” bude povazovat za uplny nezmysel, ktory mu je v podstate nanic,
• viac nevyhod som ja zatial neidentifikoval…ak Vy poznate ine, tak mi dajte vediet, rad sa poucim.

Co som sa ja osobne naucil a co mozem odporucat?

UX mi ukazalo, ze aj najmensie nezrozumitelnosti ako napr. otazne pomenovanie buttonu alebo zly vyber ikony mozu sposobit, ze pouzivatel nie je schopny zrealizovat potrebne kroky v systeme a tak nedokonci a nevyuzije danu sluzbu a nakoniec ju kvoli malickosti povazuje za zlu, chybnu, nepouzitelnu.

Ale dolezitejsie je to, ze vy ako tvorcovia uvedeneho systemu, sluzby ste od urciteho okamihu uz slepi, vsetko uz v danom systeme robite zpamati, prehliadate vela nejasnosti, chyb, nezrozumitelnosti, vsetko povazujeze za zrozumitelne a pod. UX testovanie v tomto nastavuje zrkadlo a vracia vas spat na zem, do reality.

Netreba testovat cele IT riesenie. Treba hladat to najcennejsie a z minima ziskat maximum. My sme si vybrali tie formulare a funkcionality, s ktorymi pracuje najvacsi pocet pouzivatelov a pouzivaju sa na dennej baze. Funkcionalitu, ktoru pouziva napr. 10 ludi v celej SR a to do konca na strane statu, nema vyznam testovat. Takyto pocet ludi je jednoduchsie vyskolit za 2 hodiny a je pokoj.

Plus sa osvedcilo, ze je fajn otestovat patterny, ktore sa v ramci IT systemu opakuju. Napr. nejaky opakujuci sa typ tlacidla, use case a pod. Ak ho otestujem a pouzivam ho aj na dalsich miestach systemu, tak zistenia pre testovanu cast sa daju vacsinou aplikovat aj na tie casti aplikacie kde je opatovne pouzity.

Data driven design, development. Odporucam, co najskor zacat zbierat udaje napr. prostrednictvom Google analytics. Sledovat, co pouzivatelia naozaj pouzivaju a co nie. Zozbierane data pomahaju v rozhodovani sa, do ktorych casti, funkcionalit systemu sa oplati investovat cas a peniaze, do ktorych nie. Zaroven vas mozu naviest, aby ste zistovali, preco pouzivatelia niektoru z casti, funkcionalit systemu nepouzivaju. Vzdy je lepsie a lahsie robit rozhodnutia na zaklade overitelnych dat s urcitou mierou statisticky vypovedatelnej hodnoty ako na zaklade nejakych dohadov a subjektivnych domnienok. Na tomto aktualne pracujeme, nakolko sme to na zaciatku projektu neurobili a prave teraz nam to chyba…

UX nie je liek na vsetko a treba sledovat aj ine symptomy, priznaky. Nie je dobre sa spoliehat na to, ze ked sa v ramci projektu zrealizuje nejaky typ UX testovania, tak zarucene bude IT system “odsudeny” na uspech. Treba sledovat zaroven dalsie suvislosti. Napr. vyssie uvedena datova analytika vie ukazat, ze aj ked funkcionalita systemu v ramci UX testovania dopadla dobre, tak nakoniec zo strany pouzivatelov nie je vyuzivana a pod. Nam sa osvedcilo este aj napr. sledovanie hlaseni o podporu pouzivatelov.

Ma UX miesto v informacnych systemoch a elektronickych sluzbach statu?

Musi mat!!! Som nazoru, ze tvorba sluzieb v ramci statnych IT systemov bez testovania priamo na realnych a konecnych pouzivateloch je systemovou chybou. Ide o velke zlyhanie ci uz vlastnika systemu, teda statu, alebo firmy, ktora je zodpovedna za dodanie daneho IT systemu.

Otvorte si portal www.slovensko.sk a pohrajte sa s vyhladanim sluzieb na zaklade jednotlivych kategorii (pozn. podla mna aktualny stav je uz ovela lepsi ako predosly). Skuste sa zamysliet, ci by ste nahodou Vy niektore sluzby nezaradili pod ine kategorie, alebo tie kategorie na zaklade zaradenych sluzieb inak nepomenovali a pod. Sygic riesil a velmi dobre vyriesil podobny problem v ramci ich navigacie, vid nasledujuce video. Teraz si predstavte, ze napr. spominana kategorizacia sluzieb na www.slovensko.sk by bola otestovana podobne ako v pripade Sygicu a to na stovkach a az tisickach pouzivateloch, respondentoch…

Vie byt odborna verejnost, napr. SUXA, napomocna statu v tejto oblasti?

SUXU vnimam hlavne v roli evanielizatora UX v statnych IT projektoch. SUXA ako odborna entita vie svojimi aktivitami pomoct zvysovat know-how odbornych kapacit statu. Pri navrhnuti zaujimaveho a systematickeho modelu spoluprace so statom si viem predstavit budovanie odbornych kapacit na strane statu a nasledne aj zmenu myslenia ludi v statnej sprave a nakoniec mozno aj vznik zaujimavych a na pouzivatela orientovanych IT systemov a sluzieb s jasne stanovenymi a meratelnymi cielmi.

Moct sa vratit spat a mat tak pred 3–4 rokmi znalosti a skusenosti z oblasti UX ako mam dnes. Keby niekto vtedy prisiel a ponukol mi moznost ziskat urcitu uroven znalosti v tejto oblasti a ja by som vtedy pochopil, co presne znamena UX, ake metody testovania existuju, co ktora metoda prinasa a na co je vhodna a kedy v ramci zivotneho cyklu projektu je ju idealne aplikovat… Uplne inak by som nasledne premyslal nad ITMS2014+.