Kuka meistä on nähnyt ja/tai käyttänyt yritysohjelmistoa, joka näyttää siltä kuin se olisi tehty 90-luvulla? Jos olemme rehellisiä, monet niiden toiminnoista todennäköisesti rakennettiin silloin.

Miksi hyväksymme surkeat käyttöliittymät ja käyttäjäkokemukset yritysohjelmissamme? Erityisesti kun olemme äärimmäisen kriittisiä sovelluksille, joita käytämme päivittäin, kuten Netflix, Spotify, sosiaalinen media jne.

Lopetamme yleensä sellaisten ohjelmistojen käytön, joissa on huono käyttäjäkokemus, koska markkinoilla on parempi vaihtoehto. Kyseiset yritykset tapaavat mennä konkurssiin asiakkaiden ja käyttäjien puutteen vuoksi.

Eikö meidän pitäisi keskittyä hyvään käyttöliittymään (UI) ja käyttäjäkokemukseen (UX) myös sisäisten ohjelmistojen tuotekehityksessä? Etkö sinäkin haluaisi työskennellä ohjelmistolla, joka on vankka ja tarjoaa hyvän käyttäjäkokemuksen?

Mielestäni vastaus on selvä kyllä. Silti sisäisissä, mittatilaustyönä tehdyissä ohjelmistoissa on niin usein huono käyttöliittymä.

Työntekijät, jotka käyttävät huonon käyttäjäkokemuksen ohjelmistoa, eivät useinkaan edes tajua, kuinka paljon se kuormittaa meitä.

Kuvittele käyväsi läpi pitkää prosessia blogikirjoituksen kirjoittamiseksi tai sivun muokkaamiseksi, vain jotta se katoaisi jonkin ohjelmistovirheen vuoksi? Se on resurssien tuhlausta sekä työntekijän että työnantajan näkökulmasta. Se on työntekijälle lannistavaa ja turhauttavaa, kun työn joutuu tekemään uudelleen, ja työnantaja joutuu maksamaan samasta työstä kaksi kertaa.

Vaatimukset ja budjetointi // RFP

Tarkastellaan asiaa budjetoinnin ja tarjouspyynnön (RFP, request for proposal) vaatimusten keräämisen näkökulmasta. Olet kerännyt liiketoiminnallesi kriittisiä vaatimuksia, mutta jättänyt käyttöliittymän tavallaan taka-alalle.

Koska ohjelmiston pitää vain saada asiat hoidettua, eikä UI ja UX ole tähän välttämätöntä, eihän?

Saatat joutua maksamaan enemmän ohjelmiston hyvästä suunnittelusta, ja budjetin perusteleminen voi olla vaikeampaa. Kysyisin tässä kohtaa: oletko tarkastellut asiaa käyttäjän näkökulmasta?

Tarinahetki

Etenet suunnitelman mukaan ja selaat tarjouspyynnön vastauksia. Hylkäät monet niistä pelkästään hinnan perusteella. Kunnes törmäät yhteen, jossa ei mainita käyttäjäkokemusta. Myös hintalappu on pienempi. (Näin asiat toisinaan vain menevät.)

Valitset tämän yrityksen, ja muutaman kuukauden kuluttua ensimmäisen version koulutus alkaa loppukäyttäjille. Kehittävä yritys käy läpi palautteen ja tarkastaa ohjelmiston. Navigointipaneelissa on 60 kohtaa…

Pienten muutosten toteuttamisen ja ohjelmiston käyttöönoton jälkeen kaikki on hiljaista muutaman päivän ajan. Tuottavuus on laskenut. Kyseessä on kuitenkin uusi järjestelmä, joten vauhtiin pääseminen ottaa aikansa.

Sitten kysymykset alkavat todella vyöryä sisään.

”Miten voin tehdä…”

”Missä on yleisnäkymä…”

”Vanhassa järjestelmässä tämä onnistui helposti…”

Lähetät kaiken tämän takaisin yritykselle. He korjaavat asiat ja esittelevät päivitetyn ohjeistuksen ohjelmiston käyttöön. Kymmenien sivujen mittainen manuaali siitä, miten asioita tehdään.

Varmasti osa oppii sen nopeammin kuin toiset, ja he yrittävät sitten auttaa muita. Ne, jotka oppivat nopeimmin, opettavat sen aikanaan uusille työntekijöille.

Mieti, kuinka paljon resursseja tarvitaan kaikkien saamiseksi mukaan, tuottavuuden palauttamiseksi sekä turhautumisen ja motivaation puutteen käsittelemiseksi. Ovatko nämä niitä kustannuksia, joita haluat maksaa tulevaisuudessa säästettyäsi minimaalisesti suunnittelussa?

Kognitiivinen ergonomia työntekijöille (Ratkaisu)

Yritykset maksavat suuria summia, jotta työpisteet olisivat mahdollisimman ergonomisia tuottavuuden lisäämiseksi. Miten tai miksi tämä ei ole käytäntönä myös ohjelmistoissa, joita he käyttävät? Sieltähän se raha tulee.

Toimistoihin, työpisteisiin ja vastaaviin panostaminen johtaa paljon tyytyväisempiin työntekijöihin, mikä puolestaan lisää tuottavuutta. Käy järkeen, eikö?

Miten tässä pitäisi edetä? Tarkastellaan asiaa UX-tarvehierarkian näkökulmasta.

UX-tarvehierarkia

Fysiologinen

Kuinka pitkä ruutuaika on ohjelmiston käytön vuoksi? Onko tieto helppolukuista kaikille riippumatta erilaisista näkökyvyistä, jotta käyttäjän silmien rasitus vähenee? Kuinka monta klikkausta tarvitaan jonkin asian löytämiseen, ja onko navigointi intuitiivinen? Kuinka paljon käyttäjän on muistettava asioita ulkoa sen sijaan, että ohjelmisto ohjaisi heitä?

Turvallisuus

Psykologisen turvallisuuden tunne – tuntevatko he olevansa valvottuja tai tarkkailun alaisina? Onko ohjelmisto luotettavasti verkossa ja sisältääkö se automaattisen tallennuksen, jotta työ ei katoa, jos jotain menee pieleen? Pääsy henkilötietoihin? Voiko joku ulkopuolinen haksata sen?

Sosiaaliset tarpeet (Yhteenkuuluvuus)

Vapauttaako ohjelmisto aikaa työstä ja mahdollistaa yhteydenpidon työkavereiden kanssa? Käyttävätkö ihmiset yhteistä sanastoa? Työskentelevätkö he samaa tavoitetta kohti?

Arvostus

Kertooko ohjelmisto, jos työntekijä on tehnyt hyvää työtä? Nämä voivat vahvistaa työntekijän tyytyväisyyden tunnetta ja auttaa motivaatiossa. Myös sen näkeminen, jos he ovat ylittäneet itsensä tai päivän arvioidun työmäärän.

Itsensä toteuttaminen

Edistääkö ohjelmisto organisaation missiota vai haittaako se sitä? Voiko vaikutusta missioon mitata? Onko olemassa uusia mahdollisuuksia ongelmien ratkaisemiseen, palautteen antamiseen ja työn merkityksellisyyteen?

Opit

Kun keräämme vaatimuksia tarjouspyynnöön, sivuutamme usein vaiheen, jossa menisimme käyttäjien luo ja kysyisimme, mikä voisi olla paremmin, mikä on hyvää ja mikä ei toimi. Tätä vaihetta ei voi korostaa liikaa.

Et ole heidän työnsä asiantuntija, joten älä teeskentele tietäväsi, miten he työskentelevät. Mene ja kysy. Tämän tekeminen saa heidät myös sitoutumaan projektiin ja lopputulokseen paremmin. Se tekee projektista kaiken kaikkiaan paremman alusta loppuun.

Kun suunnittelet uuden ohjelmiston rakentamista, muista ajatella jatkuvasti suunnittelua ja loppukäyttäjää. Loppukäyttäjät ovat tärkeimpiä ihmisiä riippumatta siitä, mikä projekti on kyseessä.

Ajattele koko ohjelmiston elinkaarta, älä vain julkaisuun tai käyttöönottoon asti.