Ei pitkäkään aika sitten minulta kysyttiin: ”Miten ihmeessä muka DevOps ja UX liittyvät toisiinsa?”. Asiaa pohtiessani ymmärsin, ettei yhteys näiden kahden välillä ole se kaikista selvin – eikä ihme. Varmasti itse kukin tätäkin lukiessa pohtii, mitä yhteistä on DevOps:lla, joka korostaa tietynlaista yrityskulttuuria ja UX:llä, joka vaatii käyttäjien aktiivista ja jatkuvaa osallistamista. Jotta yhteys ei olisi enää niin epäselvä, yhteyden voisi kiteyttää kolmeen keskeiseen teemaan.
Kaiken takana on avoimuus
Yksi keskeisistä mantroista UX-työssä on pyrkimys pois käyttäjän elämään vaikuttavista päätöksistä, jotka syntyvät suljetuissa neuvotteluhuoneissa. UX (User Experience, suom. käyttäjäkokemus) on kiteytettynä se muistijälki, joka käyttäjällä on mielessään kokemuksestaan palvelun kanssa. UX-työn, joka pyrkii tuottamaan positiivisia käyttäjäkokemuksia, keskiössä on todellisten käyttäjien osallistaminen. Tämä ei johtoryhmän kokouksessa toteudu. Parhaat käyttäjäkokemukset syntyvät käyttäjien ääntä kuuntelemalla – näin se on. Samalla kun pyritään irti suljettujen kerhojen päätöksistä, puhutaan modernissa tehokkaassa UX-työssä niiden samojen sidosryhmien osallistamisesta, jotka piileksivät neuvotteluhuoneessa.
Parhaimmat käyttäjäkokemukset saavutetaan tehokkaalla UX-työn jalkauttamisella, joka ottaa huomioon sidosryhmien ammattitaidon omasta käyttäjäkokemukseen vaikuttavasta vastuualueestaan. UX-työ onkin monesti sidosryhmien osallistamista, mutta valitettavan usein tietynlaisissa siiloutuneissa yrityskulttuureissa se ei ole kovin yksinkertaista, eikä ainakaan tehokasta. UX-ammattilaisen näkökulmasta sitä ottaakin vastaan iloiten DevOps:n mukanaan tuoman avoimuuden, joka tehostaa UX-työn keskeistä työtehtävää: kommunikaatiota sidosryhmien välillä. Mikäs sen parempi ajatus kuin tieto, että paremmalla yrityskulttuurilla voidaan saada käyttäjän ääni kuulumaan läpi organisaation. DevOps ja UX toivovat siis samaa avointa, toista arvostavaa, keskustelukulttuuria.
Se että nykyaikana yrittäisi olla ottamatta sidosryhmiä huomioon, onkin lähinnä huvittava ajatus. Nyt, jos koskaan tekijät koodareista järjestelmäasiantuntijoihin ja myyntiin ovat entistä tietoisempia, miltä hyvä käyttäjäkokemus tuntuu. Jotta tällaisessa tilanteessa UX-työ johtaa parhaimpaan lopputulokseen, tulee sen noudattaa DevOps:n viitoittamia ohjeita: yhteistyö, yhteinen tietoisuus ja yhteiset tavoitteet.
Mittaamattoman arvokas mittari
Ensimmäisiä asioita, joita minullekin Käytettävyyden perusteet -kurssilla aikoinaan sanottiin, oli ”Käytettävyys on mitattava määre”. Vaikkei asiaa usein sanota, niin sama pätee käyttäjäkokemukseen. Olipa tutkittavana melkein mikä vaan käyttäjäkokemukseen vaikuttava tekijä – tehokkuus, helppokäyttöisyys tai vaikka tarkoituksenmukaisuus – on sen toteutumista mahdollista seurata mitattavassa muodossa. UX-työ on parhaimmillaan laadullisen ja määrällisen työn tulosta, jossa määrälliset mittarit kuvaavat ”mitä” ja laadulliset tulokset kertovat ”miksi”. Käyttämällä analytiikkaa oikein voi käyttäjäkokemuksen kehitystä ja siihen vaikuttavien tekijöiden tilaa seurata tehokkaasti omissa palveluissaan. Tärkeintä on löytää sopivin yhdistelmä määrällisiä ja laadullisia menetelmiä, joilla voidaan seurata, miten saavutamme tavoitetilamme mukaisen käyttäjäkokemuksen.
Voidaankin kysyä, mitä olisi DevOps ilman UX-työn tuomaa käyttäjän ääntä palautteena?
DevOps vaatii ja hyötyy merkittävästi laadukkaista palautevirroista, jota UX-työ luontaisesti tarjoaa osana toimintatapojaan, ja on UX-työn keskiössä. Mitä UX-työ olisikaan ilman, tässäkin jutussa painotettua, käyttäjien osallistamista, joka johtaa palautevirtoihin? Käyttämällä tehokkaasti hyvin laadittuja mittareita, niin analytiikkapohjaisia määrällisiä kuin myös laadullisia, voidaan käyttäjien ääni tuoda osaksi organisaation kehitystä. Voidaankin kysyä, mitä olisi DevOps ilman UX-työn tuomaa käyttäjän ääntä palautteena?
Kevyin askelin yhdessä
Siinä missä Lean on vallannut ohjelmistokehityksen, on se myös vallannut alaa UX-työssä, termin ”Lean UX” alla. Samoin kuin DevOps kannustaa jatkuvaan kehittymiseen niin tekee myös Lean UX. Lean UX kiteyttääkin monia asioita, joita tässäkin tekstissä on sivuttu puhuttaessa DevOps:n ja UX:n yhtäläisyyksistä. Jos Lean UX:n ydinajatuksen haluaa tiivistää, voi sanoa sen lähtevän liikkeelle luottamuksesta palautteen voimaan. Ei ylisuurta määrittelyä vaan pieniä palasia lisää, joita arvioidaan tehokkaasti käyttäjien avulla. Saamme palautetta, kehitymme ja parannamme. Lean UX:n mukaisen toiminnan voi kiteyttää toistuvaan sykliin: suunnittele – toteuta – evaluoi. Jatkuvan kehittymisen ajatuksella emme koskaan ole valmiita vaan matkaamme aina kohti parempaa, joka perustuu kerättyyn palautteeseen. Palautteeseen, johon luotamme. Pienet epäonnistumiset eivät haittaa, sillä Lean UX kannustaa pieniin askeliin.
Lean UX painottaa myös eri sidosryhmien osallistamista. Jotta voimme tehdä valistuneita päätöksiä käyttäjälle tarjottavasti palvelusta, pitää meidän osallistaa sidosryhmiä. Takana ovat ne ajat, kun käyttöliittymät ja visuaaliset ilmeet suunniteltiin norsunluutornissa, ja kuin taivaan lahjana ne toimitettiin toiseen siiloon photoshopilla piirrettynä kuvana. Edessä on DevOps-aikakausi, jossa eri toimijat toimivat lean-periaatteiden mukaisesti yhdessä – tehokkaasti, kevyesti ja yhteishyödyllisesti. Painotan usein Goforen UX-suunnitelijoille, että yksi tärkeimpiä heidän tehtäviään on miettiä, edistääkö tekeillä oleva asia työn jalkautumista eteenpäin. Jokaisen ammattitaitoisen UX-suunnittelijan vastuulla onk toimia tehokkaana osana avointa toimintayhteisöä, jossa hänen tuotoksensa heijastavat käyttäjän ääntä ja ottaa huomioon vastaanottavat ja osallistuvat sidosryhmät. Tätä on myös DevOps.
Mitä siis olisi DevOps ilman UX:ää tai UX ilman DevOps:a? Vastaus lienee, että UX-työ ja DevOps eivät kunnolla toteudu ilman toista – niin kiinteästi ne ovat osa toisiaan.