Yes We Can – Etuovi.com

Tätä kirjoittaessa 31.5.2014 on saavutettu merkittävä piste suomalaisten verkkopalvelujen historiassa. Yksi Suomen web-historian tunnetuimmista palveluista, asunnonvälityksen markkinajohtaja Etuovi.com, on uudistettu kokonaan. Palvelun historia alkaa jo vuodesta 1996 nimellä dime.net ja seuraava uudistus sekä nimen muutos Etuovi.comiksi tehtiin vuonna 2001. Vanha järjestelmä on edelleen pitänyt pintansa kilpailussa, mutta nyt kolmetoista vuotta myöhemmin järjestelmä on ymmärrettävästi teknisesti vanhentunut. Alma Media tiedosti haasteet ajoissa ja alkoi suunnitella uutta järjestelmää huolella.
Olen itse saanut olla viime kuukaudet mukana Alma Mediapartnersin kehittäjätiimissä Etuovi.com -projektin loppusuoralla. Kevään teemana on ollut ”Yes We Can” ja se on näkynyt mm. toimiston seinällä olevan oheisen julisteen muodossa sekä asiantuntevan tiimin esimerkillisenä sitoutumisena yhteiseen tekemiseen. Erityisesti tämä on näkynyt viimepäivien työpanoksessa; hommia on painettu arkipyhät ja viikonloput.
obama
Alma Media on tarjonnut hyvät puitteet tekemiselle ja myös tällainen ulkopuolinen konsultti on tuntenut olonsa mukavaksi. Tiimiä on hemmoteltu omalla kahvilla, virvokkeilla, hedelmillä, pähkinöillä ja lisäkannustusta on tuonut käytävällä kaikkien nähtävillä oleva laskuri. Kuva on otettu reilut neljä päivää ennen h-hetkeä. Armottomasta laskurista huolimatta kaikki saatiin valmiiksi julkaisua varten ja uusi Etuovi julkaistiin täsmälleen aikataulun mukaisesti.
samikallio

Älä luota Open Sourceen

Uuden Etuoven perusta rakennettiin jo vuonna 2012, jolloin Alma Mediapartnersin ja Goforen yhteinen tiimi ryhtyi suunnittelemaan Alman tulevien online-palvelujen arkkitehtuuria ja toteutti sovellusrunkoa palveluille. Tähän työhön perustuvat Alma Mediapartnersin uudet verkkopalvelut, Etuovi.comin asuntoportaalin lisäksi mm. sisustus.etuovi.com. Kuten useimmat verkkopalvelut nykyään, myös Etuovi.com hyödyntää vahvasti Open Source -teknologiaa.
Tältä ajalta on peräisin myös viimeisen viikon pahin blokkeri. Huomattiin, että kovan kuormituksen alla tietyt toiminnot käyttöliittymästä hajoavat täysin. Kuulin ongelmasta ensimmäisen kerran keskiviikkoiltana ja käytin sen tutkimiseen jonkin verran aikaa. Syy jäi kuitenkin vielä keskiviikkona kaikille mysteeriksi. Alma Mediapartnersin kehittäjät työskentelivät koko helatorstain ja syy blokkeriin selvisi. Perjantaiaamuna korjaus oli valmis ja minulle jäi tehtäväksi korjauksen katselmointi. Syynä oli kaksi vuotta sitten tekemäni CDN-koodi, jossa oli rinnakkaisuuteen liittyvä virhe. Kovan kuorman alla potentiaalinen race condition realisoituu ja tässä tapauksessa se ilmeni niin, että samoja resursseja mm. JavaScript-tiedostoja ladattiin monta kertaa. Tämä taas hajotti käyttöliittymän JavaScriptit kokonaan ja siten koko käyttöliittymän.
Käytetty CDN-koodi oli osa Apache-lisensoitua komponenttia ja kävin tietysti tarkistamassa komponentin nykyisen tilan; sama virhe oli edelleen siellä. Voiko tästä oppia jotain? Ainakin sen, että avoimen koodin kirjastoista voi löytyä vakaviakin virheitä. Toisaalta vastaavia on löytynyt myös kaupallisista kirjastoista, joten tämän perusteella ei voi kategorisesti tehdä eroa avoimen ja kaupallisen koodin välillä. Kaksi asiaa tästä ainakin kannattaa ottaa opiksi: käytettävien kehysten, kirjastojen ja komponenttien valinta vaatii huolellisuutta, asiantuntemusta ja usein järjestelmällistä tarkastelua ja vertailua. Tämän lisäksi on tärkeää tehdä kunnolliset testit ja erityisesti suorituskykytestit yhdistettynä toiminnalliseen testaukseen, kuten Etuovi-projektissa tehtiin.
Propsit Mediapartnesin kavereille virheen löytämisestä ja korjaamisesta!
 

Avatar

Sami Kallio

Sami on kokenut ohjelmistoarkkitehti ja huippuasiantuntijoista koostuvan tiimin vetäjä. Hän on osallistunut lukuisten erilaisten yksityisektorin ja julkishallinnnon tietojärjestelmien kehittämiseen vakuutusjärjestelmistä mediasektorille ja joukkoliikenteestä rahastotoimintaan Suomessa ja ulkomailla.

Piditkö lukemastasi? Jaa se myös muille.

Apple sen teki. Herätti meidät siihen, että hyvä käyttäjäkokemus (user experience, UX) ratkaisee palveluiden ja tuotteiden menestymisen. Vaikka palvelu olisi kuinka hyvä teknisesti, tai vaikka kuinka syvää sen sisältämä tieto olisi, tunne palvelua käytettäessä ratkaisee kokemuksen – fiilisjuttuja siis.
Väitän, että hyvätkin nykyiset palvelut ovat valovuoden päässä sellaisesta käyttäjäkokemuksesta, joihin olisi tällä hetkellä teknisessä mielessä mahdollista päästä.
Olet varmasti saanut häivähdyksen sellaisesta kokemuksesta joskus – palvelu antoi sinulle wau-kokemuksen. Se ennakoi toimintaasi, tarjosi ainoastaan tilanteeseen sopivia valintoja eteesi, mukautui päätelaitteeseesi, toimi kuin ajatus. Ehkä palvelu jopa yllätti sinut siten, että sait palvelua käyttäessäsi jotain sellaista, mitä et osannut odottaakaan.
Tulevaisuus on tässä suhteessa varsin valoisa. Megatrendit kuten teollinen internet ja big data tarkoittavat käyttäjän näkökulmasta juuri sitä, että tarpeet huomioidaan kulloisessakin tilanteessa, tietoa yhdistellään ja tarjotaan käyttäjälle oikeaa toiminnallisuutta tai tietoa oikea-aikaisesti. Digitalisaatio eteneekin tällä hetkellä vauhdikkaammin kuin milloinkaan ennen – kokonaan uusille aloille ja elämän alueille. Maltan tuskin odottaa niitä palveluita, jotka kymmenen vuoden kuluttua ovat meille arkipäivää.
Tässä muutoksessa me Goforessa haluamme olla mukana, parhaina asiantuntijoina. Miten kokonaisarkkitehtuuri kytkeytyy käyttäjäkokemuksen suunnitteluun? Miten UX huomioidaan elimellisenä osana ketterän kehittämisen elinkaarta? Missä kohtaa luovuus astuu kuvaan palveluita suunniteltaessa? Entäs se big data? Tässä kaikessa voimme olla apunasi, ajantasaisesti, nyt ja jatkossa.

Avatar

Timur Kärki

Timur on Gofore Oy:n toimitusjohtaja ja yksi perustajaosakkaista. Hänellä on yli viidentoista vuoden kokemus haasteellisista tietojärjestelmien kehittämishankkeista. Erityisen kiinnostunut Timur on Suomen pelastamisesta onnistuneilla ja innovatiivisilla sähköisillä palveluilla yhdessä Goforen asiakkaiden ja työntekijöiden kanssa. Timur itse konsultoi asiakkaita liittyen kokonaisarkkitehtuurityöhön, vaatimusmäärittelyihin sekä kilpailutusprosesseihin.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Aikansa eläneen tietojärjestelmän uudistaminen tarjoaa tilaisuuden tarkastella myös organisaation toimintamalleja uusista näkökulmista. – Kun teknologian uudistamiseen liittyy myös toimintatapojen uudistus, keskeistä suunnittelussa on käyttäjälähtöisyys, sanoo hankepäällikkö Pekka Äikäs Aalto-yliopistosta.
Äikäs vetää Helsingin yliopiston, Tampereen yliopiston ja Aalto-yliopiston yhteistä opintohallinnon tietojärjestelmien modernisointihanketta (OTM).
Järjestelmällä hallinnoidaan tutkinto- ja jatko-opiskelijan elinkaari yliopistossa opiskelijavalinnasta valmistumiseen, ja sen on määrä kattaa kaikki opintohallinnon toiminnallisuudet.
Hanke on vaativa, monitahoinen ja aikaa vievä. Se on myös malliesimerkki siitä, miten käyttäjäkeskeinen lähestymistapa voi avata pitkälle ja haastavalle työlle uuden näkökulman ja sen myötä oikean suunnan ja etenemismallin.

Opiskelijat hallintotöihin

Yliopistojen opintohallinnon järjestelmät ovat pääosin 90-luvun puolivälistä. Tarve niiden uudistamiseen on ollut pitkään tiedossa, ja ajatusta kansallisesta tietojärjestelmästäkin oli jo ministeriön tasolla viritelty. Kun se ei toteutunut, kolme yliopistoa päätyivät aloittamaan järjestelmäuudistuksen keskenään. Hanke jatkuu vuoden 2016 loppuun.
– Teknologian vanhentuminen on vain yksi syy järjestelmien uudistamiselle, sillä entistä painavammiksi ovat viime vuosina nousseet yliopistojen resurssipaineet ja pyrkimys hallinnon tehostamiseen. Opintohallinnon tietojärjestelmän uudistamisella on siten myös tärkeä strateginen rooli, Äikäs sanoo.
Painotuksen muutos näkyy myös käytännössä. Hallinnon tarpeiden ohjaama valmistelu löysi uuden vaihteen, kun Helsingin yliopiston Tietotekniikkakeskuksen ohjelmistotuotannon tiiminvetäjä Sami Nikander liittyi projektiin viime kesänä. Hän  toi mukanaan vahvan painotuksen käyttäjäkeskeiseen suunnitteluun ja sen seurauksena koko työhön uuden näkökulman.
– Katsantokulman kääntäminen hallinnosta opiskelijoihin avasi ajatukset ratkaisuille, jotka aikanaan antavat mahdollisuudet fiksumpiin toimintatapoihin niin opiskelijan, opintohallinnon kuin yliopistonkin kannalta. Yliopistot haluavat nyt aidosti katsoa, miten toimintamalleja voidaan opintohallinnossa uudistaa sujuvammiksi ja tehokkaammiksi, Äikäs sanoo.

Käyttöliittymä on onnistumisen avain

Valmistelu, vaatimusmäärittely, konseptointi ja käyttöliittymän perussuunnittelu on tehty pääosin yliopistojen omin voimin. Loppukeväästä mukaan tulivat yliopistojen puitesopimusten piiristä valitut yrityskumppanit.
Käyttöliittymää suunniteltiin Sami Nikanderin johdolla ja työssä käytettiin Helsingin yliopistossa kehitettyä suunnittelumenetelmää GUIDEa. Siinä suunnittelun lähtökohtana ei ole ominaisuusluettelo, vaan käyttäjän konkreettinen tarve, joka ratkaistaan läpi. Työkaluja ovat paperi ja kynä, ja käyttäjät kommentoivat ehdotuksia ensimmäisestä luonnoksesta alkaen.
Gofore on Helsingin yliopiston puitesopimuskumppani ketterien menetelmien konsultoinnissa ja on ollut hankkeessa mukana toukokuusta 2014 käyttöliittymäasiantuntijana.
– Yliopistot ovat tehneet poikkeuksellisen hyvää työtä käyttäjien tarpeiden selvittämisessä ja käyttöliittymän suunnittelussa, Goforen UX-suunnittelija Arto Puikkonen kiittää. Hän työstää parhaillaan suunnitelmia eteenpäin ohjelmointikuntoon.

Ketterästi yli kynnyksen

Äikkään mukaan kolmen yliopiston yhteenliittymä on osoittautunut toimivaksi. Toteutusvoimaa on riittävästi, mutta joukko pysyy silti päätöskykyisenä.  Yhteistyö on tehnyt vaikutuksen myös Sami Nikanderiin.
– On hienoa nähdä, miten yliopistot pyrkivät nyt yhdessä harmonisoimaan työtapojaan.
Omasta tietotekniikka-asiantuntijan kulmastaan Nikander on erityisen tyytyväinen siitä, että sai tuoda hankkeeseen ’ketterän mindsetin’ ja sen mukaisen etenemisen.
– Ketterä toimintamalli alentaa liikkeellelähdön kynnystä, kun voidaan edetä kokeilun kautta ja pystytään reagoimaan palautteeseen ja toimintatapojen muutoksiin.

Lukkarista liikkeelle

Äikäs toteaa, että vaikka yliopistoilla on paljon omaa osaamista ja hanke on edennyt hyvin, kaikkea ei voi eikä kannata tehdä omin voimin.
– Yritysten ammattilaisten myötä hankkeeseen tulee ryhtiä ja myös tilaajan puolella fokus pysyy koko ajan selvänä, Äikäs sanoo.
Toteutus etenee nyt vaiheittain. Lomakauden jälkeen valmistuu lukujärjestystyökalu, joka annetaan rajatun opiskelijaryhmän käyttöön.
– Opiskelijoiden saaminen käyttäjiksi on järjestelmän hyödyllisyyden kannalta aivan ydinasia. Siksi lähdemme liikkeelle heille tärkeästä työkalusta.
Entä jatkossa – millaista uutta on tulossa?  Äikäs antaa esimerkkejä:
– Nykyisin opiskelijan valmistuessa virkailijat kokoavat paljolti käsityönä eri lähteistä tiedot opiskelijan suorituksista. Tulevaisuudessa monia vaiheita pystytään automatisoimaan, jolloin hallintoa kuormittava paperityö vähenee ja työaikaa saadaan esimerkiksi kehittämiseen ja suunnitteluun.
– Myös yliopiston resurssien suunnittelu järkevöityy, kun kurssien toteuttamista ja tilojen käyttöä ei tarvitse enää suunnitella historiadatan perusteella vaan sen mukaan miten opiskelijat ovat suunnitelleet.
Opiskelijan näkökulmasta uutta järjestelmää voi luonnehtia opintojen suunnittelun itsepalvelutyökaluksi. He voivat suunnitella vuoden tai jopa koko viiden vuoden opiskelujensa etenemisen ja ovat muun muassa koko ajan selvillä suorituksistaan suhteessa tutkintovaatimuksiin.

Pekka Äikäs (vas.), Arto Puikkonen ja Sami Nikander kommentoivat Arton työstämää käyttöliittymäsuunnitelmaa.
Pekka Äikäs (vas.), Arto Puikkonen ja Sami Nikander kommentoivat Arton työstämää käyttöliittymäsuunnitelmaa.

Teksti: Marketta Tammisto, Effet.

Gofore Oyj

Gofore Oyj

Piditkö lukemastasi? Jaa se myös muille.

Valitettavan usein käyttöliittymäsuunnittelijan elämä on kuin suojaisi kukkaistutuksia sateenvarjolla raekuurossa. Tiedät, että tehtävä on lähes mahdoton. Tiedät, että voit suojella vain osan istutuksista, mutta silti tahdot yrittää. Kun löytää itsensä tuosta tilanteesta, tietää pahimman jo tapahtuneen sekä tekevänsä jotain järjetöntä.
Mitä sitten on tapahtunut? Käyttöliittymäsuunnittelija on tilanteessa, jossa hänelle satelee määrittelyjä, jotka pohjautuvat… Ai niin, kukaan ei taida tietää mihin. Hänellä on edessään huono määrittely, joka ei kuvaa sitä, mikä on olennaista käytettävän lopputuloksen saavuttamiseksi. Käyttäjälähtöinen määrittely on jäänyt tekemättä.
Käyttöliittymäsuunnittelun yksi tärkeimmistä fundamentaaleista on vastaus kysymykseen ”Miksi?”. Jos suunnittelija ei tiedä, miksi käyttäjä haluaa tehdä jonkin asian, hänen on hyvin vaikea muodostaa määrittelyn pohjalta käytettävää käyttöliittymää. Kysyt ehkä miksi. Annan sinulle esimerkin – käyttäjän tulee voida valita asioita listalta.
Kuulostaa yksinkertaiselta, vai mitä? Ammattitaitoinen käyttöliittymäsuunnittelija kaipaa kuitenkin vastausta kysymykseen ”Miksi?”. Koska tätä tietoa ei ole tarjolla, suunnittelija joutuu arvailemaan muun muassa, mitä tietoja käyttäjä tarvitsee voidakseen valita oikeat asiat listalta ja kuinka monta kohtaa hän tyypillisesti valitsee, jotta voidaan tehdä valintaan soveltuva työkalu. Tämän yksinkertaisen tiedon puuttuminen saattaa johtaa väärien käyttöliittymäkomponenttien valintaan, jotka eivät tue käyttäjän todellista tarvetta. Vaikutus voi tuntua pieneltä, mutta näin käyttöliittymäsuunnittelijan näkökulmasta ero on merkittävä. Käyttöliittymien toimintaperiaatteita on laaja kirjo. Ymmärrys käyttäjän syistä ja tarpeista antaa näkemyksen, jonka perusteella ammattitaitoinen käyttöliittymäsuunnittelija valitsee juuri tilanteeseen sopivan toimintaperiaatteen. Ilman tätä ymmärrystä mennään metsään.
Kuinka tämä uhkakuva sitten vältetään? Tärkeää luonnollisesti on se, että kerran kerätty tieto käyttäjien tarpeista ja käyttötilanteista kulkee toteutuksen mukana. Ketterässä ohjelmistokehityksessä, jossa järjestelmää toteutetaan käyttäjätarina kerrallaan, ei ole mitenkään vaikeaa kuljettaa käyttäjätarinan mukana tarvittavia tietoja. Käyttäjän tulee voida valita asioita listalta, jotta hän voi vertailla niiden sisältöjä. Valitettavaa kuitenkin on, että usein virhe on tapahtunut jo paljon aiemmin kuin käyttäjätarinoita kirjoittaessa. Virhe on tapahtunut siinä, miten määrittelyn pohjalla oleva tietämys on kerätty.
Voi sitä ärtymyksen ja turhautumisen määrää, mikä minuakin on piinannut useissa projekteissa. Ne ovat niitä hetkiä, kun kokee suojaavansa kukkaistutuksia sateenvarjolla. Edessäsi on määrittely, jonka alkuperän tiedät vääräksi. Määrittely on tullut pelkästään joltain muulta kuin järjestelmän todelliselta käyttäjältä. Jos ongelma oli ”Miksi?”, niin ongelma on myös ”Kuka?” ja ”Miten?”. Valitettavan usein, edelleen, järjestelmien määrittely tehdään komiteoissa ja pelkästään organisaation johtoa haastattelemalla. Taas ollaan menossa metsään ja vauhdilla. En sano, että tämä on väärin. Sanon, että tämä ei yksin riitä. Näin toimiessa saadaan lähes poikkeuksetta vain organisaation näkemys siitä, mitä järjestelmällä tulisi saavuttaa. Syntyy määrittely, joka kuvastaa organisaation johdon näkemyksiä tavoitellusta lopputuloksesta. Syntyy toimintalähtöinen määrittely. Erittäin tärkeä tieto tämäkin, mutta se tärkein substanssiosaaja on juuri jäänyt kuulematta. Metsään mennään ja aurinkoranta on vielä vain haaveena.
tienviitta
Käyttäjä on paras osaaja kertomaan, mitä hän tarvitsee, jotta hän voi tehdä työtään hyvin. Mitä hän tarvitsee, jotta hän voi mahdollisimman hyvin ja tehokkaasti saavuttaa sen lopputuloksen, jota organisaatio häneltä kaipaa. Olipa kyseessä järjestelmän uudistus tai aivan uuden sovelluksen luominen, käyttäjä tietää parhaiten, mitä hän tarvitsee. Käyttäjä on järjestelmän kovin substanssiosaaja niistä tietotarpeista, joita hän sujuvan työskentelyn kannalta tarvitsee. Hän on myös oikein osallistettuna erittäin hyvä innovaattori, joka kykenee kehittämään organisaation toimintatapoja. Käyttäjä on se henkilö, joka sanoo ”Ei ole mitään järkeä, että…”.
Saatoit ehkä kiinnittää huomiota, että sanoin käyttäjän kertovan. Kyllä, tällä tarkoitetaan myös käyttäjältä kysymistä ja käyttäjän kanssa tehtävää yhteistä pohdintaa tai esimerkiksi käyttäjän observointia. Kun ammattilainen tarkkailee käyttäjää luonnollisessa ympäristössä todellisen työtehtävän äärellä, saadaan sellaista ymmärrystä, joka täydentää käyttäjien sanat todellisuudeksi. Observoinnin avulla voidaan tunnistaa käyttäjien tiedostamattomat tietotarpeet ja ongelmat. Hyvin tehty käyttäjätyö, haastatteluja ja observointeja hyödyntämällä, yhdistää käyttäjiltä saatavan subjektiivisen ja objektiivisen datan. Käyttäjä katsoo järjestelmää laatikon sisäpuolelta, käyttäjätyön ammattilainen laatikon ulkopuolelta. Kun tämä ammattilainen on tehnyt laadukasta työtä tunnistaen laatikon molemmat puolet, hän ymmärtää mistä laatikossa on kyse. Ilman käyttäjää ei saada sellaista lopputuotetta, joka toimii tehokkaasti ja helppokäyttöisesti omassa toimintaympäristössään.
Kyse on siis toimintalähtöisen ja käyttäjälähtöisen määrittelyn yhdistämisestä. Molemmat kuvaavat muodostuvaa järjestelmää omista näkökulmistaan. Kumman tahansa pois jättäminen aiheuttaa joko ongelmia järjestelmän toiminnan tavoitteiden tai tavoitteiden tehokkaan saavuttamisen kanssa. Huonoa käytettävyyttä ja tehotonta työskentelyä. Ei kuulosta minusta modernilta järjestelmältä. Suurin harmitus tästä tulee, kun tiedän, miten asiat voisivat olla. Olen Goforella ollut tekemässä useita käyttäjälähtöisen määrittelyn projekteja yhdessä toimintalähtöisen määrittelijän kanssa. Näissä projekteissa olen nähnyt, kuinka laadukas määrittely edesauttaa merkittävästi korkean käytettävyyden saavuttamista. Goforella käyttäjälähtöinen ja toimintalähtöinen määrittely kulkevat aina yhdessä. Tämän tekstin opit kumpuavat niistä projekteista, joissa virheet on tehty ennen meidän saapumista mukaan kuvaan.
Mitä sinulle tästä jutusta pitäisi sitten jäädä mieleen? Väärin laadittu ja käytetty määrittely vie sinut varmasti metsään. Minä taas tahtoisin mennä aurinkoiselle rannalle. Uskon, että niin tahdot sinäkin ja kaikki muutkin käyttäjät.
 

Avatar

Arto Puikkonen

Arto on kokenut palveluiden muotoilija ja UX-suunnittelija. Hän on urallaan huolehtinut kymmenien web-, mobiili- ja työpöytäsovellusten muotoilusta. Arton ydinosaamista ovat käyttäjätyö sen moninaisimmissa muodoissaan sekä käyttöliittymäsuunnittelu. Goforella Arto vastaa yrityksen muotoilupalveluista

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Käyttöliittymäsuunnittelija suunnittelee, asiakas katselmoi ja toteuttaja toteuttaa. Tämä periaatteessa yksinkertainen ketju ei kuitenkaan tuota aina toivottua lopputulosta. Joskus alkuperäisen suunnitelman tavoitteet eivät toteudu tai asiakas ei saa sitä mitä tilasi. Yleensä konseptitason suunnittelu tehdään rautalankamalleina, joilla käyttöliittymäsuunnittelija havainnollistaa käyttöliittymän keskeiset ominaisuudet ja sommittelun asiakkaalle ja kehitystiimille. Rautalanka on tähän erinomainen työkalu, mutta samalla myös väistämättä rajoittunut tapa esittää suunnittelijan visioima käyttöliittymä. Rautalanka ei koskaan pysty kommunikoimaan kaikkea käyttöliittymän toiminnallisuutta eikä erityisesti eri näkymien suhdetta toisiinsa kattavasti. Käyttöliittymäsuunnittelun seuraava vaihe kannattaa lähes aina tehdä rakentamalla käyttöliittymäprototyyppi, joka on osaavissa käsissä erinomainen työkalu parantamaan suunnittelun laatua. Hyvä käyttöliittymäprototyyppi vastaa suunnittelutyön keskeisiin haasteisiin:

  • Käyttöliittymäsuunnitelman kommunikointi kehitystiimille ja asiakkaalle
  • Suunnittelijan oman ajattelun selkiyttäminen ja rautalangaksi piirretyn käyttöliittymän koeajaminen
  • Kevyen käytettävyystestauksen tekeminen varhaisessa vaiheessa projektia

Käyttöliittymäprototyyppi tarjoaa sekä asiakkaalle että kehitystiimille toimivan version käyttöliittymästä joka simuloi tuotantoversion toiminnallisuutta ja ulkoasua. Lisäksi prototyyppi paljastaa usein rautalankamallissa piiloon jääviä seikkoja myös suunnittelijalle itselleen. Miten navigointi todella toimii? Mitä tapahtuu kun käyttäjä siirtyy sivulta toiselle? Miten sivulle suunniteltu responsiivisuus toimii käytännössä? Hyvä käyttöliittymäprototyyppi vastaa näihin ja moneen muuhunkin kysymykseen kevyesti ja tehokkaasti. Lisäksi käyttöliittymäprototyyppiä voi käyttää kevyeen käytettävyystestaukseen. Tämä on erityisen suositeltavaa projektin alkuvaiheessa jossa testattavaa tuotantoversiota ei vielä ole, mutta käyttöliittymäsuunnitteluun on hyvä saada palautetta suoraan oikeilta käyttäjiltä. Vaikka prototyyppi ei sisällä oikeaa toiminnallisuutta, moneen peruskysymykseen on mahdollista saada vastaus prototyyppitestaamisella.
Keveys ja tehokkuus ovat prototyypin rakentamisen kulmakiviä. Suunnittelijan on tunnistettava käytännön projektityössä milloin on oikea aika aloittaa protoilu, jotta työmäärä ja protosta saatava hyöty kohtaavat. Yleensä prototyyppiä ei kannata ryhtyä rakentamaan heti projektin alussa, sillä prototyyppi vaatii alleen perustellun käyttöliittymäsuunnitelman jonka peruskonseptit on jo ehditty keskustella ja iteroida asiakkaan kanssa kuntoon. Rautalankamalli sopii tähän työhön paremmin. Toisaalta prototyyppiä ei kannata jättää liian myöhäiseen vaiheeseen projektissa, sillä ihanteellisesti  sen tulisi olla kehittäjien ja asiakkaan arvioitavana ennen kuin tuotantoversion kehitys ehtii ajaa prototyypin ohi. Prototyypin tulisi yleensä olla myös tarpeeksi kevyt toteutus käyttöliittymästä, eikä sen yleensä tarvitse toteuttaa kaikkia suunniteltuja toiminnallisuuksia tai olla ulkoasultaan viimeiseen asti hiottu.
Hyväksi havaittuja prototypointimenetelmiä ovat paperiprototyyppi, suoraan suunnitteluohjelmistolla rakennettu prototyyppi sekä HTML-prototyyppi.
Paperiprototyyppi on kevyt ja erityisesti suunnittelun alkuvaiheessa tehokas menetelmä rautalangan testaamiseen ja iterointiin. Paperiprototyypissä käyttöliittymäsuunnitelma joko piirretään tai printataan paperille, ja käyttöliittymän toiminnallisuutta demonstroidaan vaihtamalla piirrosta tai sijoittamalla uusia paperinpaloja käyttöliittymään käyttäjän toiminnan mukaan. Paperiprototyypin hyviä puolia ovat sen edullisuus, nopeus sekä alhaiset tuotantokustannukset (kynä ja paperia). Huonona puolena paperi on aina paperia eikä välttämättä anna tarpeeksi realistista kuvaa käyttöliittymän todellisesta toimivuudesta.
Joillakin suunnitteluohjelmistoilla mahdollista rakentaa prototyyppejä suoraan rautalankamallien päälle. Käytännössä tämä tarkoittaa toiminnallisuuden lisäämistä suoraan rautalankaan. Lisäksi on palveluita jotka on suunniteltu nopeiden prototyyppien tuottamiseen. Tämäntyyppinen lähestymistapa voi olla nopea ja tehokas keino hahmottaa käyttöliittymän toiminnallisuutta, eikä vaadi käyttöliittymäsuunnittelijalta itseltään teknistä osaamista. Huonona puolena monimutkaisempien toiminnallisuuksien toteuttaminen suoraan suunnitteluohjelmistossa on usein jopa työläämpää kuin käsin HTML-koodin kirjoittaminen. Lisäksi ohjelmistolla tehtävä protoilu on aina riippuvainen ohjelmiston tarjoamista ominaisuuksista.
Paras mutta samalla vaativin prototypointikeino on HTML-prototyyppi, eli käyttöliittymäsuunnitelman toteuttaminen web-sivuna HTML-teknologioilla. HTML-prototyyppi antaa suunnittelijalle vapaat kädet toteuttaa suunnittelemansa käyttöliittymä juuri sellaisena kuin on sen tarkoittanut. Lisäksi se on realistisin ja lähinnä tuotantoversiota oleva keino protoilla. HTML-prototyyppi vaatii suunnittelijalta toteutusosaamista: vähintään HTML/CSS on oltava hyvin hallussa, mutta käytännössä myös Javascript-osaamisen täytyy olla hyvällä tasolla. Tämä asettaa haasteita prototyypin tehokkuusvaatimukselle, sillä HTML-proton rakentaminen voi helposti viedä liikaa aikaa erityisesti kokemattomammalta toteuttajalta. Onneksi nykyisin on tarjolla useita työskentelyä helpottavia käyttöliittymäkirjastoja kuten BootstrapjQuery UI tai Foundation, joilla on mahdollista tuottaa näyttäviä käyttöliittymiä nopeasti ja vaivattomasti.
Yleisesti ottaen käyttöliittymäprototyypin toteutuksessa on otettava huomioon projektin aikataulut ja suunnittelijan oman ajankäytön tehokas hyödyntäminen. Ennen prototyypin rakentamista on oltava selvillä millaisiin kysymyksiin se voi antaa vastauksia, ja mitä lisähyötyä siitä on pelkkään rautalankamalliin verrattuna (usein niitä löytyy lukuisia). Lisäksi prototyypillä voi olla erityisvaatimuksia jotka täytyy ottaa huomioon sen toteutuksessa. Tulisiko esimerkiksi HTML-prototyypin oltava sellaisenaan hyödynnettävissä tuotantoversiossa? Jos vastaus on kyllä, prototyypin laatuvaatimukset nousevat huomattavasti. Toisaalta osaavan tekijän käsissä prototyyppi on parhaimmillaan lähes sellaisenaan tuotantokoodia, mikä antaa varsinaiselle kehitystiimille suoraan aikaa ja mahdollisuuksia keskittyä hiomaan toiminnallista koodia, sekä parantamaan käyttöliittymätason toteutusta aikaisemmin kuin se muuten olisi mahdollista.
Prototyypin rakentaminen on projektityössä käytettävyystestaukseen verrattavissa oleva suunnittelun työkalu. Sen hyödyllisyyttä voi olla ennalta vaikea nähdä, mutta prototyypin tarjoamien uusien ideoiden ja parannusten kautta lopputuloksena on yleensä merkittävästi kohonnut suunnittelun laatu, parempi käyttäjäkokemus ja asiakkaalle pitkällä aikavälillä tätä kautta syntyvät kustannussäästöt tai parantunut myynti. Parhaimmillaan tyylikäs ja teknisesti laadukas prototyyppi on se tekijä, joka varmistaa että valmiin palvelun käyttäjäkokemus on ykkösluokkaa. Goforen UX-palveluissa prototyypit ovat kiinteä osa päivittäistä suunnittelutyötä.
 
 

 
Avatar

Matti Linna

Matti on käyttöliittymäsuunnittelija ja käytettävyysasiantuntija, jolla on monipuolista projektikokemusta raskaasta konepajateollisuudesta erilaisiin web-palveluihin. Matti on tehnyt paljon käyttäjätutkimuksia ja konseptisuunnittelutyötä haastavissa olosuhteissa sekä Suomessa että kansainvälisesti, ja Matin erityisosaamista on käyttöliittymäprototypointi mm. HTML5-, jQuery- ja Bootstrap-tekniikoilla. Matti työskentelee Goforella UX-suunnittelijana erilaisissa ohjelmistohankkeissa keskeisinä vastuualueinaan käyttöliittymäsuunnittelu, käyttäjälähtöinen määrittelytyö sekä käyttäjätutkimukset.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Toukokuussa 2014 julkaistu FlowIT-tutkimus paljastaa julkishallinnon tietotyöläisten haasteellisen arjen – 65 prosenttia kyselyyn vastanneista koki tietotekniikkaan liittyvien ongelmien haittaavan päivittäistä työntekoaan ja arvioi hukatuksi ajaksi neljä tuntia viikossa. Pelkästään menetettynä työaikana aiheutuu jopa 275 miljoonan euron vuotuinen kustannus valtiolle. Tutkimuksessa nostetaan esille keskeiseksi tekijäksi erilaiset käytettävyyteen ja käyttäjäkokemukseen liittyvät ongelmat. “Ehkä tässä on vielä vahva ajatus, että työympäristössä ihmisiä voidaan kouluttaa järjestelmien käyttämiseen. Sen sijaan pitäisi lähteä siitä, että uuden järjestelmän käyttöönotto voitaisiin tehdä kouluttamatta ihmisiä.” [1] Tähän ongelmakenttään voitaisiin vaikuttaa merkittävästi jo aikaisessa vaiheessa käyttäjälähtöisellä suunnittelulla.
Kehitysprojektien alkuvaiheessa on tyypillistä dokumentoida esimerkiksi sidosryhmiä, prosesseja, käyttötapauksia, tietorakenteita ja rajapintoja tavoitteena määritellä sekä asiakkaan liiketoiminta että tekninen ympäristö. Näistä uutetaan usein suoraan joukko vaatimuksia uudelle järjestelmälle tarkastelematta kuitenkaan aidosti ja määrämuotoisella tavalla käyttäjän tarpeita, motivaatioita ja käyttökontekstia. Tämän seurauksena myös erilaisten vaihtoehtoisten konseptien paremmuus käyttäjälle jää testaamatta. Tuoreen tutkimuksen mukaan esimerkiksi kokonaisarkkitehtuurityö näyttäytyy käytännössä useimmiten hyvin IT-keskeisenä [2]. Tulevien käyttäjien ja käyttäjien tarpeiden tunnistaminen ei ole useinkaan itsestään selvä osa projektien toimitussisältöjä, joten vaatimusmäärittelyssä ja toteutuksessa oikaistaan käyttäjälähtöisyyden kustannuksella. Joudutaan tilanteeseen, jossa jo alkuvaiheessa esitetään vaatimuksia, jotka ovat käyttäjien kannalta epämääräisiä ja jopa virheellisiä.
Jotta voitaisiin varmistua jo projektin alkuvaiheessa ollaanko ratkaisemassa oikeita asioita oikeilla lähestymistavoilla, tarvitaan selkeitä menetelmiä, joilla voidaan löytää ja testata nopeasti käyttäjien tarpeisiin pohjautuvia oletuksia. Käyttäjälähtöisen suunnittelun keskiössä on pitää käyttäjänäkökulmaa esillä koko projektin ajan monien eri menetelmien avulla. Käyttäjälähtöisen suunnittelun näkökulmasta projekti alkaa usein konseptisuunnittelulla, jonka avulla luodaan yhteinen visio toteutettavasta järjestelmästä. Konseptisuunnittelun ydintavoitteina on määritellä järjestelmän halutut liiketoimintavaikutukset, selvittää käyttäjätarpeita sekä luoda, priorisoida ja testata näihin perustuvia oletuksia ja suunnitteluratkaisuja yhdessä käyttäjien kanssa. Käyttäjälähtöisessä konseptisuunnittelussa on näin ollen sama pyrkimys kuin ketterissä projektimenetelmissä – pyrkimys “epäonnistua” nopeasti ja välttää tuotoksia, joiden merkitystä ja toimivuutta ei voida nopeasti arvioida.
Konseptisuunnitteluun soveltuvat käyttäjälähtöiset menetelmät voivat olla samoja kuin muissakin projektin vaiheissa – esimerkiksi sidosryhmähaastattelut, persoonat ja skenaariot, määrämuotoista prosessia seuraavat suunnittelutyöpajat (design studio), yhteenkuuluvuuskaaviot (affinity diagram), luonnokset (sketches), storyboardit, rautalankamallit ja eri tavoin toteutetut prototyypit. Joissakin tapauksissa voidaan tuottaa jopa jonkinlainen minimitoteutus (minimum viable product, MVP), jolla voidaan arvioida vaikkapa potentiaalisen markkinan suuruutta testaamalla yleisesti käyttäjien kiinnostusta. Uusien palveluiden ja tuotteiden innovoinnissa ja konseptoinnissa edellä mainittuja käyttäjälähtöisiä menetelmiä voidaan hyödyntää yhdessä erilaisten liiketoimintapainotteisempien discovery-menetelmien kanssa [4].
Konseptisuunnittelun aikana rautalankamalleilla tai kevyillä prototyypeillä on tärkeä tehtävä: niiden avulla voidaan arvioida varsin konkreettisesti eri suunnitteluratkaisuja käyttökontekstissa ennen tarkkoihin toteutusvaatimuksiin päätymistä. Karkeat luonnokset ja rautalankamallit ovat usein käytännöllisin tapa visualisoida ja hahmottaa vaikeitakin kokonaisuuksia. Samalla sidosryhmien huomio keskittyy käyttäjille tärkeimpien asioiden arviointiin. Konseptisuunnittelulla voidaan tutkia myös korkealla tasolla tietoarkkitehtuuria sekä tarvittavan tiedon ja toimintojen löytymistä. Huomioitavaa on, että liian laajat dokumentaatiot ja kaaviot sekä tarkkaan viimeistellyt käyttöliittymäsuunnitelmat konseptoinnin yhteydessä voivat nostaa kynnystä kommentoida ja tarvittaessa hylätä asioita. Konseptisuunnittelun haasteena on löytää suunnittelulle ja tuotoksille sopiva tarkkuus ja näkökulma, ettei päädytä vesiputousmallisesti määrittelemään järjestelmää toteutusnäkökulmasta yksityiskohtineen etukäteen.
Käytetyistä menetelmistä ja tuotoksista riippumatta on oleellista järjestelmällisesti priorisoida ja testata tunnistettuja oletuksia. Lisäksi on tärkeää pyrkiä konseptointiin väistämättä kuuluvasta kohinasta huolimatta kohti järjestelmän haluttuja vaikutuksia ja säilyttää kirkas kokonaiskuva. Onnistunut konseptisuunnittelu vaatii “komentoketjuista” riippumatonta rohkeutta kaikilta sidosryhmiltä – on uskallettava sanoa ääneen kun jokin esitetyistä oletuksista ei toimi tai keskustelu ajautuu väärille raiteille. ”If it disagrees with experiment, it’s wrong.” (Dr. Richard Feynman) [3]
Käyttäjälähtöisen suunnittelun menetelmillä aikaansaatu konseptisuunnitelma tuottaa jo aikaisessa projektin vaiheessa hyvin perusteltuja vaatimuksia ja suunnitteluratkaisuja. Korkealaatuinen konseptisuunnitelma tarjoaa vankan lähtökohdan päätöksenteolle, suunnittelun tarkentamiselle ja toteutuksen aloittamiselle. Tuloksena on kivuttomampi toteutusvaihe, valmiin toteutuksen hyvä käyttäjäkokemus sekä parantunut käyttäjätyytyväisyys ja näiden kautta asiakkaalle syntyvät kustannussäästöt. Konseptisuunnitelma ei ole kuitenkaan yksinään ratkaisu kaikkeen – sen yhteydessä ei yleensä kuvata tarkkaan teknisiä yksityiskohtia eikä testata esimerkiksi käyttöliittymän yksityiskohtia ja lopullista käytettävyyttä. Siksi käyttäjälähtöinen suunnittelu ei rajoitukaan vain projektin alkuvaiheisiin – toteutuksen alkaessa käyttäjälähtöisen suunnittelun menetelmillä pureudutaan yhä tarkemmin yksityiskohtiin, arvioidaan toteutuksen vastaavuutta käyttäjien tarpeisiin ja reagoidaan muuttuneisiin tilanteisiin ja mahdollisiin teknisiin rajoitteisiin. Käyttäjälähtöinen suunnittelu ei siis ole yksittäinen vaihe tai tuotos vaan luonteva osa koko ketterän projektin elinkaarta.
[1] http://yle.fi/uutiset/montako_tietojarjestelmaa_tyopaikallasi_on__trafissa_niita_on_170/7252898 (23.5.2014)
[2] Jakobsson, Aino: User-Centered Aspects in Enterprise Architecture Practices: Exploratory study on the Perceptions of Finnish Enterprise Architecture Practitioners (2014)
[3] Gothelf, Jeff & Seiden, Josh: Lean UX (2013)
[4] McGrath, Rita Gunther & MacMillan, Ian C.: Discovery-driven growth: a breakthrough process to reduce risk and seize opportunity (2009)

Avatar

Jarmo Korhonen

Jarmo is Senior User Experience Designer at Gofore. Being Master of Economics in Information System Sciences and Business Strategies. He knows how to combine user needs with today’s cutting edge technology, mobility and business models. During his 15+ years in the software business, Jarmo has also been invited to speak at international conferences such as JavaOne (US) and SVG Open (DE). But that’s not all – He is also an experienced visual and interaction designer, creating designs that make awesome digital services. Jarmo loves to work fast and lean, and focus on creating real value to the users at every step on the way.

Piditkö lukemastasi? Jaa se myös muille.

Edellisessä blogissani nostin kokonaisarkkitehtuurin (KA) kehittämismenetelmien tärkeäksi osa-alueeksi asiakkaan ja palveluntuottajan välisen vuorovaikutuksen kehittämisen. Asiakas ja substanssinäkökulman mukaan tuominen hukkuu usein erilaisten tietojärjestelmärakenteiden – ja ratkaisujen kehittämisen haasteiden alle. Näin ei kuitenkaan tarvitse olla. Siinä missä ohjelmisto- ja tietojärjestelmäkehittäminen ovat tuoneet ketterät menetelmät Lean-metodien rinnalle, on asiakaslähtöisten palveluiden kehittämisestä nousemassa merkittävä metodologia. Näillä metodologioilla voidaan parantaa asiakkaan ns. 360 asteen näkymää ja tapoja tuottaa onnistuneita lopputuloksia (kuva 1.) niissä vuorovaikutuspisteissä, joissa asiakas kytkeytyy palveluita tarjoavan organisaation prosesseihin – olivat ne sitten myynnin, toimituksen tai jatkuvien palveluiden prosesseja. Ei siis aivan sattumaa, että näitä vuorovaikutuspisteitä kutsutaankin ”totuuden hetkiksi” (engl. ”Momenths of Truth”). Goforella käytämme useita asiakaslähtöisiä metodeja, joista tässä blogissa käsittelen palvelumuotoilua. Tulevissa blogeissa keskityn syvemmin prosessien suunnitteluun ja optimointiin asiakaslähtöisesti (mm. Customer Expectation ja Experience Management, Service ja Value blueprint sekä Design for Six Sigma).
360astetta
Kuva 1. Asiakkaan vuorovaikutuspisteiden arviointi ja systemaattiset kehittämisen menetelmät
Palvelumuotoilu on yksi asiakaspalveluiden kehittämisessä käytetty menetelmä, jossa palveluntarjoaja keskittyy jaetun lisäarvon tuottamiseen asiakaslähtöisesti sekä laadullisesti että taloudellisesti mitattuna. Tärkeätä on myös valmentaa asiakasta ja palvelun järjestävää organisaatiota varautumaan tarjottavien palveluiden aiheuttamiin muutoksiin aikaisessa vaiheessa ennen kuin tieto- ja viestintäteknisiä ratkaisuja on otettu käyttöön. Sosiaalisten ja teknisten tekijöiden tasapainottamisessa muutoshallinnalla onkin tärkeä rooli. Palvelumuotoilun vaiheet (kuva 2.) ja esimerkkejä niissä käytettävistä menetelmistä ovat:

  • Asiakasymmärrys, mm. havainnointi, fokusryhmähaastattelu ja yhteiset työpajat, innovointimenetelmät
  • Konseptointi, mm. osallistava suunnittelu
  • Prototypointi, mm. vuorovaikutuspisteiden tunnistus ja käyttöliittymien prototyyppien rakentaminen
  • Toteutus ja käyttöönotto, ketterän kehittämisen periaatteet
  • Arviointi ja jatkuva parantaminen, mm. palautteen systemaattinen kerääminen ja arviointi, prosessien optimointimenetelmät ja jatkuva parantaminen

palvelumuotoilun vaiheet
Kuva 2. Palvelumuotoilun vaiheet
Olemme kollegani Juha Siltasen kehittämän palvelumuotoilun menetelmiä noudattavan pohjan (kuva 3.) avulla konseptoineet sähköistä asiointia asiakkaidemme kanssa. Työpajatyöskentelyllä olemme käyneet läpi asiointipolun vaiheita. Vaiheet voidaan yleisesti jakaa asiointia tai palvelua edeltävään vaiheeseen, itse asiointitapahtumaan ja palvelun jälkeiseen vaiheeseen. Olemme alla olevaan pohjaan keräämällä tunnistaneet jokaiseen vaiheeseen liittyviä keskeisiä tekijöitä ja painopisteitä. Työpajan tuloksena on muodostettu yhteinen käsitys kehitettävän palvelun tavoitetilasta ja vuorovaikutukseen liittyvistä kehittämiskohteista, esimerkiksi mitä taustajärjestelmiä vuorovaikutukseen liittyy ja kuinka asiointitapahtuman jälkeen asiakasta tulisi ohjata.
Palvelumuotoilun20konseptointi
Kuva 3. Palvelumuotoilun hyödyntäminen sähköisen asioinnin konseptoinnin välineenä
Sähköisen asioinnin ja palveluiden suunnittelussa tulisi käyttää yhteistä lisäarvoa tuottavia parhaita menetelmiä. Liiketoiminnan puolella palaava asiakas edustaa hankintakustannukseltaan murto-osaa uuden asiakkaan hankinnan vaatimista kustannuksista. Julkisella puolella palveluita siirretään sähköisen asioinnin piiriin kustannussyistä. Kummassakin tapauksessa jo pelkästään taloudellisista syistä tulisi asiointipolun suunnittelussa varmistaa, että asiakas sekä säilyy että tarvittaessa palaa helposti palvelun käyttäjäksi. Palvelumuotoilu on yksi näistä menetelmistä, jonka avulla olemme pyrkineet varmistamaan, että KA-kehittämistyössä huomioidaan asiakkaan näkökulma ja että sen vaikutusalue on mahdollisimman laaja. Näen kuitenkin, että palvelumuotoilun lisäksi on syytä käyttää myös muita asiakaslähtöisiä kehittämismenetelmiä, esimerkiksi prosessien kuvaamisessa, jotta asiakaslähtöisyys pysyy systemaattisena läpi KA-kehittämissyklin.
 

Avatar

Tahvo Hyötyläinen

Tahvo on laaja-alaisen kokemuksen hankkinut kokonaisarkkitehtuurin asiantuntija, joka on väitellyt liiketoimintaprosessien hallinnan ja järjestelmien kehittämisestä. Hän on toiminut vanhempana arkkitehtina niin yritysmaailman kuin julkishallinnon kokonaisarkkitehtuurien projekteissa. Tahvolla on myös pitkä kokemus ohjelmistoarkkitehtuureista. Nykyisin Tahvo työskentelee kokonaisarkkitehtuurin suunnittelun, hallinnan ja johtamisen konsulttina. Tahvo on sertifioitu prosessien ammattilainen (Certified Process Professional) ja Data Vault 2.0 harjoittaja.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.