Kävin muutamia viikkoja sitten höpöttämässä Goforen muotoilijoille omista kokemuksista yhteistyöstä. Kokemukset olivat yleisön mielestä hieman yllättäviä, joten ajattelin jakaa ne myös teille.
Muotoilijan* roolia on nimittäin kehittäjän näkökulmasta parjattu hyödyttömäksi, jopa kehitystyötä hidastavaksi. Tosin itse edustan koulukuntaa, jossa se on suorastaan välttämätön.
Olen työskennellyt pääasiassa pienissä, alle viiden hengen tiimeissä, koodarina ja Scrum Masterina. Selvennyksenä vielä Scrum Masterin tehtävä: ketterässä kehityksessä Scrum Master huolehtii, että laput ovat ojennuksessa ja tiimi hiihtelee lappujen avustuksella oikeaan suuntaan.
Kaikissa projekteissa tekotapa on ollut ketterän ja erittäin ketterän välimaastossa eli tiimi juttelee paljon keskenään, asiakas on sylkäisyetäisyydellä, dokumentointi on pääasiassa iskusanoista koostuvalla tehtävälistalla (post-it-lappuset tai ranskalaiset viivat) ja kehitysvauhti huomattavan ripeää. Megaprojekteissa tilanne on varmastikin hieman erilainen.
*Käytän tässä tietoisesti muotoilija-termiä selkeän suomenkielisyytensä vuoksi. Tässä yhteydessä tarkoitetaan nyt henkilöä, jolla on taitoja suunnitella käytettävyyttä, käyttöliittymiä, ulkoasuja ja ottaa kantaa itse palvelun muotoiluun. Titteli voisi olla siis myös AD, UX, käytettävyyssuunnittelija, palvelumuotoilija tai palveluarkkitehti näkökulmasta riippuen.
#1 Historian havinaa, elämä ilman muotoilijaa
Ennen Goforea työskentelin erittäin mielenkiintoisessa työssä kehittämässä maatalouteen automaattista traktoritöiden päiväkirjaa. Lyhyesti virsi kaunis eli mittasimme isännän ajoreitit traktorista GPS:llä, piirsimme kartalle ja laskimme mittauksista asioita kuten kynnettyjen peltojen nimet, kynnetyt hehtaarit ja käytetyt ajat.
Työkaverit ja tiimi olivat erittäin taitavia, mutta meillä ei ollut erillistä käytettävyys- tai käyttöliittymäsuunnittelijaa. Kehittäjät perehtyivät itse isäntien työtapoihin ja harrastuneisuutta oli sen verran, että kehittäjät piirsivät esimerkiksi sovelluksessa käytettyjä ikoneita itse Inkscapella.
Hitainta kehityksessä oli työtapa, joka perustui koodaamiseen ja sovelluksen testaamiseen asiakkaalla. Nimittäin juurikin tässä aikajärjestyksessä.
Kehitin esimerkiksi hienon algoritmin joka tuotti sekunnin tasolla tarkkaa dataa pellolla vietetystä ajasta tai työtehosta, mutta seuraavana kesänä selvisi asiakasta kiinnostavan enemmänkin kuinka paljon lannoitetta oli käytetty, koska se oli ympäristöviranomaisille raportoitava tieto.
Joka tapauksessa tykkäsin erittäin paljon asiakkaiden kanssa työskentelystä ja monitaitoisesta lähestymistavasta. Eipä ole juuri ikoneita päässyt tuon jälkeen piirtelemään!
#2 Haastava elämä käytettävyyssuunnittelijan kanssa
Goforella ensimmäinen projektini Scrum Masterina oli kaikin puolin haastava. Uusi rooli kokemattoman asiakkaan kanssa täysin tuntemattomassa sovellusalueessa. Erittäin haastava se oli meidän muotoilijalle Niko Savanderille, joka haastoi asiakasta tehtävistä ominaisuuksista (huono sanaleikki, tiedän).
Projektissa suunnittelimme AirD-nimiselle asiakkaalle maailman mageimman ilmanvaihtojärjestelmän (tästä muuten kuulette vielä, www.aird.fi) ja toteutimme siitä osan asiakkaan myyntiponnisteluiden tueksi. Lopulta projekti alitti hinta-arvion ja ylitti odotukset, mutta se ei ollut mitenkään selvää alkuvaiheessa. Pikemminkin päinvastoin, alku lähti liikkeelle unettomilla öillä ja Scrum Master laahusti paikalle aamuisin tummien silmänalusten kanssa.
Alkuvaiheessa haluttuja ominaisuuksia oli valtava läjä ja kaikki ominaisuudet tuntuivat asiakkaasta yhtä tärkeiltä. Kehittäjinä tiesimme, että osa ominaisuuksista on hyvin suuritöisiä ja hanketta ei saada pienillä resursseilla maaliin tekemällä kaikki.
Keskeinen komponentti onnistumisessa oli meidän Niko, joka osasi teollisella kokemuksellaan, käytettävyystiedoillaan ja lehmän hermoilla työstää asiakkaan kanssa sen timanttisen ytimen, jossa oli kaikki tarvittava asiakkaalle, mutta ei mitään ylimääräistä.
Tältä pohjalta asiakas sai myyntikäyttöön erittäin vakuuttavan ja näyttävän demon ja pääsi työssään eteenpäin. Loput ominaisuudet ovat nyt vuosi projektin aloittamisen jälkeen jatkoprojektissa toteutuksessa.
Kaikkein halvimpia ominaisuuksia olivat ne, joita ei tarvinnut kehittää. Nämä valtavat säästöt olivat käytettävyyssuunnittelun ansiota.
Mainittakoon vielä sovelluksen ulkoasusta vielä sen verran, että aiempien kokemusten jälkeen pidin itseäni aika hyvänä käyttöliittymäsuunnittelijana. Nikon tuotosten näkemisen jälkeen tajusin olevani vasta ylemmässä harrastelijasarjassa.
#3 Käytettävyyssuunnittelija valmiiden käyttäjätarinoiden kimpussa
Seuraavassa projektissa teimme Työterveyslaitokselle työelämän ulkopuolella oleville tarkoitetun nettikyselyn. Mihin tällaista tarvitaan, koska on niin monta valmista kyselysovellusta kuten Survey Monkey, Zef ja niin edelleen?
Projektin alussa selvisi, että valmis tuote olikin jo käytössä, mutta sen käyttö oli vaikeaa, erityisesti kännyköillä tai tableteilla. Osalla käyttäjistä elektronisten laitteiden käyttötaidot ovat hyvin heikot. Myöskään kyselyitä tekevät hankeprojektien vetäjät eivät kaivanneet lisävaikeuksia jo ennestään vaikeaan työhönsä.
Kuinka tehdä äärihelppo kyselysovellus äärimmäiselle käyttäjäryhmälle? Tämä haaste kulki projektin läpi punaisena lankana. Apuun tuli (yllätys yllätys) muotoilija Juha Perä.
Tällä kertaa tilaajalla oli tarvittavista ominaisuuksista hyvä karkean tason lista jo valmiiksi olemassa. Yksi käyttäjätapaus oli esimerkiksi “käyttäjä kirjautuu järjestelmään”. Kuulostaa ehkä alkuun selvältä, mutta kuka tekee käyttäjätunnukset, miten ne jaetaan käyttäjille, tarvitaanko salasana, kuka tekee salasanan, miten vaikea se saa olla, kuinka linkki annetaan asiakkaalle? Ja ennen kaikkea: kuinka tämä kaikki tehdään niin, että kirjautuminen onnistuu pommin varmasti asiakkaalle, joka ei kyselyä välttämättä halua täyttää?
Juha mahdollisti meidän pienelle kehitystiimille sen, että saimme keskittyä rauhassa teknisiin haasteisiin ja kirjautumisen kaltaiset hahmottomat möhkäleet tulivat kehityspöydälle valmiiksi pureskeltuina.
Ratkaisu kirjautumiseen oli muuten valmiin kertakäyttöisen linkin jakaminen, jolloin käyttäjätunnuksia ei tarvita ja käyttäjän syöttämät tiedot eivät voi levitä ulkopuolisille.
Projektin kliimaksi oli lopulta kyselyn palautesivu. Vastaajat saavat vastauksistaan kannustavan palautteen, jonka piti olla havainnollinen ja selkeä, mutta niin neutraali ettei siitä kukaan voi loukkaantua. Miten kuvaat esimerkiksi omaa fyysistä kuntoa neutraalisti positiivisessa sävyssä?
Parin päivän työstämisen jälkeen Juha esitteli asiakkaalle rauhaa henkivät ikonit, jotka kelpasivat heti ensimmäisellä kerralla tilaajan vaativalle projektiryhmälle. Toteutustapa oli myös teknisesti helppo ja seuraavana päivänä testiversiot olivat asiakkaan kliksuteltavissa.
Yhteenveto
Halvimmat koodinpätkät ovat niitä, jotka voi jättää koodaamatta. Toiseksi halvimmat ovat niitä kerralla maaliin osuvia toiminnallisuuksia, joita ei tarvitse myöhemmin muutella.
Edelliset esimerkit ovat poimintoja useista vastaavista tilanteista. Työtapa, jossa käytettävyyssuunnittelun menetelmin ensin perehdytään asiakkaan tarpeisiin JA toiminnallisuudet testautetaan ennen koodaamista, on erittäin voimallinen ja säästää asiakkaalle selvää rahaa.
Käytettävyyssuunnittelu ei ole mitään sellaista mustaa magiaa, jota sovelluskehittäjä ei voisi opiskella. Päinvastoin, asiat ovat terveellä käytännön järjellä pääteltävissä ja pienellä teoriaan perehtymisellä välttää pahimmat mokat. Tämä on kuitenkin työtä, joka jonkun täytyy tehdä. Kehittäjien tontille osuessaan se on pois teknisestä kehitystyöstä.
Käyttöliittymäsuunnittelussa ja piirtämisessä tilanne on sama. Taitava käyttöliittymäkoodari pyöräyttää kyllä nopeasti käyttöliittymiä itsekin, mutta Nikon ja Juhan kaltaiset taikurit leiskauttavat ne niin paljon paremmin ja nopeammin.
Kirjallisuutta käytettävyydestä ja käyttöliittymistä kiinnostuneille
Don’t Make Me Think
Erityisen hyvä, koodareille sopiva perehdytys käytettävyyteen. Käy läpi perusasiat melko kompaktissa paketissa. Aloita tästä.
Non Designers Design Book
Aivan mahtava opas hienojen ulkoasujen suunnitteluun. Samoja teesejä voi käyttää kuvituksissa, taitoissa, käyttöliittymissä tai onnittelukorteissa.
Designing with the Mind in Mind
Vähän vastaava kirja kuin Don’t Make Me Think, mutta käy läpi aihealuetta psykologian ja ihmisen rajallisen hahmotuskyvyn näkökulmasta. Lue tämä sitten, kun kaksi edellistä on hanskassa.
