Design näkyy myös Sitedrivessa

Siis mikä suunnittelu..? Käyttökokemus syntyy siitä, että suunnittelijat eli UX-designerit suunnittelevat ohjelmistoista toimivampia ja miellyttävämpiä teille – Sitedriven käyttäjille.

Pohjimmiltaan käyttökokemussuunnittelija on ongelmanratkaisija. Hän toimii linkkinä käyttäjien ja kehitystiimin välillä, keräten tietoa käyttäjien työstä, tarpeista ja ongelmista. Näiden selvittämisen jälkeen suunnittelija voi viedä ratkaisunsa kehitystiimille varmana siitä, että kehitettävät tuotteet ja ominaisuudet tulevat aidosti helpottamaan käyttäjien elämää.

Miten käyttäjäkeskeinen suunnittelu toimii?

Jotta Sitedrive voisi vastata käyttäjän oikeisiin tarpeisiin ja ongelmiin, pitää kehitystiimin ymmärtää käyttäjää. Rakennusalan ja aikataulujohtamisen asiantuntijoita ovat ensi kädessä käyttäjät, eivät kehitystiimiläiset tai suunnittelijat. Usein työmailta käsin voi kuitenkin olla vaikea sanoa, mikä konkreettinen ratkaisu helpottaisi elämää, mutta on helppo sanoa mikä harmittaa ja hidastaa. Silloin tarvitaan käyttäjäkeskeistä suunnittelua, joka on muotoilun metodologia, jossa tuotteen käyttäjän palaute ja näkemykset laitetaan suunnittelun keskiöön.

Suunnittelu mahdollistaa sen, että toteutus menee ensimmäisellä kerralla maaliin.

Jos tuotekehitystä ei tehdä käyttäjälähtöisesti, niin vaarana on, että kehitetään ja julkaistaan ominaisuuksia, jotka eivät palvele rakentamista optimaalisesti. Tällöin ominaisuus on todennäköisesti toteutettava uudestaan. Tämä on kallis ja hidas prosessi, ja ennen kaikkea turhauttavaa työmaille. Toisin sanoen, käyttäjäkeskeinen suunnittelu mahdollistaa sen, että toteutus menee ensimmäisellä kerralla maaliin.

Miten suunnittelu näkyi Sitedriven käyttöliittymäuudistuksessa?

1. Ongelman hahmotus

Kaikki alkaa siitä, että jollakin on herännyt idea uudesta ominaisuudesta, tai tuotteesta on tullut ilmi ominaisuus tai osa, joka kaipaa muutosta. Saimme Sitedriven käyttäjiltä toiveita, että aikataulun muokkaus ja julkaisu voisi olla yksinkertaisempaa. Ongelmaa lähestyttiin haastattelemalla työmailla Sitedrive-käyttäjiä, jotka kertoivat lisää tarpeistaan ja palautetta kerättiin mahdollisimman laajasti eri rooleissa toimivilta ihmisiltä. Kerättyjen palautteiden perusteella syntyi sen jälkeen kehitystiimin kanssa suunnitelma siitä, mitä aikataulujen julkaisemiselle tehdään.

2. Konseptointi ja ratkaisuehdotus

Käyttäjien ongelman ymmärrettyään suunnittelija luonnostelee ratkaisuehdotuksen. Tämä tapahtuu työkaluilla, joilla on mahdollista visualisoida idea nopeasti. Sitedriven tapauksessa käytimme käyttöliittymän prototyyppiä, jolla voitiin testata, miten lopullinen toteutus voisi toimia.

3. Validointi eli ratkaisun testaus

Visualisoitua ratkaisuehdotusta testataan yhdessä useiden käyttäjien kanssa, jotta näkökulmia kertyy laajasti. Sitedriven käyttäjille annettiin tehtäväksi vapaasti selata käyttöliittymää ja aloittaa aikataulun editointi. Testauksen aikana he kertoivat, mitkä asiat toimivat heidän mielestään ja mitkä eivät. Samalla suunnittelija tarkkaili, onko prototyypissä käytettävyysongelmia, kuten vaikeasti selitettyjä nappeja tai huonosti sijoitettuja ominaisuuksia. Sitedriven tapauksessa prototyyppi toimi melko hyvin testaajien käytössä, mutta muokkaustilan aktivoinnin nappi ei useimpien käyttäjien kohdalla löytynyt kovinkaan helposti.

4. Uudelleensuunnittelu tai hienosäätö

Palautteet ja observaatiot kerätään yhteen ja analysoidaan. Näiden tietojen valossa Sitedriven kehityksessä hienosäädettiin editointinapin sijaintia helpommin löydettäväksi ja napin tekstiä paremmin kuvaavaksi.

5. Tuotteen julkaisu

Tavoite saavutetaan, kun tuote vastaa käyttäjän tarpeisiin.

Sitedrivestä poistettiin erilliset seuranta- ja laadintatilat, jotta aikataulun muokkaus ja julkaisu olisi jouhevampaa. Kehitys ei kuitenkaan pysähdy tähän, vaan edelleen vastaanotetaan käyttäjien palauteet palautekanavia pitkin, joiden perusteella parannellaan ominaisuuksia. Harva digituote on koskaan valmis, vaan päivityksiä tehdään jatkuvasti.

On olemassa muitakin keinoja kehittää tuotteiden ominaisuuksia. Voidaan esimerkiksi kerätä yhteen käyttäjiä ja kehitystiimiä, joiden kanssa yhdessä suunnitellaan ratkaisu työpajassa. Näin päästään nopeasti ratkaisun jäljille, mutta tässäkin tapauksessa suunnitelma on validoitava ennen toteutusta.

Käyttäjien on todella kannattavaa osallistua käyttäjäkeskeisen suunnittelun vaiheisiin, sillä siten he voivat auttaa muovaamaan tuotetta paremmin tarkoitusta palvelevaksi ratkaisuksi – itselleen.