Design system on pelkkä kuluerä, jos keskeinen periaate unohtuu

Näiden muutaman vinkin avulla tarkistat, onko organisaatiosi design system tuottava. 

Onko komponenttien rakenne oikeasti atominen – ja miksi sen pitäisi olla?

Atomisuus tarkoittaa sitä, että design systemiin sisällytetyt komponentit on purettu mahdollisimman pieniin osiin. Jo pelkästään Figman design-kirjastoa tarkastelemalla voit päätellä, millä tasolla komponenttiesi uudelleenkäytettävyys on. Kirjastotiedostosta selviää esimerkiksi, onko monimutkainen komponentti tehty ainoastaan yksittäistä toiminnallisuutta varten.

Jos komponenttia ei voi käyttää uudestaan missään toisessa projektissa tai toiminnallisuudessa, sen paikka ei todennäköisesti ole yhteisessä design-kirjastossa – eikä sitä kannata rakentaa design systemiin devatuksi komponentiksi.

Miten uudelleenkäytettävyyttä voi siis parantaa?

1. Mieti, miten komponentti pilkkoutuisi vielä pienemmiksi osiksi, eli atomeiksi, joille löytyy todennäköisemmin käyttöä myös muista projekteista.
2. Lisää atomitason Figma-komponentille tarvittavat propertyt ja variantit. Toisinaan atomien propertyt riittävät siihen, että saat muokattua molekyylitason komponentista tarpeeseesi soveltuvan rakennuspalikan, eikä molekyylitason varianteille ole tarvetta.

Tarkista, vaihtuuko komponentin variantissa ainoastaan sisältö

Välillä design-kirjastoissa näkee komponentteja, joiden ainoa ero on se, että niissä vaihtuu sisältö. Esimerkiksi kahdessa eri komponentissa on kahta erilaista tekstiä. Tämä on erittäin kohtalokasta komponentin monikäyttöisyydelle. 

Pelkkä tekstin vaihtuminen on tietenkin hyvin äärimmäinen esimerkki. Vastaavasta ongelmasta on kuitenkin kyse myös silloin, jos molekyyli- tai organismitason komponentti sisältää jonkin vaihtuvan elementin, joka käytännössä voisi olla saman atomin kaksi eri varianttia tai propertya.

Arvioi Figman variablejen uudelleenkäytettävyyttä

Onko design tokeniesi semanttinen taso oikeasti semanttinen? Myös semanttisissa design tokeneissa pyritään mahdollisimman laajaan monikäyttöisyyteen.

Jos call-to-actionin väreistä löytyy tokenit kaikille painikkeen tiloille (default, hover, active…), ollaan tokeneissa lipsuttu semanttisista tokeneista komponettitokeneihin. Tokenien määrää on tällöin lisätty turhaan ja monikäyttöisyyttä heikennetty urakalla. Semattisten tokenien nimeäminen voi olla vaikeaa, varsinkin jos design tokeneita ollaan määrittelemässä ensimmäistä kertaa.

Onko organisaatiollasi yhtenäinen tapa tehdä designia? Myös käytäntöjen tulee olla kunnossa

Ovatko valmiit designit jatkuvasti hukassa? Eikö design-tiedostosta tahdo löytyä oikeaa sivua? Kuinka paljon menee aikaa päivittäin, kun kehitystiimin jäsenet yrittävät raivaa tiensä läpi tiheän Figma-tiedostoviidakon etsiessään oikeaa designia? Uuteen projektiin on helppo hypätä mukaan, jos organisaatiossa on sovittu yhteiset käytännöt ja tiedostorakenteet. Kadonneen designin metsästys vähenee, jos käytännöt ovat yhtenäiset projektien välillä.

Kun design systemisi on kunnossa, uudet ominaisuudet ja palvelukokonaisuudet saadaan nopeammin loppukäyttäjien käsiin käyttämällä vähemmän resursseja. Älä anna systeemin myöskään rapistua, vaan seuraa komponenttien laatua systeemin kasvaessa.