Slipper designsystemer

Leverer sammenkoblede utganger til adoptere over tid

Nr. 1 av 6 i serien Releasing Design Systems:
Utgang | Kadens | Versjoner | Breaking | Avhengigheter | Prosess

Bedrifter innser verdien av et designsystem når de tar i bruk produkter bruker et system for å gjøre og sende erfaringer som kundene deres bruker. Som en del av den verdikjeden frigir systemet funksjoner over tid. Dette setter systemet i hendene på kundene: designere og ingeniører som gjør jobben sin.

Sterke systemteam tar utgivelser på alvor. De ser ikke på seg selv som å gi ut bare bibliotekkoden for komponenter. I stedet leverer de mange flere utganger: design tokens, dokumentasjon, design eiendeler og andre ressurser.

Denne serien beskriver mange fasetter av frigjøring av designsystemer. Det begynner med å definere systemets mange utganger og hvor de leveres. Etterfølgende artikler dekker emner om tråkkfrekvens, versjon, bryte endringer, avhengigheter og en trinnvis tilnærming.

Disse historiene gjenspeiler det jeg har lært om å gi ut systemer som jobber med team som Discovery Education, Morningstar, Target og REI. De er forhøyet av innsikt fra kolleger i Salesforce, Adobe, Atlassian, Shopify og Financial Times. Takk for at du nådig delte tiden din og praksis!

Utganger: Hva er utgitt?

Design systemer gir ut mange typer utganger, ikke bare kode. Som et resultat bør et system differensiere og kommunisere dette spekteret av versjonerte utganger til utviklere, designere og andre kunder.

Kode, sannhetens kilde

De fleste systemer tilbyr en enkelt kilde til sannhet i presentasjonslagskoden som:

  • UI-komponentbibliotek som HTML Markup & CSS. Ofte referert til som "CSS", er forbruket av denne pakken hviler på å bruke eller kompilere CSS som en konsistent grunnleggende visuell stil kombinert med gjenbruk av HTML-utdrag.

og / eller ...

  • UI Components Library som Javascript: Mange systemer pakker HTML og CSS med JavaScript for å forsterke logikken, innkapsle stilen og lette integrasjonen og vedlikeholdet mer direkte i en valgfri ramme. Mens de fleste biblioteker retter seg mot et spesifikt rammeverk (React, Vue, Ember, Angular, ...), tyder bransjesignaler på en overgang til å lage webkomponenter for alle rammer. Min seks siste systeminnsats? Senere 2017: Vanilla HTML, Vanilla HTML. Tidlig 2018: React, Vue. Senere 2018: Webkomponenter, Webkomponenter.

I tillegg kan andre fremtredende utganger frigjøres separat:

  • Design tokens som etablerer en visuell stil via semantisk betydningsfulle eiendomsverdipar. Tokens er variabler som er tilgjengelige i mange formater for bruk på tvers av plattformer (web, iOS, Android), forbehandlere (Sass og LESS) og rammer (som React). Noen systemer administrerer tokens i et depot som er atskilt fra UI-komponentkoden. Som et resultat kan biblioteket deres - sammen med andre implementeringer - avhenge av token som en pakke, også.
  • Demo-apper / nettsteder som et miljø med sideeksempler bygget på komponentbiblioteket. Demoene er også for tutorials og rask prototyping, inkludert av designere!
  • Kryssplattformkomponenter som passer for iOS, Android og Windows.

Design eiendeler

De fleste team begrenser forståelsen av hva de gir ut til enkle “vi slipper kode.” Det åpner øye for dem å innse at de publiserer så mange andre verktøy som endrer seg over tid. De inkluderer:

  • Design Toolkits som malfiler og symbolbiblioteker som tilbys i designprogramvare. I dag, nesten alltid Sketch. I morgen, Figma, Invision Studio og andre nye konkurrenter?
  • Skrifter, ikoner og til og med Origamis bildesett på grunn av systemets ofte forventede rolle i distribusjon og versjon av slike biblioteker.
  • Andre designressurser som illustrasjon og fargeprøver ASE / CLR-filer som et springbrett for skreddersydde kunstverk. Disse samlingene endres sakte, mindre formelt, og via bidrag fra samfunnsmedlemmer som ikke er en del av et systemkjerneteam. Likevel, fra kundens perspektiv og systemets kommunikasjon, er det en del av systemet.

Dokumentasjonsside

Designsystemer trenger et hjem, et sted alle vet at de kan finne en vei til alt som vil ha det siste og beste. Den ligger i en minneverdig URL, og er ofte bygget med brukergrensesnitt-komponenter som er spesifikke for dets oppdrag.

  • Dokumentasjonssider beskriver funksjoner (som en knapp), ombord nye brukere og utløser prosesser som å få hjelp eller bidra. Lag bygger oftere nettsteder ved hjelp av en statisk nettstedgenerator eller sjeldnere med et innholdsstyringssystem.
  • Dokumentasjonskomponenter - kodeeksempel-par, do-dont, hex-kode, komponentutforsker - er avhengig av UI-komponentbiblioteket og tjener vanligvis bare doc-nettstedet. Slike komponenter kan versjoneres med dokumentasjonsstedet eller som et tredje, separat versjonert bibliotek i forhold til dok og UI-komponentene de ligger mellom.

Reisemål: Hvor går den?

Når du distribuerer kode og design eiendeler, er det viktig å tilby koden på en måte som enklest kan konsumeres av dine adoptere ingeniører. Dette betyr at noen systemer må tilby valg på tvers av mange alternativer, mens andre kan stole på et enkelt valg som organisasjonsstandard.

For kode

  • BEST: Registreringer som npmjs (eller en intern motstykke som Sonatype's nexus) som gir tilgang til og administrasjon av utgitte kodepakker. Utviklere bruker deretter verktøy som bower, npm, garn, webpack og babel for å integrere og oppgradere den koden jevnt i miljøene.
  • BEDRE: Hostede eiendeler på CDN-er for direkte koblinger til versjonert stil og skript, så vel som skrifter og ikoner som endres saktere.
  • Bare OK: Tilgang til Github, Bitbucket eller lignende for å klone, gaffle eller på annen måte sammenstille, bruke og kanskje - til slutt - bidra.
  • HVIS NØDVENDIG: Nedlasting av direkte kode, vanligvis av "ZIP-filen" av kompilerte eller ikke-kompilerte systemeiendeler fra dokumentsiden for lokal bruk og / eller manuell integrasjon i et eget depot.

Bootstrap og Material Design Lite er eksempler som slipper til 2+ destinasjoner.

For designverktøysett

  • BEST: Lag ny som en synkronisert, innebygd bane i et designverktøy-meny for å opprette en ny forekomst fra en mal.
  • BEDRE: Versjonert og distribuert ved hjelp av tillatelsesbasert designadministrasjonsprogramvare som Abstract eller Lingo.
  • GODE: Direkte verktøysett nedlasting fra et dokumentasjonssted, med tydelig versjon indisert og tilhørende Komme i gang-dokument i nærheten.
  • BARE OK: Delt stasjon, via godt utlyst og muligens forenklet intern URL (for eksempel http: //system.uitoolkit).
  • IKKE GODT RETT: Gravlagt på en side på fjerde nivå på et knapt organisert wikiside mange ikke kan finne.

Neste → # 2. Cadence