Slik integrerer man designsystemet med CMS
featureArticle.chapters
featureArticle.introduction
Lær hvordan du kan integrere designsystem med CMS, inkludert kompileringsprosess, integrasjonspunkter og front-end vs. back-end-gjengivelsen av UI-komponenter.
authorBox.aboutVegard Ottervig
Vegard Ottervig er innholdsansvarlig i Enonic, har en mastergrad i filmvitenskap og har jobbet med journalistikk og markedsføring siden 2010. Han elsker film, sykling, filosofi, spill og skriving.
Chapter 1
Viktige deler av et designsystem
Et designsystem samler de visuelle og funksjonelle elementene i organisasjonen din på ett sted. Med alt fra mønsterbiblioteker og stilguider under samme tak, kan du holde merkevaren og kommunikasjonen konsistent. Uansett hvor varierte dine digitale opplevelser er.
Formen på designsystemet ditt vil variere avhengig av dine digitale opplevelser, kommunikasjon og team, men det vil mest sannsynlig inkludere:
- Et Sketch-bibliotek
- Et mønsterbibliotek
- En stilguide
- Organisasjonsprinsipper
- Maler
- Beste praksis
- UI-komponenter levert som en kodebit (f.eks. HTML, CSS og andre front-end-rammeverk)
Chapter 2
Designsystemet er en del av din kompileringsprosess
Ulike designsystemer tilbyr forskjellige alternativer. Med noen må du importere all koden inn i prosjektet ditt, mens andre lar deg inkludere de delene du trenger. Det siste alternativet er best når det kommer til å skape et strømlinjeformet system som ikke er oppblåst med unødvendig kode.
Vi vil ikke gå inn på de små detaljene i denne guiden. Men populære verktøy å se etter når du fokuserer på front-end-utvikling inkluderer Webpack, LESS, Sass, Babel og Nodejs.
Chapter 3
Hvordan knytte CMS-et til designsystemet
Koblingen mellom et CMS og et designsystem er HTML. Dette betyr at for å koble CMS-et ditt til designsystemet ditt, må du tilpasse HTML i CMS-malen der det trengs.
I hvilke scenarioer trenger CMS-et å være fleksibelt? La oss gå gjennom noen eksempler.
- Designsystemet støtter flere kolonner og responsivitet. Hvordan kan dette tilpasses CMS-et?
- Designsystemet støtter valgfri bruk av marger. Hvordan kan dette konfigureres i CMS-et uten hardkoding?
- Designsystemet kan håndtere avansert interaksjon, f.eks. validering av skjemaer. Hvordan kan CMS-skjemabyggeren tilpasse seg dette uten å endre designsystemet?
- Server vs. klientrendering. Støtter CMS-et smidige overganger for en rask respons og rik brukeropplevelse på klientsiden?
Chapter 4
Integrasjonspunktene
Header, Footer, meny
Header, footer og meny utgjør skallet på nettstedet ditt og må integreres for å passe med designsystemet. Når disse er tilpasset CMS-et ditt, vil du kunne dynamisk bygge menyinnholdet og spesifikke deler av footer og header.
Layouter
Layouter brukes til å organisere strukturen på de forskjellige komponentdelene på en side. De er konfigurerbare, noe som betyr at du kan justere marger, bakgrunn, antall kolonner og fordeling (som 70/30).
Det er fint hvis CMS-et ditt støtter layouter. Hvis ikke, må du hardkode og lage flere sidemaler. Husk bare at hardkoding vil begrense fleksibiliteten for innholdsredaktører.
Sidemaler
CMS-et ditt kan være der du koder og administrerer sidemalene dine. I så fall vil du få enda mer fleksibilitet hvis CMS-et har dynamiske sidemaler som kan konfigureres av innholdsredaktører.
Og glem ikke at maler kan kombineres med layouter for å produsere ulike resultater uten å måtte kode.
Sidekomponenter
Sidekomponenter består av elementer og widgets, og kan settes inn i layouten eller sidemalene dine. Dette kan være nyttige funksjoner som en kalkulator, artikkelliste eller kalender.
Det er disse komponentene som går dypt inn i designsystemet, og kobler UI med funksjonalitet i form av knapper, animasjon eller interaktive elementer.
Det meste av integreringen av designsystemet ditt vil komme i form av disse sidekomponentene. Sidekomponentene kan være bygget med React eller andre front-end-rammeverk.
Skjemaer
For å få nettskjemaer til å fungere godt med designsystemet ditt, trenger du en fleksibel skjemabygger som tillater tilpasning av HTML-utdata.
I tillegg, for å sørge for at de passer med designsystemet, må selve komponenten kanskje tilpasses. Husk at feilhåndtering, skjemalayout og validering også er essensielt for skjemaet.
Chapter 5
Front-end-rammeverk og ytelse
Til slutt bør du vurdere alternativet mellom front-end- og back-end-gjengivelse i ditt designsystem. Populære front-end-rammeverk inkluderer React, Angular og Vue. Hvilket du bør velge avhenger av teknologien som brukes i ditt designsystem.
I dag leveres stadig mer av brukeropplevelsen i nettleseren, noe som ofte kan ha negativ innvirkning på ytelsen, spesielt ved første innlasting.
Du må bestemme om all funksjonalitet skal plasseres i front-end, eller om du bør velge en blanding der du leverer back-end-gjengitt markup og deretter overlater resten til front-end-rammeverket etter innlasting. Sistnevnte vil gi bedre responstid for brukerne.
Det er mulig å få til dette hvis ditt CMS støtter server-side-JavaScript. Da vil du kunne generere markup server-side, for eksempel med React, og sende dette til klienten for en smidig overlevering.
Vi nevner dette fordi å stole på ren front-end-levering vil påvirke ytelsen og indeksering av søkemotorer, noe som igjen vil påvirke SEO-scoring og tilgjengelighet.
Chapter 6
Bonus: 5 raske tips for å bygge designsystem fra Gjensidige
Gjensidige er et norsk forsikringsselskap som har bygget et dedikert designsystem for sine digitale kanaler.
Vi spurte digitalredaktør Torstein Aas-Hansen om å dele selskapets erfaringer og beste praksis for å bygge et designsystem.
Her er deres fem essensielle kjappe tips:
- Legg ned tid og innsats i arbeidet med designsystemet. Samarbeid på tvers av funksjoner og avdelinger.
- Finn inspirasjon fra andre, men lag et designsystem som passer for dere.
- Start beskjedent, med et designsystem som er enkelt å bygge og kan brukes av mange mennesker i ulike sammenhenger.
- Lag en veikart, som forteller dere hvor dere vil være om seks måneder og hva dere må gjøre for å komme dit.
- Sikre et tverrfaglig eierskap til designsystemet i hele design- og utviklermiljøet.