HTML suunnittelujärjestelmissä

Komponentit sisältävät parhaat käytännöt: jokainen Button käyttää <button>-elementtiä (ei div-elementtiä) oikean type-attribuutin kanssa. Jokainen Modal hallitsee fokusta, tukee Escape-näppäintä ja käyttää oikeita ARIA-rooleja. Komponenttien käyttöönotto estää saavutettavuuden toteuttamisen uudelleen jokaisessa tuotteen ominaisuudessa.

Storybook renderöi jokaisen komponentin erillään erilaisten propsien ja varianttien kanssa. Suunnittelijat ja PM:t näkevät käytettävissä olevat komponentit lukematta koodia, ja kehittäjät näkevät käyttöesimerkit etsimättä niitä lähdekoodista. Se on käytännössä suunnittelujärjestelmien dokumentoinnin de facto -standardi.

Käsittele suunnittelujärjestelmää semver-versiona julkaistavana pakettina. HTML:n tai CSS:n rikkovat muutokset, kuten käyttäjien tarvitsemien CSS-luokkien nimeäminen uudelleen tai komponentin slotin poistaminen, kasvattavat major-versiota. Paketin käyttäjät päivittävät version tietoisesti oman aikataulunsa mukaan eivätkä yllätyspäivityksenä.

Komponenttien propsit, slotit ja julkiset osat muodostavat julkisen API:n. Kun ne on julkaistu käyttäjille, niiden muuttamista on pidettävä kalliina toimenpiteenä. Poista vanha API käytöstä asteittain: lisää uusi API vanhan rinnalle, kirjaa vanhan käytön yhteydessä varoituksia ja poista se vasta harkitun siirtymäajan jälkeen.

Tokenit mahdollistavat teemoituksen: vaihda värien token-kartta, niin jokainen komponentti ottaa käyttöön uuden paletin. White-labelointi, jossa eri brändit jakavat komponentit mutta käyttävät erilaista visuaalista ilmettä, on helppoa, kun tokenit ohjaavat kaikkea ja komponentit viittaavat tokeneihin kovakoodattujen arvojen sijaan.

Kun organisaatio käyttää useita kehyksiä (React, Vue, Angular), web components -komponentit tarjoavat yhden toteutuksen, joka toimii kaikkialla. Toteutuksen voi rakentaa Litillä, FASTilla tai vanillana ja sitä voi käyttää samalla tavalla missä tahansa kehyksessä. HTML-rakenne on sopimus, ei käytetty kehys.

Suunnittelujärjestelmät rakentavat saavutettavuuden kerran jokaiseen komponenttiin: näppäimistökäsittelyn, ARIA-roolit, fokuksen hallinnan ja värikontrastin. Järjestelmän käyttöön ottavat tuotejoukkueet saavat saavutettavuuden valmiina sen sijaan, että rakentaisivat jokaisen ominaisuuden alusta asti. Tämä vähentää saavutettavuusvirheitä mitattavasti koko yrityksessä.

Seuratkaa, mitkä tuotteet käyttävät mitäkin suunnittelujärjestelmän versiota. Backstagen komponenttiluettelo, package.json-tiedostoa seuraavat mukautetut Slack-botit ja yksinkertaiset sisäiset hallintapaneelit paljastavat, missä uusin versio ei ole vielä käytössä. Käyttöönoton mittarit auttavat perustelemaan jatkuvat investoinnit.

Päättäkää, kuka saa lisätä komponentteja: ainoastaan keskitetty suunnittelujärjestelmätiimi vai tuotetiimien hajautetut osallistujat? Kummallakin mallilla on etunsa ja haittansa. Keskitetyt tiimit julkaisevat hitaammin mutta ylläpitävät laatua, kun taas hajautetut tiimit etenevät nopeasti mutta voivat aiheuttaa pirstaloitumista. Valitkaa malli tietoisesti organisaation mittakaavan perusteella.

Suunnittelujärjestelmät ovat eläviä tuotteita. Lisää komponentteja, kun tuotteissa ilmenee uusia patterneja, poista käytöstä komponentit, jotka eivät enää sovi kokonaisuuteen, ja refaktoroi, kun perustavanlaatuisia päätöksiä on muutettava. Käsittele järjestelmää ohjelmistona, jolla on etenemissuunnitelma, ei valmiina artefaktina.

Suunnittelujärjestelmät kokoavat tokenit (atomiset arvot), komponentit (uudelleenkäytettävät HTML-yksiköt) ja patternit (korkeamman tason kokonaisuudet) versioiduksi kirjastoksi, jota jaetaan tuotteiden kesken. Käytä dokumentointiin Storybookia, kehysten väliseen käyttöön web components -komponentteja ja vakauden hallintaan semveriä. Rakenna saavutettavuus jokaiseen komponenttiin, seuraa käyttöönottoa ja kehitä järjestelmää elävänä tuotteena.