Elämä design systemin jälkeen

Design system on vihdoin pystyssä ja kytketty tuotantoon. Mitä sitten? Onko edessä pelkkää myötätuulta? Katsotaan, mitä uutta se tuo mukanaan ja mihin kaikkeen se vaikuttaa.

Design system -tiimi

Design systemin rakentamista varten oli todennäköisesti projektitiimi… ja nyt huomaat, että sen ylläpitoon tarvitaan kokonaan uusi tiimi. Ydintiimi voi olla alkuperäistä projektitiimiä hieman pienempi, mutta tarvitset sen joka tapauksessa. Kyse on tietysti resursseista ja design systemin laajuudesta, mutta on hyvä nimetä virallisesti henkilö, joka vastaa siitä, ja varata sille työaikaa. Kehittäjän ja designerin pari on rooliin luonteva valinta.

DevOps kannattaa myös ottaa mukaan, jotta design systemin käyttö ja julkaiseminen olisi mahdollisimman helppoa.

Sen ylläpitoon tarvitaan kokonaan uusi tiimi.

Iso kysymys on tietenkin, kuinka paljon resursseja tälle tiimille on sopivasti. Kun design system on vasta julkaistu, päivitystarpeita ei välttämättä ole kiireellisesti – toisaalta ajan myötä se vanhenee helposti, jos vastuut eivät ole selvät ja siitä vastaa vain löyhä virtuaalinen tiimi.

Designprosessi

Komponenttipohjaisen design systemin yksi keskeisistä periaatteista on poistaa pitkälti designin ja kehityksen välisen kuilun aiheuttama tuska ja tarjota helppo, johdonmukainen ja nopea tapa toteuttaa pikselintarkkoja käyttäjäpolkuja. Hyvin tehty design system antaa myös työkalut siihen, miten komponentit asettuvat suhteessa toisiinsa, eli välistykset ja gridin.

Pienissä muutoksissa tämä voi pitää paikkansa. Staattista designia ei edes tarvita, vaan riittää kynällä ja paperilla piirretty luonnos siitä, mitä komponentteja käytetään ja missä. Joskus designerin työ muuttuu viestijän rooliksi ja käyttöliittymän ”leikepöytädesignien” toimittamiseksi oikeaan aikaan.

Komponenttipohjaisen design systemin yksi keskeisistä periaatteista on poistaa pitkälti designin ja kehityksen välisen kuilun aiheuttama tuska.

Isommissa ominaisuuksissa mukana on enemmän sidosryhmiä ja viestintää tarvitaan enemmän – kaikilla sidosryhmillä ei välttämättä ole pääsyä käyttöliittymien tekemiseen käytettäviin työkaluihin. Siksi staattisille designeille on edelleen tarvetta: niitä on helppo jakaa, ja niistä saa hyvän kokonaiskuvan siitä, mitä on tekeillä.

Onneksi Figman kaltaiset uudet työkalut mahdollistavat sekä designien komponentoinnin että niiden jakamisen verkossa. Huono puoli on se, että ylläpidettäviä kokonaisuuksia on kaksi yhden sijaan: toinen koodissa ja toinen Figmassa. Tätäkin kuilua on yritetty kuroa umpeen, mutta sanomattakin on selvää, että se vaatii poikkeuksellista osaamista ja tiukasti organisoitua otetta design systemiin.

Kysymys kuuluu: milloin käyttää custom-designia, jos käytössä on design system? Jotkin elementit, kuten bannerit, pyrkivät luonteeltaan häiritsemään ja kaappaamaan huomion. Vaikka suunnittelisit kuinka hyvän bannerin, seuraavalla kerralla saatat tarvita jotain muuta.

Joskus elementin pitää olla tavallista ”merkittävämpi”. Jos esimerkiksi tärkeä valinta tehdään tavallisella radiopainikkeella, se ei välttämättä riitä viestimään valinnan painoarvoa. Siksi samaa asiaa tekeville kontrolleille voi tarvita erilaisia variaatioita (koko, kontrasti, kuvat). Nämä variaatiot voi tietysti toteuttaa design systemiin, mutta se voi olla ylilyönti.

Kysymys kuuluu: milloin käyttää custom-designia, jos käytössä on design system?

Vuoden takainen sinä saattoi ajatella eri tavalla kuin nykyinen sinä. Jokaisen design systemin perusperiaate on kuitenkin johdonmukaisuus – jos nykyinen design hoitaa tehtävänsä hyvin, uudelleensuunnittelusta ”ihan vain huvikseen” tai viime viikolla opitun innoittamana on harvoin hyötyä. Design system asettaa designereille riman suunnitella laadukkaasti, johdonmukaisesti ja kestävästi.

Staattiset designit

Uutta ominaisuutta tai tuotetta ideoitaessa staattisilla designeilla on yhä paikkansa. Niitä on melko nopea tehdä ja muokata, kun yksityiskohtien taso ei vielä kata kaikkia mahdollisia käyttötapauksia. Ennen kaikkea niitä on hyvin helppo jakaa eri kanaviin. Staattisilla designeilla tarkoitan näkymiä, jotka eivät ole responsiivisia eivätkä sisällä edistynyttä interaktiivisuutta. Designerien osaaminen ja työkalut vaihtelevat, mutta useimmat tuntevat nämä työkalut hyvin – joten ne eivät sulje designihmisiä ulkopuolelle isommissakaan organisaatioissa.

Uutta ominaisuutta tai tuotetta ideoitaessa staattisilla designeilla on yhä paikkansa.

Joku voisi väittää, että ”staattisia designeja ei tarvita enää, kun design system on tuotannossa”, mutta se riippuu siitä, mitä työkaluja ihmiset käyttävät ja ovat valmiita käyttämään. Auttaa, jos product managerit voivat antaa palautetta suoraan kirjoittamalla tekstejä tai kommentoimalla. Vaikka designtyökalut ovat vielä kaukana täydellisestä, helposti omaksuttaville työkaluille on tilausta eri sidosryhmien keskuudessa.

Huono puoli on tietysti tuplatyö – kun tuote on julkaistu ja sitä kehitetään, staattisten designien päivittäminen vastaamaan tuotantoa on työlästä. Ainoana designerina siinä ei ole juuri järkeäkään. Mutta jos joudut luovuttamaan tuotteen toiselle designerille, jonka tausta ja osaaminen ovat hieman erilaiset, staattiset designit voivat auttaa häntä hyppäämään liikkuvaan junaan.

Asiat eivät yleensä ole mustavalkoisia. Siksi voi olla hyvä idea pitää design systemin rinnalla joitain staattisia designeja – 100 prosentin kattavuus voi olla liian työlästä ja jäykistää asioita liikaa, ja kaikista staattisista designeista luopuminen voi haitata viestintää.

Vanhentuneet komponentit

Kun design system on ollut käytössä jonkin aikaa, huomaat, että osa komponenteista on… vanhanaikaisia. Tai niitä ei enää käytetä. Ennen kuin hylkäät ne, sinun pitää pystyä jäljittämään niiden käyttökohteet. Se voi kuulostaa helpolta, mutta riippuen siitä, kuinka iso sovelluksesi on tai kattaako se useita sovelluksia, se voi olla yllättävän työlästä. Kun käyttökohteet löytyvät, saatat haluta suunnitella ne näkymät uudelleen kokonaan.

Elementin poistaminen käytöstä ei luonteeltaan ole yleensä kaikkein tärkein tai kiireellisin asia, joten edessä on valinta:

1. suunnittele komponentti uudelleen
2. ”tapa komponentti hellästi” uhkailulla ja deprecated-merkinnällä
3. tapa se suoralta kädeltä (ja katso, kun sovellus mahdollisesti palaa)

Koska hyvät tavat kunniaan eikä sovellusta saa rikkoa, kolmonen jää pois. Kakkosen voi tehdä helposti, mutta se on vain dokumentaation muuttamista. Ykkönen jää ainoaksi vaihtoehdoksi… mutta se vie eniten aikaa. Eikä se välttämättä mahdu viikon prioriteettilistalle. Sen voi aina poistaa käytöstä ensi viikolla.

Design systemien maailmassa saatat huomata suunnittelevasi komponenttia uudelleen jo ennen kuin design system on otettu käyttöön sovelluksen kaikissa osissa. Se tarkoittaa vain, että design system on työkalu, ei ratkaisu. Työkaluja käyttää useampi designer, ja jokaisella on omat mieltymyksensä siitä, millä komponenteilla ongelma ratkaistaan.

Dokumentaatio ja koulutus

Dokumentaation avulla design system saadaan hyödynnettyä koko organisaatiossa. Se ei ehkä ole projektin seksikkäin osa, mutta sen tekemättä jättäminen kostautuu myöhemmin. Onneksi dokumentointiin on nykyään tarjolla todella hyviä työkaluja.

Dokumentaation avulla design system saadaan hyödynnettyä koko organisaatiossa.

Design systemiä käyttää ehkä eniten ydintiimi, mutta moni kehittäjä käyttää sitä satunnaisesti. Kehittäjä, joka kysyy designiin liittyviä kysymyksiä oma-aloitteisesti, on harvinainen laji, joten kaikille taloon tuleville uusille kehittäjille kannattaa järjestää design system -koulutus. Sama pätee product managereihin ja vastaavissa rooleissa toimiviin.

Se on myös erinomainen tapa tehdä omasta työstä läpinäkyvämpää koko organisaatiolle.

Versionhallinta ja julkaiseminen

Jos työskentelet design systemien parissa ja organisaatiossasi on DevOps, juttele heidän kanssaan siitä, miten design systemistä saadaan kehittäjille mahdollisimman houkutteleva ja miten muutoslokin läpinäkyvyyttä voidaan lisätä kaikille sidosryhmille.

Design systemin versiointi, julkaisemisen helppous ja muutosten seuranta ovat ratkaisevia, jotta design system saavuttaa suosiota kehittäjien keskuudessa. Lisäksi haluat pystyä vastaamaan kysymykseen ”milloin muutokset näkyvät tai näkyivät tuotteessa ja kuka ne vei sinne”.

Refaktorointi

Frontend-kehityksen maailmassa kaikki voi muuttua kahdessa vuodessa. Bisneksen maailmassa koko sovelluksen uudelleenkirjoittaminen kahden vuoden välein ei välttämättä tuota eniten arvoa. Näiden kahden tosiasian kanssa moni yritys elää joka päivä. Uusi startup käyttää aina uusimpia ja kehittäjäystävällisimpiä teknologioita, mutta menestyessään se kasvaa ja joutuu jossain vaiheessa päivittämään teknologiapinonsa.

Designereille se voi tarkoittaa, että design system ei ole käytössä organisaation kaikilla alueilla tai kaikissa sovelluksissa. Se voi myös johtua liian pienestä design system -tiimistä tai jostain muusta resursointipäätöksestä. Toisaalta aina tuntuu löytyvän organisaatio, joka on onnistunut siinä. Taustalla voi olla designin arvostus, yrityskulttuuri, nopeus tai mitä tahansa siltä väliltä.

Frontend-kehityksen maailmassa kaikki voi muuttua kahdessa vuodessa.

Varmaa on se, että jos UX-tiimisi pystyy osallistumaan suoraan tuotteen koodipohjaan, saat kehittäjiltä enemmän arvostusta ja vaikutusvaltaa. UX-tiimi ei ehkä kirjoita koko sovellusta uudelleen, mutta osallistuminen joihinkin osiin voi helpottaa tiimisi äänen kuulumista kehittäjien keskuudessa – ja se voi myös inspiroida heitä.

Vaikka sovelluksen refaktorointi ei tuota välitöntä arvoa, se voi parantaa kokonais-UX:ää sekä designerien ja kehittäjien kokemusta ja lopulta nopeuttaa innovaatioita ja kehityssyklejä. Mutta jos olet startup, varmista tietysti ensin, että product-market fit on kunnossa.

Asenne: ole johdonmukainen, säilytä luovuus

Design systemit ovat olemassa tuomaan selkeyttä ja vauhtia designiin ja kehitykseen. On myös tärkeää säilyttää luovuus eikä ottaa design systemiä uskontona. Design systemiä voi aina muuttaa tai käyttää custom-designia, jos se palvelee tarkoitusta.

Ole johdonmukainen, säilytä luovuus.