Design system – tuote, ei projekti 

UX Designin pelikirjan seitsemäs kappale
UX Designin maailma on täynnä erilaisia strategioita, joilla muovaamme laadukasta ja vaikuttavaa käyttökokemusta. Se on pelikirja, jonka neljäs kappale tämä blogikirjoitus on. Yksi blogikirjoitus kerrallaan paljastuu uusi pelitaktiikka, ja rakentuu UX-tietämyksen pelikenttä, jonka jokaista pelipaikkaa ja olosuhdetta hallitsemme pelikirjan kuvioilla. Tämä kappale lisää peliimme osa-alueen, jonka tulisi ulottua organisaation jokaiseen nurkkaan toimiakseen hyvin. Kyseessä on siis yet another description of design system.

Tällä kertaa pelikirjan kappaleen on rustannut design systemien maailmassa marinoitunut TeamIT:n suunnittelija.

Mikä on design system ja mitä se ei ole?

Design system ei ole yksikään seuraavista yksinään eikä yhdistettynäkään: visuaalinen ohjeisto, ui kit tai komponenttikirjasto. Pääpiirteissään se tarkoittaa kahta asiaa:

1. se on kokoelma komponentteja ja niistä koottuja käytäntöjä, joita
2. ohjaavat ennalta määritetyt prosessit.

Kokoelma sisältää uudelleenkäytettäviä komponentteja, joiden takana on selkeät standardit. Näitä komponentteja voidaan yhdistellä, jotta saadaan aikaan yksi tai useampi applikaatio, joilla on yhtenäinen look and feel. Perustana toimii brandiohjeistus, jonka pohjalta valmistetaan komponentit UI Kitiin. Näiden komponenttien perusteella kehittäjät toteuttavat vastaavat komponentit komponenttikirjastoon. Kaiken tämän liimana toimivat design tokenit – suunnittelupäätösten alustariippumaton koodattava muoto, joka mahdollistaa saumattoman kommunikaation suunnittelijoiden ja kehittäjien välillä. Ja jotta systeemi voi toimia moitteettomasti, kaikkea tätä ohjaa taustalta organisaation läpileikkaava prosessi.

Mitä tarvetta varten design system rakennetaan?

Syitä ja tapoja rakentaa design system on monia, mutta karkeasti ottaen voidaan erotella kaksi erilaista tarvetta.

Ensimmäisessä lähestymistavassa systeemi rakennetaan pala palalta eli jokainen lisättävä elementti vastaa olemassa olevaan tarpeeseen. Tällöin ratkaisuja kehitetään konkreettisten käyttötilanteiden pohjalta.

Toinen tapa on niin sanottu ”kaiken varalta” -lähestymistapa, jossa pyritään luomaan kaikki mahdollisesti tarvittavat elementit valmiiksi. Tämä kertoo usein siitä, että systeemi saattaa olla olemassa yleisempää käyttöä varten kuten esim. Bootstrap tai vastaavanlaiset. Tällöin systeemi kaikkine osasineen on massivinen kokonaisuus kaikkea mahdollista maan ja taivaan väliltä luoden pohjan sille, että laajempi yleisö voi hyödyntää kyseistä systemiä omiin tarkoituksiinsa joustavasti ja tilanteesta riippuen.

Miksi design system?

Tarviiko organisaatiomme design systemiä? Tätä kysymystä voi miettiä monelta eri kannalta ja tarpeellisuutta voi testata muutamalla lisäkysymyksellä.

1. Skaalaus
   • Onko yrityksessä tuote tai tuotteita, joissa on yhteensä yli 300 näyttöruutua?
2. Yhtenäisyys
   • Onko tavoitteena, että tuotteissa yhtenäinen brändi, look & feel ja käyttökokemus? ‘
   • Onko tuotteessa tai tuotteissa 20 erilaista painiketyyliä?
3. Tehokkuus
   • Halutaanko, että suunnittelijat ja front end -kehittäjät työskentelevät nopeammin säästäen aikaa?
4. Tiimityö
   • Onko projekteissa paljon työn eteenpäin luovuttamista suunnittelijoiden välillä
   • Onko projekteissa monta suunnittelijaa yhtä aikaa?

Design system todennäköisesti tuo arvoa organisaatiolle, mitä selkeämmin vastaus on myöntyvä yllä oleviin kysymyksiin. 

Maturiteetti

Design systemin maturiteettia voi tarkastella parin näkökulman läpi: organisaation tai tiimin kautta.

Organisaation näkökulmasta keskiössä ovat prosessit, dokumentointi ja se, onko suunnittelu otettu huomioon kaikilla mahdollisilla organisaation tasoilla.

Tiimilähtöinen maturiteettiajattelu taasen vertailee tiimissä olevien tekijöiden, luojien ja kuluttajien suhdetta:

• Luojat ovat niitä, jotka kehittävät design systemiin komponentteja
• Kuluttajat ovat niitä, jotka käyttävät näitä komponentteja omassa työssään, niin suunnittelussa kuin kehityksessä.
  

Omistajuus

Kuka vastaa design systemin kehittämisestä, ylläpidosta, käyttöönotosta ja hallinnasta? Kuka päivittää? Kuka hyväksyy? Kuka vastaa laadusta? Ilman selkeää omistajaa systeemi ei toimi ja pahimmillaan se voi jäädä komponenttien hautausmaaksi.

Omistajuutta on pääpiirteittäin kolmea erilaista: strategista, operatiivista ja kulttuurillista. Strategisessa omistajuudessa on kyse päätöksistä, niiden priorisoimisesta ja systemin suunnasta. Operatiivisella omistajuudella tarkoitetaan komponenttien kehittämistä ja ylläpitämistä. Kulttuurillinen omistajuus varmistaa, että design system leviää organisaatiossa mahdollisimman monen käyttöön, ja että sitä kehitetään yhdessä.

Organisaation rakenne kannattaa mallintaa suhteessa systeemiin. Tällöin eri sidosryhmät ymmärtävät oman roolinsa ja vaikutuksensa systeemiin selkeämmin. Mallintaminen tuo näkyväksi systeemin seuraajat, neuvonantajat, käyttäjät, luojat ja näiden kaikkien yhdistelmät. Usein tämä voi olla jonkinlainen kaavio, joka havainnollista roolit ja niiden suhteet itse systeemiin.

Suunnittelumallin elinkaari (pattern journey)

Suunnittelumallin elinkaari on design systemin keskeisimpiä osia. Se kuvaa suunnittelumallin (patternin) matkaa tarpeen tunnistamisesta käyttöönottoon ja ylläpitoon saakka.Elionkaari auttaa tiimejä valmistamaan käyttökelpoisempia palvelukokonaisuuksia yhtenäisten komponenttien ja mallien avulla.

Elinkaaressa on selkeät vaiheet:

1. Tarpeen tunnistaminen
   • On olemassa toistuva tarve, johon tarvitaan ratkaisu (painike, login ikkuna, jne.).
2. Tutkimus & ideointi
   • Selvitetään käyttötilanteet, esimerkiksi työpajojen avulla, kutsumalla kokoon eri tuotteista vastaavia henkilöitä organisaatiosta.
3. Suunnittelu & prototypointi
   • Malli suunnitellaan valmiiksi ja testataan ennen toteutusta.
4. Dokumentointi
   • Luodaan selkeät käyttöohjeet (saavutettavuus, rajoitukset ja esimerkit).
5. Toteutus
   • Malli toteutetaan komponenttikirjastoon.
6. Julkaisu & käyttöönotto
   • Malli tuodaan kaikkien käyttäjien saataville (kehittäjät, muut suunnittelijat).
7. Ylläpito
   • Kerätään palautetta ja kehitetään mallia edelleen.

Tämän rakenteen avulla varmistetaan, että jokainen suunnittelumalli kehittyy harkitusti, pysyy ajantasaisena ja tukee design systemin pitkäjänteistä käyttöä.

Jalkauttaminen

Design Systemin jalkauttamiseen ei ole mitään hopealuotia. Jalkauttaminen vaatii viestintää, sitouttamista ja arjen hyötyjen osoittamista. Kun design system julkaistaan organisaatiossa, alkaa tavoitteellinen viestintä uudesta systeemistä organisaation sisällä. Samalla käynnistyy muutos, joka vaatii uudistuksia niin ajattelu- ja työtavoissa kuin eritoten organisaatiokulttuurissa.

Jotta design system voidaan jalkauttaa menestyksekkäästi, vaaditaan monia erilaisia taitoja: myyntitaitoja, tarinankerrontaa, empatiaa, kuuntelua. Design systemin jalkauttajan rooli on siis moninainen. Välillä hän on evankelista, toisinaan tuotepäällikkö ja joskus jopa palvelumuotoilija. Jalkauttajan on löydettävä organisaation sisältä tiimi tai tiimejä, joiden kanssa voi viedä design systemin ilosanomaa eteenpäin. Näin syntyy tarinoita ja design system -tiimi saa arvokasta palautetta, jolla kehittää systeemin palasia entistä paremmaksi.

Loppujen lopuksi tärkeintä jalkauttamisessa on osoittaa design systemin arvo niin tiimeille kuin liiketoiminnalle. Design system on tuote sekä toimintamalli.

Kirjoitusta rikastaneet lähteet

• https://www.invisionapp.com/inside-design/guide-to-design-systems/
• https://www.forumone.com/ideas/what-is-design-system/
• https://varya.me/design-systems/pattern-journey/
• https://bradfrost.com/blog/post/a-design-system-governance-process/
• https://medium.com/slalom-build/a-maturity-model-for-design-systems-93fff522c3ba
• https://www.designsystems.com/the-spectrum-of-maturity-for-design-systems/

Mitä seuraavaksi?

Design system ei ole pelkkä projekti, vaan mahdollisuus rakentaa fiksummin. Jos kirjoitus herätti ajatuksia, ota yhteyttä meihin.