Dobar UX poslovnog softvera smanjuje pogreške jer korisniku u pravom trenutku prikazuje stanje, dopuštene radnje i posljedice odluke. Ne pokušava pojednostavniti proces koji stvarno ima ovlasti, iznimke, povezane dokumente i financijske posljedice. Cilj je osobi omogućiti provedbu složenog zadatka bez nepotrebnog traženja, straha i ponovnog unosa.
To je važna razlika. Čišći ekran sam po sebi ne znači bolje korisničko iskustvo. Ako su bitne informacije skrivene iza kartica, ako status nije razumljiv ili se greška ne može ispraviti bez pomoći kolege, sustav je možda vizualno mirniji, ali je posao i dalje težak.
Poslovni softver često mora prikazati stvarna ograničenja procesa. Nalog može čekati odobrenje. Dokument može biti djelomično obrađen. Knjiženje može zaključati podatke ili utjecati na povezane evidencije. Te činjenice ne treba ukloniti iz sučelja jer bi korisnik tada odluku donosio bez potrebnog konteksta.
UX dizajn odlučuje kako će se ta složenost rasporediti:
Dobar kriterij nije broj elemenata na ekranu. Kriterij je može li osoba dovršiti stvarni zadatak uz dovoljno informacija i bez oslanjanja na privatne bilješke, poruke kolegama ili paralelne tablice.
Korisnik treba odmah razumjeti je li dokument nacrt, čeka li odobrenje, je li zaključan ili je poslan u sljedeći korak. Sam naziv statusa često nije dovoljan. Status treba odgovoriti na praktična pitanja: što mogu učiniti sada, što ne mogu učiniti i tko ili što čeka sljedeći korak.
Ako je stanje nejasno, nastaje skriveni operativni trošak. Korisnik ponovno otvara zapis, uspoređuje datume, zove kolegu ili vodi vlastitu evidenciju. Ti se prekidi rijetko vide u broju klikova, ali usporavaju obradu i povećavaju mogućnost da dvije osobe rade na pogrešnoj pretpostavci.
Vidljivo stanje ne zahtijeva prikaz cijele povijesti procesa na svakom ekranu. Sažetak može pokazati trenutačnu fazu, vlasnika sljedeće radnje i razlog blokade. Detaljna povijest može ostati dostupna kada osoba treba provjeriti prethodni korak. Time se zadržava kontekst bez stalnog opterećivanja radne površine.
Radnja poput zaključivanja naloga, slanja dokumenta ili knjiženja može promijeniti više dijelova sustava. Generičko pitanje o potvrdi ne objašnjava rizik i često postaje automatska prepreka koju ljudi zatvaraju bez čitanja.
Korisnija potvrda opisuje relevantnu posljedicu:
Ipak, upozorenje nije rješenje za svaku radnju. Dodatni modal može usporiti čest, niskorizičan korak. Za rijetku odluku s velikom posljedicom može spriječiti ozbiljnu pogrešku. Zato razinu upozorenja treba vezati uz rizik, učestalost i mogućnost oporavka, a ne uz naviku da se svaka radnja potvrđuje.
Kod svakodnevnog filtriranja popisa dokumenata korisnik obično ne treba dodatnu potvrdu. Rezultat se može odmah promijeniti, a uvjet se može lako ukloniti.
Kod knjiženja dokumenta sustav treba prije potvrde prikazati bitnu promjenu koju korisnik time pokreće. Ako postupak nije lako povratan, to mora biti jasno prije završne radnje. Ne radi se o stvaranju nesigurnosti, nego o tome da osoba odluku donosi s informacijom koja joj je potrebna.
Tablica s mnogo stupaca može biti dobar alat osobi koja uspoređuje odstupanja, rokove ili iznose kroz velik broj zapisa. Ista tablica može biti prepreka korisniku koji samo treba pronaći jedan dokument i provjeriti njegov status.
Univerzalni minimalizam zato nije dobar cilj. Korisniji pristup uključuje:
Smanjenje pogrešaka u poslovnom softveru često ovisi o tome vidi li osoba pravovremeno odstupanje, blokadu ili podatak koji nedostaje. Ako je važan signal skriven među jednakim elementima, korisnik ga može previdjeti i kada su svi podaci tehnički prisutni.
Prevencija ne može ukloniti svaku pogrešku. Korisnik može odabrati pogrešan zapis, izgubiti vezu, otvoriti zastarjeli dokument ili unijeti podatak koji ne prolazi poslovno pravilo. Sustav tada treba sačuvati uneseni rad kad god je to moguće, objasniti problem konkretnim riječima i ponuditi sljedeći korak.
Poruka koja samo kaže da je došlo do greške prebacuje dijagnostiku na korisnika. Korisnija poruka pokazuje polje, uvjet ili korak koji traži ispravak. Ako se dio rada ne može sačuvati, i to treba jasno navesti. Neizvjesnost o tome je li unos ostao zabilježen može stvoriti dupli rad ili dvostruku obradu.
Oporavak treba provjeriti i kod procesa s ovlastima. Korisnik može imati pravo pripremiti dokument, ali ne i zaključiti ga. Sučelje treba objasniti što može učiniti dalje, primjerice spremiti nacrt ili poslati zahtjev za odobrenje, bez pukog blokiranja radnje.
Za procjenu korisničkog iskustva nije dovoljno pitati sviđa li se korisniku ekran. Korisnije je pratiti cijeli stvarni zadatak, od početnog pronalaska zapisa do završetka i mogućeg oporavka.
Task-flow audit može bilježiti:
Takav pregled daje konkretniji prioritet od opće ocjene zadovoljstva. Ne govori samo da je rad težak, nego pokazuje gdje sučelje stvara dodatni rad i kakva je poslovna posljedica prekida.
Za složenije procese audit je korisno povezati s ERP i procesnim screeningom . Tada se problem može promatrati i kao pitanje tijeka rada, ovlasti, podataka i povezanih koraka, a ne samo kao pitanje izgleda pojedinog ekrana.
Prazan demo ekran rijetko otkriva problem. U stvarnom radu postoje dugi nazivi, velike tablice, stari zapisi, nepotpuni podaci i više otvorenih zadataka. Tek u takvom kontekstu postaje vidljivo može li korisnik pronaći signal, razumjeti stanje i nastaviti nakon prekida.
Test treba obuhvatiti najmanje tri situacije:
Promatrajte gdje osoba skenira ekran, što zapisuje sa strane i kada traži potvrdu od kolege. Nemojte je odmah podučavati. Prvo zabilježite što sučelje nije uspjelo objasniti. Nakon promjene ponovite isti zadatak te usporedite vrijeme, pogreške, prekide i broj traženih pomoći.
Vizualna preferencija može biti koristan dodatni signal, ali ne treba nadjačati dokaz da osoba sigurnije obavlja posao. Posebno testirajte korisnike različitog iskustva. Obrazac koji je brz stručnjaku može biti neprohodan osobi koja ga koristi jednom mjesečno.
Kupac poslovni softver ne procjenjuje samo na demo sastanku. Procjenjuje ga svaki dan kada korisnik pokušava dovršiti posao. Ako ljudi zaobilaze sustav, podaci slabe, izvještaji kasne, a proces se seli u poruke i zasebne datoteke.
ORKA pristup UX auditu počinje zadatkom, stanjem i posljedicom. Ne polazi od pretpostavke da složen proces treba sakriti, nego da ga treba učiniti provedivim. Kao sljedeći korak, odaberite jedan čest zadatak s vidljivim prekidima i prođite ga s korisnikom od početka do kraja. Zabilježite čekanje, prekid, pogrešku i oporavak prije nego što odlučite koje sučelje mijenjati ili koje poslovne module povezane s ERP-om treba dodatno uskladiti.