Joskus (eikä aivan harvoinkaan) käy niin, että organisaatiossa investoidaan merkittävä määrä rahaa ja aikaa tietovaraston ja raportoinnin rakentamiseen. Kun kaikki on valmista saatetaan huomata, että käyttäjät eivät syystä tai toisesta käytäkään tehtyjä raportteja tai dashboardeja. Tilanne on surullinen, mikäli paljon raportoinnin eteen tehtyä työtä valuu hukkaan. Syynä on tyypillisesti se, että kehitysvaiheessa loppukäyttäjä on päässyt unohtumaan tyystin. Siksi on tärkeää varmistaa projektin alusta loppuun, että tehty työ johtaa loppukäyttäjälle hyödylliseen tulokseen.
Kun halutaan varmistaa, että dashboard vastaa käyttäjän todellisia tarpeita, on tärkeää tuntea käyttäjäryhmät ja heidän tarpeensa hyvin. Älä luota omaan intuitioosi tai toisen käden kertomuksiin, vaan tutustu todellisiin käyttäjiin ja heidän tarpeisiinsa. Kuuntele käyttäjää. Tärkeintä on varmistaa, että kehitystyö on ratkaisemassa oikeaa ongelmaa, eikä jotakin oletettua ongelmaa, tai toistamassa jotain, mitä tehtiin aiemmassa ratkaisussa.
Kuvagrafiikka: Designed by Freepik (www.freepik.com)
Pyri keskusteluyhteyteen todellisen käyttäjän kanssa
Kun tämä yhteys on olemassa, esitä avoimia kysymyksiä ja kuuntele. Älä tarjoile oletettuja vastauksia heti aluksi, sillä tällöin ohjaat keskustelua ja käyttäjää ja käyttäjän todelliset tarpeet saattavat jäädä huomaamatta. Keskity ratkaisuun vasta kun olet ymmärtänyt käyttäjän todelliset tarpeet. Kun saat tietoa käyttäjän tarpeesta kannattaa se kirjoittaa auki käyttäjätarinan muotoon: ”As a … I want to … so that …”.
Kuva: Designed by Freepik (www.freepik.com)
Esimerkiksi näin:
”Osaston X myyntimiehenä haluan tuntea tärkeimpien asiakkuuksieni ajantasaisen varastotilanteen, jotta tiedän mihin asiakkaaseen minun tulee ottaa yhteyttä ennen kuin tavara on loppunut varastosta”. Hyödyllinen tapa on myös luoda homogeenisille käyttäjäryhmille käyttäjäpersoonat ja kirjoittaa persoonan kuvaukset auki.
Käyttäjäpersoonakuvaukset auttavat kaikkia projektissa mukana olevia ymmärtämään kenelle ja mihin tarpeeseen kyseistä dashboardia ollaan tekemässä.
Persoonan kuvauksessa tulisi olla projektin kannalta oleellinen tieto käyttäjästä: mikä on henkilön tausta ja osaaminen, työympäristö, tyypilliset työtehtävät ja mihin tavoitteeseen henkilö pyrkii dashboardia käyttäessään.
Vaikkapa tähän tapaan:
”Yrityksen tuotepäällikkö. Vastaa tuoteryhmästä X. On aiemmin tottunut käyttämään analytiikkaratkaisuja, mutta on usein kiireinen ja tarvitsee tiedon nopeasti ja helposti. Haluaa nähdä oman tuoteryhmänsä myynnin kehityksen ja asiakkaiden antaman palautteen. Raportoi kuukausittain ylemmälle johdolle edellisen kuukauden kehityksestä. Tekee töitä toimistolla ja tarkastelee yleensä viimeisen 3 kuukauden tietoja kannettavalta tietokoneeltaan.”
Tällä tavalla on kaikkien projektiin osallistuvien helppo nopeasti ymmärtää, mistä on kyse, kenelle ratkaisua tehdään ja mitä sillä tavoitellaan.
On hyvä myös huomata, että vaikka eri käyttäjät tarkastelisivat samaa dataa, voi heidän tavoitteensa ja tiedon käyttötapansa olla täysin erilainen.
Tällöin on syytä harkita erillisiä ratkaisuja eri käyttäjätyypeille, jotka vastaavat juuri heidän tyypillistä käyttötarvettaan.
Henkilöhaastattelut, käyttäjätarinoiden ja käyttäjäpersoonakuvauksien tekeminen voi tuntua työläältä. Kannattaa kuitenkin huomata, että dashboard-projekteissakin laatu on määrää tärkeämpää. On parempi laatia kymmenen dashboardia, joita käyttäjät aktiivisesti käyttävät, kuin 100 dashboardia, joita kukaan ei käytä.
Hahmottele Ratkaisu yhdessä käyttäjän kanssa
Kun ymmärryksesi käyttäjän tarpeesta on saanut riittävän selkeän muodon, voit alkaa hahmotella tarpeisiin sopivaa ratkaisua. Yksinkertaisimmillaan hahmotteluun voidaan käyttää piirtämällä tehtyjä hahmotelmia tai tekemällä vaikka kynällä ja paperilla tehtyjä luonnoksia. Keskustele luonnoksista käyttäjän kanssa, jotta saat arvokasta palautetta. Voit käyttää keskustelun pohjana myös geneerisiä kuvia kuvaajista.
Kun ensimmäiset hahmotelmat ovat valmiina, voit joko piirtää tarkemman suunnitelman tai toteuttaa yksinkertaisen ja hiomattoman version todellisen työkalun avulla. Jos tarvittava data ei vielä ole tietovarastossa valmiina, voit käyttää excelillä tuotua esimerkkidataa. Tämä helpottaa dashboardin toiminnan hahmottamista huomattavasti.
Voi olla hyvä luonnostella useampia eri versioita samasta dashboardista ja haastatella käyttäjiä – mitkä ratkaisut ovat hyviä, mitkä huonoja ja miksi.
Kuuntele mitä ajatuksia hahmotelmat käyttäjässä herättävät. Kysy mahdollisimman paljon avoimia kysymyksiä, jotta voit paremmin ymmärtää käyttäjän tarpeita. Uusi dashboard-ratkaisu voi tarjota uusia ratkaisuja käyttäjien ongelmiin, joita he eivät välttämättä osaa itse pyytää. Näitä mahdollisuuksia on hyvä pohtia. Selvitä myös todelliset käyttötilanteet – onko käyttäjällä esimerkiksi tarve päästä dashboardiin käsiksi tabletilla tai älypuhelimella?
Jos loppukäyttäjillä on jo dashboardeja käytössä ja haluat jatkokehittää niitä edelleen, kannattaa kehityksen tukena käyttää myös käyttäjätilastotietoa, jota yleensä on saatavilla raportointivälineistä. Käyttäjätilastoista näet mitkä dashboardit ovat suosittuja ja ketkä niitä käyttävät. Jos dashboardeissa on toiminnallisuuksia, kuten porautumisominaisuuksia, on hyvä perehtyä myös siihen, miten ja ketkä niitä käyttävät.
Käyttäjätarinoiden priorisoinnilla fokusta kehitystyöhön
Kun käyttäjätarinoita on valmiina useampia, on ne syytä priorisoida. Kaikkien mahdollisten pyydettyjen ominaisuuksien toteuttaminen ei yleensä ole järkevää. Edelleen kaikkea dataa ei kannata tuoda yhteen dashboardiin.
On mietittävä miksi kyseistä dashboardia ollaan tekemässä ja kenelle.
Jotta lopputuloksena olisi käytettävyydeltään hyvä dashboard, on syytä kiinnittää huomiota myös siihen, mitkä ominaisuudet pohjautuvat todelliseen tarpeeseen ja millä esitystavalla tuohon tarpeeseen parhaiten vastataan.
Koska hyvä dashboard on yksinkertainen ja selkeä on syytä myös tutkia käyttäjän tarpeita siitä näkökulmasta, että mitä elementtejä tai toiminnallisuuksia näkymästä kannattaa jättää kokonaan pois tai piilottaa näkyvistä. Vähemmän on enemmän tässäkin tapauksessa.
Jotta projekti voisi tuottaa mahdollisimman nopeasti lisäarvoa on syytä arvioida jokaisen käyttäjätarinan arvo liiketoiminnalle, sen tekninen kompleksisuus ja priorisoida kehitystyö siltä pohjalta. Priorisoitu lista käyttäjätarinoista ohjaa ketterää kehittämistä.
Ketterässä kehitysprosessissa design-työ ja tekninen kehittäminen kulkevat rinta rinnan projektin läpi alusta loppuun.
Implementoiduista muutoksista saatu palaute ohjaa suunnittelutyötä ja palautteen pohjalta tehdyt design-suunnitelmat ohjaavat toteutusta. Jokaisella kehityskierroksella parannellaan ratkaisua vastaamaan yhä tarkemmin käyttäjien todellisiin tarpeisiin. Vähäiselle käytölle jääneet osat voidaan poistaa, jotta ne eivät tee näkymästä tarpeettoman monimutkaista.
Haluaisitko kuulla lisää dashboardeista ja saada käytännön vinkkejä niiden suunnitteluun sekä hyödyntämiseen? Katso tallenne Dashboardin suunnittelu -webinaarista, jossa Aino kertoo miten voit valjastaa dashboardien voiman käyttöösi ja kuinka esität datassa piilevän tarinan helposti ymmärrettävässä muodossa. Webinaarin sisältö on suunnattu yritysten management dashboardeja suunnitteleville ja/tai niiden parissa työskenteleville, sekä self-service BI -työkaluja työssään hyödyntäville dashboardeista kiinnostuneille.
