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