Design system ilman näkemystä ja pelisääntöjä on vain unohdettujen komponenttien tunkio

Designin jakaminen kehityshankkeiden kesken voi säästää rahaa ja parantaa käyttökokemusta, mutta pelkkä komponenttikirjasto ei riitä. Termi "design system" viittaakin paitsi rakennuspalikoiden kokoelmaan, myös organisaation ehdoilla määriteltyihin työtapoihin ja pelisääntöihin.

Moni organisaatio kehittää useita verkkopalveluja tai sovelluksia eri sidosryhmille. Kasvavat asiakasodotukset nostavat jatkuvasti käyttökokemuksen rimaa, mikä tuottaa painetta synnyttää laadukkaita ratkaisuja nopeasti. Samaan aikaan on havahduttu siihen, että laadukas design ei skaalaudu vain lisäämällä suunnittelijoiden määrää. Eheän käyttökokemuksen tarjoaminen hankaloituu sitä mukaa kun palveluja synnytetään lisää tai kun kehitystiimit kasvavat. Kehitystiimit päätyvät ajan myötä keksimään samoihin ongelmiin useita erilaisia ratkaisuja, lisäten monimutkaisuutta ja kustannuksia palvelujen ylläpitoon.

Moni taho onkin tunnistanut tarpeen jakaa tehtyjä ratkaisuja ja toteutustapoja projektien kesken. Johdonmukaista käyttökokemusta pyritään monesti varmistamaan muodostamalla jaettu kirjasto palvelun visuaalisista ja toiminnallisista peruselementeistä — kuten esimerkiksi väreistä, fonteista, lomake-elementeistä ja navigaatiokomponenteista. Näin tavoitellaan aika- ja kustannussäästöjä, kun käyttöliittymiä ja toteutustapoja ei tarvitse joka kehitysprojektissa miettiä alusta asti. Tällaista rakennuspalikoiden kokoelmaa saatetaan kutsua esimerkiksi komponenttikirjastoksi, tyylikirjastoksi tai trendikkäästi design systemiksi.

Komponenttikirjastot rakentuvat usein atomiselle ajattelulle, jossa vakioituja peruspalikoita yhdistellään eri tavoin monimutkaisempien ratkaisujen muodostamiseksi.

 

Onnistuneesti jalkautetun design systemin tuottama kustannussäästö voi kehitysorganisaation koosta riippuen olla vuosittain kymmeniä tai satoja tuhansia. Monesta design systemistä kuitenkin puuttuvat laadun ja onnistumisen kannalta tärkeimmät elementit, eli selkeä omistajuus, tavat toimia sekä näkemys siitä, millaisten palvelujen rakentamista ja kenelle design system itseasiassa palvelee.

Henkilöityykö ajattelu?

Kenties kehitystiimistä löytyy design-ratkaisujen systematisoinnista innostunut suunnittelija tai front end -sovelluskehittäjä. Ehkä tämä innokas tiiminjäsen ilmoittautuu vapaaehtoiseksi rakentamaan ja ylläpitämään design systemiä. Alkuvaiheessa kaikki voi näyttää hyvältä. Ajan myötä tästä henkilöstä muodostuu kuitenkin valtava ymmärryksen ja kehityksen pullonkaula, ja koko sovelluskehityksen työnkulku hidastuu.

Ei riitä, että komponentti on lisätty kirjastoon, jos vain yksittäiset ihmiset tietävät. miten komponentti toimii tai miksi se on suunniteltu sellaiseksi kuin se on. Tällaisessa tilanteessa komponentti happanee, kun sen rinnalle syntyy uusia ratkaisuja, kun vanhaa ratkaisua ei ymmärretä tai osata jatkokehittää.

Jotta design system on enemmän kuin siitä innostuneiden harrastamista, se tarvitsee tuekseen vakiintuneet käytännöt ja systemaattiset toimintatavat ymmärryksen jakamiseksi eri roolien kesken. Design system ottaa kantaa siihen, miten designia organisaatiossa tehdään, miten sitä hallinnoidaan.

Myös itse design systemin käytettävyys on huomioitava: jos sen käyttäminen edellyttää esimerkiksi sellaista teknistä osaamista tai työkaluja, joita kaikilla palvelukehitykseen osallistuvilla ei jo valmiiksi ole, on todennäköistä, että tekijä tarttuu mieluummin itselleen tuttuihin välineisin ja vanhentuneisiin työtiedostoihin.

Heiluttaako häntä koiraa — eli johtaako komponenttikirjasto suunnittelua?

On tietysti keskeistä, että design systemiä on helppo käyttää itse kehitystiimin näkökulmasta, ja että kirjasto tuottaa arvoa suunnittelun työnkululle. Jotta ratkaisujen jakamisesta ja systematisoinnista tulee vakiintunut tekemisen tapa, palvelukehityksen tulee olla helpompaa design systemin kanssa kuin ilman sitä. Organisaatiot ovat myös erilaisia. Yhdessä organisaatiossa toimivat designin hallintamallit eivät sovi kaikille. Jotta tunnistetaan ne kipukohdat, joita design systemillä juuri tietyssä organisaatiossa ensimmäisenä kannattaa lähteä ratkomaan, on osallistettava design systemin sisäisiä ja ulkoisia käyttäjäryhmiä.

Kenties suurin vaara on, että ongelman ratkaisemisesta kirjastoon jo tehdyillä palikoilla tulee tärkeämpää kuin ongelman ratkaisemisesta liiketoiminnan kannalta parhaalla tavalla. Jos uuden design-ratkaisun luominen on hyvin byrokraattinen ja hidas prosessi, ja tavoitteena on orjallisesti minimoida uusien ratkaisujen määrä, design system kääntyy helposti itseään vastaan. Jos komponenttikirjastoon on luotu komponentti verkkosivuston käyttökontekstiin, organisaatiossa voi olla vaikea ymmärtää tarvetta kehittää mobiilisovellukselle omaa, erillistä komponenttiaan, vaikka loppukäyttäjän odotuksien palvelemisen kannalta tarve olisi itsestäänselvä.

Tuskin kukaan haluaa päivittäisessä työssä taistella prosesseja vastaan. Jos tällaiseen tilanteeseen joudutaan, kynnys muutosten ehdottamiseen kasvaa, silloinkin kun muutokset olisivat loppukäyttäjän ja liiketoiminnan kannalta aiheellisia. Elävän ja kehittyvän design systemin sijaan käsissä onkin pian akateeminen harjoitus, jolla ei ole toivottua vaikutusta käyttökokemuksen laatuun, ja pahimmassa tapauksessa ratkaisuja, joita aiemmin olisi ehdotettu uusiksi design systemin osiksi, tehdään surutta prosessin ohi kertaluontoisina ratkaisuina, mikä kasvattaa kustannuksia ja vaikeuttaa kokonaisuuden hahmottamista ylhäältä päin.

Kompakti, elegantti ja päällekkäisyyksiä minimoiva komponenttikirjasto, jota kukaan ei kehitä tai käytä, ei ole läheskään yhtä arvokas kuin rönsyilevä mutta tekemisen kulttuuriin saumattomasti omaksuttu design system.

Kehitetäänkö lopulta komponentteja vai palveluja?

Silloinkin, kun komponenttikirjasto tai design system on ymmärrettävä ja helppokäyttöinen kaikille sitä käyttäville tahoille, voi olla vaikea nähdä metsää puilta. Yksittäisten osasten suunnittelu tyhjiössä ilman kokonaiskuvan hahmotusta tuottaa näkemyksetöntä designia, joka riittää kehitystiketin kuittaamiseen, mutta ei vie liiketoimintaa eteenpäin.

Komponenttikirjastoja rakentaessaan moni organisaatio keskittyy turhankin paljon yksittäisiin palasiin sen sijaan, että pyrittäisiin osoittamaan, miten palasista muodostetaan tehokkaita ja liiketoimintaa palvelevia kokonaisuuksia. Pelkän komponenttien katalogin sijaan komponenttikirjaston tulisi tarjota konkreettisia esimerkkejä siitä, miten ratkaisuja sovelletaan käytännössä ja miksi juuri kuvatut sovellutukset toimivat parhaiten palvelukonseptin näkökulmasta.

Eleganttien komponenttien luominen ei saa muodostua itse tarkoitukseksi ja palvelukehityksen viime käden tavoitteeksi. Yhtenäisyys ja tehokkuus ei saa olla tärkeämpää kuin loppuasiakkaan ja oman liiketoiminnan tavoitteiden palveleminen. Design systemkin on viime kädessä kuitenkin vain väline, joka edesauttaa hyvien ja johdonmukaisten käyttökokemusten tuottamista kustannustehokkaasti—mahdollistaen hyvän palvelun.

Lisälukemista

Tilaa Palmun uutiskirje

Mistä me puhumme, kun puhumme Business Designista?

Palvelumuotoilu tai muotoiluajattelu (‘service design / design thinking’) ovat siitä hauskoja, että ne taipuvat moneen. Viime vuosien hype-sana on monen mielessä jo hieman kulahtanut (ja alan sisälläkin riittää kriittisiä tekstejä), mutta kokemuksemme on osoittanut, että muotoiluajattelun ytimessä on paljon arvokasta, josta pitää kiinni. Vuosi vuodelta Palmun projektien pääpaino onkin siirtynyt yhä isompien liiketoiminnallisten kysymysten ratkaisemiseen, ja palvelumuotoilun rinnalla puhumme nykyään liiketoiminnan muotoilusta eli alan termein Business Designista.

Business Design keskittyy yrityksen liiketoiminnan kehittämiseen asiakaslähtöisesti

Liiketoiminnan näkökulman tulisi aina olla palvelukehityksen ytimessä asiakasarvon* rinnalla. Liiketoiminnan suunnittelijoina emme ole unohtaneet perinteisiä analyyttisia menetelmiä, numeronmurskausta tai excel-labyrintteja, mutta tuomme yhtälöön lisää realismia asiakasymmärryksellä ja kokonaisuutta todentavilla kokeiluilla. Tulevaisuuden kilpailuetu rakennetaankin empiirisellä ymmärryksellä numeroiden ja datan takana.

Business Designerit tarttuvat haasteisiin analyyttisella mindsetilla, mutta suunnittelijan elkein. Täydennämme asiakasymmärrys- ja suunnittelijaduon trioksi – katsomme palvelukehitystä liiketoiminnan näkökulmasta. Oivallukset syntyvät kun yhdistämme analyysit empiiriseen ymmärrykseemme markkinasta sekä yrityksen liiketoiminnan rakenteista. Kannattavan liiketoiminnan takana on aina kaksi joukkoa ihmisiä: niitä, jotka kuluttavat arvoa tuottavia palveluita sekä niitä, jotka osaavat muuttaa asiakasarvon liiketoiminnaksi. Ilman asiakasarvoa ei ole liiketoimintaa – ja Business Designer haluaa ymmärtää molemmat.

Hyvät Business Designerit eivät millään mahdu yhteen muottiin…

… mutta selkeitä yhdistäviä tekijöitä löytyy muutamia. Liiketoiminnallista yleissivistystä on kertynyt joko aiemmasta liiketoimintavastuusta, johdon konsulttina tai koulun penkkiä kuluttamalla. Numerot eivät aiheuta rimakauhua ja looginen päättelykyky on rautaa. Vastapainoksi Business Designerilla on kuitenkin luontainen kiinnostus ihmisiin ja ilmiöihin aina yksittäisestä kuluttajasta komplekseihin markkinailmiöihin asti, sekä luovuus ja avoimuus suunnitella ratkaisuja. Suunnittelijan tavoin Business Designer ei rakentele täydellisiä mallinnuksia omassa datakammiossaan, vaan kokeilee ja validoi ideoita hypoteesi kerrallaan.

Meillä Palmussa Business Designer tekee projekteja osana eri alojen osaajista koottua suunnittelutiimiä. Kaikilla on vapaus ja vastuu omasta työstään, emmekä usko hierarkian tai valmiiden sapluunojen lisäävän lopputuloksen laatua. Edellytämme ajattelua parhaiden käytäntöjen ja benchmarkien ulkopuolelta, niitä kuitenkaan unohtamatta. Tukenamme on Palmun monialainen työyhteisö sosiologeista UX-suunnittelijoihin, joka haastaa meitä kehittämään omaa osaamistamme ja työtämme. Parhaan lopputuloksen ja yhteistyön takana on molemminpuolinen arvostus ja yhteinen halu ratkaista yhä haastavampia ongelmia.

*Asiakasarvolla tarkoitamme sitä arvoa, minkä palvelun ostaja tai käyttäjä palvelusta saa.

Kirjoituksen takana ovat Business Designerimme Jaakko Luomaranta ja Tiina Korvenoja. Jos sinusta tuntuu, että meillä voisi olla yhteistä – etsimme suunnittelija yhteisöömme parhaillaan uuden rakentamisesta innostuvia Business Designereita. Haku on auki huhti-toukokuussa 2018.

Asiakaslähtöisyys – sanahelinästä arjen todellisuudeksi

”Kyllä me teemme asiakastutkimusta: kerran vuodessa lähetämme kaikille asiakkaillemme asiakaskyselyn! Olemme todella asiakaslähtöinen yritys!”

Jos yritysjohtoa kuuntelee, niin kaikki yritykset ovat nykyään asiakaslähtöisiä. Yhä useammalla tämä lukee strategiassa asti. Ollaan oman asiakkaan kumppaneita, luotettuja neuvonantajia, erinomaisen asiakaskokemuksen tarjoavia toimittajia tai asiakkaan keskiöön laittavia uudistajia.

Tästä huolimatta, kun kysymme, keitä yrityksen asiakkaat ovat, mikä heille luo arvoa ja millaisia ongelmia he kohtaavat, palaveripöydän ääressä on usein hiljaista. On aivan tyypillistä, ettei koko tilaajamme projektitiimissä ole yhtäkään henkilöä, joka olisi ikinä jutellut asiakkaan kanssa.

On aivan tyypillistä, ettei koko tilaajamme projektitiimissä ole yhtäkään henkilöä, joka olisi ikinä jutellut asiakkaan kanssa.

Usein strategiassa mainittu asiakaslähtöisyys tarkoittaa todellisuudessa sitä, että asiakas on läsnä vain palaverihuoneessa istuvan projektitiimin ajatuksissa. Tällöin vaarana on, että ratkaistavat asiakkaan ongelmat alkavat epäilyttävästi muistuttaa projektitiimin itsensä kokemia haasteita.

Palveluita suunnitellessa puhutaan kyllä asiakkaista, mutta asiakkaan kuuntelemisen sijaan pelataan oletuksilla ja mielikuvilla. Asiakastietoakin kerätään lähinnä segmenteistä ja ennemmin raportointia kuin suunnittelua varten.

Hieman uskaliaammilla oikeat asiakkaat ovat kuvioissa mukana: heitä lähestytään vuosittaisin kyselyin tai he pääsevät osallistumaan käytettävyystesteihin. Asiakkaan ääni siis kuuluu – mutta mistä annamme hänen puhua? Entä ymmärrämmekö, miksi hän vastaa niin kuin vastaa?

Asiakaskyselyistä kerätty ymmärrys on tyypillisesti yleismaailmallista, yhteismitallista ja jää herkästi irralliseksi palvelukehityksestä. Käytettävyystesteissä taas saamme kyllä selville, että digipalvelun navigaatiossa on korjattavaa, mutta käykö ilmi, tulisiko kyseistä palvelua ylipäätään rakentaa?

Asiakaskyselyistä kerätty ymmärrys jää herkästi irralliseksi palvelukehityksestä.

Palvelumuotoiluprojekteissa nämä ongelmat taklataan ottamalla asiakas mukaan alkumetreiltä asti. Asiakas siis pääsee kertomaan ja kuvailemaan, miten hän tällä hetkellä toimii, millaisia ongelmia hän kohtaa, mikä on hänelle arvokasta ja mitä hän tavoittelee – sekä ennen kaikkea, miksi.

Tämän ymmärryksen rakentaminen suunnittelun osana on korvaamatonta, sillä tällöin opit ja oivallukset liittyvät kontekstiin ja johtavat päätöksiin: turha palvelu voidaan jättää tekemättä ja epämääräiselle kokonaisuudelle voidaan löytää todellinen kärki.

Yksittäiset palvelumuotoiluprojektit kaipaavat kuitenkin tuekseen jatkuvaa asiakkaan pulssin seurantaa. Vasta tällöin yritys voi todella tehdä pidemmän tähtäimen linjauksia asiakaslähtöisesti. Jatkuvan dialogin ja siihen pohjautuvien täsmäprojektien yhdistelmä tekee asiakaslähtöisyydestä arjen todellisuutta sanahelinän sijaan.

Jatkuvan dialogin ja siihen pohjautuvien täsmäprojektien yhdistelmä tekee asiakaslähtöisyydestä arjen todellisuutta sanahelinän sijaan.

Mitä suurempi organisaatio, sitä vaikeampi hyppy suoraan syvään päähän on. On jäykkiä rakenteita, siiloja, budjetteja ja IT-ongelmia – ja nämä kaikki ovat täysin ymmärrettäviä haasteita.

Kehotan kuitenkin pohtimaan, miten voisitte yrityksenä ottaa askeleen nykyiseltä asiakaslähtöisyyden tasolta seuraavalle. Mitä konkreettista voisitte tehdä, jotta asiakaslähtöisyys ei olisi vain hieno sana strategiassa vaan todellista toimintaa arjessa?

Osallistu keskusteluun Twitterissä: @Palmu_Finland.

Tiina Toskovic on palvelumuotoilija, jonka sydän sykkii loppuasiakkaiden käyttäytymisen, tarpeiden ja ongelmien ymmärtämiselle.