# Elämä tissainjärjestelmän jälkee

_2019-10-18 · Pekka Hartikainen_

> Tissainjärjestelmien rakentamisest ja siihe tarvittavist vaiheist puhutaa paljo – mut mitä tapahtuu sen jälkee? Millast elämä on, ku tissainjärjestelm on tuotannos?

Tissainjärjestelm on viimein pystys ja kytketty tuotantoo. Mitäs sit? Onks eessä pelkkää myötätuulta? Katotaa, mitä uutta se tuop mukanaa ja mihi kaikkee se vaikuttaa.

## Tissainjärjestelmätiimi

Tissainjärjestelmän rakentamist varte oli varmaa projektitiimi… ja nyt sie huomaat, et **sen ylläpitoo tarvitaa kokonaa uus tiimi**. Ydintiimi voi olla alkuperäst projektitiimii vähä pienemp, mut sie tarviit sen kuitenki. Kyse on tietyst resursseist ja tissainjärjestelmän laajuuest, mut on hyvä nimetä virallisest ihmine, joka vastaa siit, ja varata sil työaikaa. Kehittäjän ja tissainerin pari on rooliin luonteva valinta.

DevOps kannattaa kans ottaa mukkaa, jot tissainjärjestelmän käyttö ja julkasemine ois mahollisimman helppoo.

> Sen ylläpitoo tarvitaa kokonaa uus tiimi.

Iso kysymys on tietysti, kui paljo resursseja tälle tiimil on sopivast. Ku tissainjärjestelm on vast julkastu, päivitystarpeit ei välttämät oo kiirreel – toisaalt ajan mittaa se vanhenee helpost, jos vastuut ei oo selvät ja siit vastaa vaa löysä virtuaaline tiimi.

## Tissainprosessi

Komponenttipohjasen tissainjärjestelmän yks tärkeimmist periaatteist on **poistaa pitkält tissainin ja kehityksen välisen kuilun tuoma tuska** ja tarjota helppo, johonmukaine ja nopia tapa toteuttaa pikselintarkkoi käyttäjäpolkui. Hyvin tehty tissainjärjestelm antaa kans vehkeet siihe, mite komponentit asettuut toisiisa nähe, elikkä välistykset ja gridin.

Pienis muutoksis tää voi pittää paikkasa. Staattist tissainii ei ees tarvita, vaa riittää kynäl ja paperil piirretty luonnos siit, mitä komponentteja käytetää ja missä. **Joskus tissainerin homma muuttuu viestijän rooliks ja käyttöliittymän ”leikepöytätissainien” toimittamiseks oikiaa aikaa.**

> Komponenttipohjasen tissainjärjestelmän yks tärkeimmist periaatteist on poistaa pitkält tissainin ja kehityksen välisen kuilun tuoma tuska.

Isommis ominaisuuksis mukan on enemmä sidosryhmii ja viestintää tarvitaa enemmä – kaikil sidosryhmil ei välttämät oo pääsyy niihi vehkeisii, joil käyttöliittymii tehhää. Siks staattisil tissainil on yhä tarvetta: niit on helppo jakaa, ja niist saa hyvän kokonaiskuvan siit, mitä on tekeil.

Onneks Figman kaltaset uuet vehkeet mahollistaat sekä tissainien komponentoinnin et niien jakamisen netis. Huono puoli on se, et ylläpiettävii kokonaisuuksii on kaks yhen sijaa: toine koodis ja toine Figmas. Tätäki kuiluu on yritetty kuroa umpee, mut sanomattaki on selvä, et se vaatii poikkeuksellist osaamist ja tiukast organisoitua otetta tissainjärjestelmää.

Kysymys kuuluu: millo käyttää custom-tissainii, jos käytös on tissainjärjestelm? Jotkut elementit, niinku bannerit, yrittäät luonnostaa häiritä ja kaapata huomion. Vaik suunnittelisit kui hyvän bannerin, seuraaval kertaa saatat tarvita jotai muuta.

**Joskus elementin pitää olla tavallist ”merkittävämp”.** Jos esimerkiks tärkee valinta tehhää tavallisel radiopainikkeel, se ei välttämät riitä kertomaa valinnan painoarvoo. Siks samaa asiaa tekevil kontrolleil voi tarvita erilaisii variaatioit (koko, kontrasti, kuvat). Nää variaatiot voi tietysti toteuttaa tissainjärjestelmää, mut se voi olla ylilyönti.

> Kysymys kuuluu: millo käyttää custom-tissainii, jos käytös on tissainjärjestelm?

Vuuen takane sie saatto ajatella eri laill ku nykyne sie. Jokasen tissainjärjestelmän perusperiaate on kuitenki johonmukasuus – jos nykyne tissain hoitaa hommasa hyvin, uuelleensuunnittelust ”ihan vaa huviks” tai viime viikol opitun innost on harvoi hyötyy. Tissainjärjestelm asettaa tissainereil riman suunnitella laadukkaast, johonmukasest ja kestäväst.

## Staattiset tissainit

Uutta ominaisuutta tai tuotetta ideoiess staattisil tissainil on yhä paikkasa. Niit on aika nopia tehä ja muokata, ku yksityiskohtien taso ei vielä kata kaikkii mahollisii käyttötapauksii. Ennen kaikkee niit on tosi helppo jakaa eri kanaviin. Staattisil tissainil mie tarkotan näkymii, jotka ei oo responsiivisii eikä niis oo eistynyttä interaktiivisuutta. Tissainerien osaamine ja vehkeet vaihtelee, mut useimmat tuntee nää vehkeet hyvin – nii et ne ei sulje tissainporukkaa ulkopuolel isommiskaa organisaatiois.

> Uutta ominaisuutta tai tuotetta ideoiess staattisil tissainil on yhä paikkasa.

Joku vois väittää, et ”staattisii tissainei ei tarvita enää, ku tissainjärjestelm on tuotannos”, mut se riippuu siit, mitä vehkeit ihmiset käyttää ja on valmiit käyttämää. Auttaa, jos product managerit voi antaa palautetta suoraa kirjottamal tekstei tai kommentoimal. Vaik tissainvehkeet on vielä kaukan täyellisest, helpost omaksuttavil vehkeil on tilausta eri sidosryhmien kesken.

**Huono puoli on tietysti tuplahomma** – ku tuote on julkastu ja sitä kehitetää, staattisten tissainien päivittämine vastaamaa tuotantoo on työläst. Ainoon tissainerin siin ei oo juur järkeekää. Mut jos joudut luovuttamaa tuotteen toisel tissaineril, jonka tausta ja osaamine on vähä erilaiset, staattiset tissainit voi auttaa häntä hyppäämää liikkuvaa junnaa.

Asiat ei yleensä oo mustavalkosii. Siks voi olla hyvä idea pitää tissainjärjestelmän rinnal joitai staattisii tissainei – **100 prosentin kattavuus voi olla liia työläs ja jäykistää asioit liikaa**, ja kaikist staattisist tissainest luopumine voi haitata viestintää.

## Vanhentuneet komponentit

Ku tissainjärjestelm on ollu käytös jonkin aikaa, sie huomaat, et osa komponenteist on… vanhanaikasii. Tai niit ei enää käytetä. Ennen ku hylkäät ne, siun pitää pystyy jäljittämää niien käyttökohteet. **Se voi kuulostaa helpolt**, mut riippuen siit, kui iso siun sovellus on tai kattaaks se useemman sovelluksen, se voi olla yllättävän työläs. Ku käyttökohteet löytyy, saatat haluta suunnitella ne näkymät uuestaa kokonaa.

Elementin poistamine käytöst ei luonnostaa oo yleensä kaikkei tärkein tai kiireisin asia, joten eessä on valinta:

1. suunnittele komponentti uuestaa
2. ”tapa komponentti helläst” uhkailul ja deprecated-merkinnäl
3. tapa se suoraa *(ja kato, ku sovellus ehkä palaa)*

Ku hyvät tavat kunniaa eikä sovellusta saa rikkoo, kolmone jää pois. Kakkosen voi tehä helpost, mut se on vaa dokumentaation muuttamist. Ykköne jää ainoaks vaihtoehoks… mut se vie eniten aikaa. Eikä se välttämät mahu viikon prioriteettilistal. Sen voi aina poistaa käytöst ens viikol.

**Tissainjärjestelmien maailmas saatat huomata suunnittelevas komponenttii uuestaa jo ennen ku tissainjärjestelm on otettu käyttöö sovelluksen kaikis osis.** Se tarkottaa vaa, et tissainjärjestelm on vehje, ei ratkasu. Vehkeit käyttää useemp tissainer, ja jokasel on omat mieltymyksesä siit, mil komponenteil ongelma ratkastaa.

## Dokumentaatio ja koulutus

Dokumentaation avul tissainjärjestelm saahaa hyöynnettyy koko organisaatios. Se ei ehkä oo projektin seksikkäin osa, mut sen tekemätt jättämine kostautuu myöhemmi. Onneks dokumentointii on nykyää tarjol tosi hyvii vehkeit.

> Dokumentaation avul tissainjärjestelm saahaa hyöynnettyy koko organisaatios.

**Tissainjärjestelmää käyttää ehkä eniten ydintiimi, mut moni kehittäjä käyttää sitä silloi tällöi.** Kehittäjä, joka kysyy tissainii liittyvii kysymyksii omast aloitteestaa, on harvinaine laji, joten kaikil taloo tulevil uusil kehittäjil kannattaa järjestää tissainjärjestelmäkoulutus. Sama pätee product managereihi ja vastaavis rooleis oleviin.

Se on kans mainio tapa tehä omast hommast läpinäkyvämpää koko organisaatiol.

## Versionhallinta ja julkasemine

Jos sie teet hommii tissainjärjestelmien parissa ja siun organisaatios on DevOps, juttele niien kaa siit, mite tissainjärjestelmäst saahaa kehittäjil mahollisimman houkutteleva ja mite **muutoslokin läpinäkyvyyttä voiaa lisätä kaikil sidosryhmil**.

Tissainjärjestelmän versiointi, julkasemisen helppous ja muutosten seuranta on ratkasevii, jot tissainjärjestelm saa suosioo kehittäjien keskuuessa. Lisäks sie haluut pystyy vastaamaa kysymyksee ”millo muutokset näkyy tai näky tuottees ja kuka ne vei sinne”.

## Refaktorointi

Frontend-kehityksen maailmas kaik voi muuttuu kahes vuuves. Bisneksen maailmas koko sovelluksen uuelleenkirjottamine kahen vuuen välein ei välttämät tuota eniten arvoo. Näiden kahen tosiasian kaa moni firma elää joka päivä. Uus startup käyttää aina uusimpii ja kehittäjäystävällisimpii teknologioit, mut jos se menestyy, se kasvaa ja joutuu jossai vaihees päivittämää teknologiapinosa.

Tissainereil se voi tarkottaa, et tissainjärjestelm ei oo käytös organisaation kaikil alueil tai kaikis sovelluksis. Se voi kans johtuu liia pienest tissainjärjestelmätiimist tai jostai muust resursointipäätöksest. Toisaalt aina tuntuu löytyvän organisaatio, joka on onnistunt siin. **Taustal voi olla tissainin arvostus, firmakulttuuri, nopeus tai mitä vaa silt väliltä.**

> Frontend-kehityksen maailmas kaik voi muuttuu kahes vuuves.

Varmaa on se, et jos siun UX-tiimi pystyy osallistumaa suoraa tuotteen koodipohjaa, sie saat kehittäjilt enemmä arvostusta ja vaikutusvaltaa. UX-tiimi ei ehkä kirjota koko sovellusta uuestaa, mut osallistumine joihinki osiin voi helpottaa siun tiimin äänen kuulumist kehittäjien keskuuessa – ja se voi kans inspiroija heit.

Vaik sovelluksen refaktorointi ei tuo välitöntä arvoo, se voi parantaa kokonais-UX:ää sekä tissainerien ja kehittäjien kokemust ja lopult nopeuttaa innovaatioit ja kehityssyklei. Mut jos sie oot startup, varmista tietysti ensin, et product-market fit on kunnos.

## Asenne: ole johonmukane, säilytä luovuus

Tissainjärjestelmät on olemas tuomas selkeyttä ja vauhtii tissainii ja kehitykseen. On kans tärkeetä säilyttää luovuus eikä ottaa tissainjärjestelmää uskontona. Tissainjärjestelmää voi aina muuttaa tai käyttää custom-tissainii, jos se palvelee tarkotusta.

Ole johonmukane, säilytä luovuus.

https://pekkahartikainen.fi/krl/blog/life-after-design-systems