Frigivelse af designsystemer

Leverer sammenkoblede output til adopterere over tid

Nr. 1 af 6 i serien Releasing Design Systems:
Output | Kadens | Versioner | Breaking | Afhængigheder | Behandle

Virksomheder indser et design-systems værdi, når de vedtager produkter, bruger et system til at skabe og sende oplevelser, som deres kunder bruger. Som en del af denne værdikæde frigiver systemet funktioner over tid. Dette sætter systemet i hænderne på sine kunder: designere og ingeniører, der gør deres job.

Stærke systemhold tager udgivelser alvorligt. De ser ikke sig selv som at frigive blot en komponentbibliotekskode. I stedet leverer de mange flere output: designtokener, dokumentation, designaktiver og andre ressourcer.

Denne serie beskriver mange facetter af frigivelse af designsystemer. Det begynder med at definere et systems mange output, og hvor de leveres. Efterfølgende artikler dækker emner om kadence, versionering, ødelæggelse af ændringer, afhængigheder og en trin-for-trin-tilgang.

Disse historier afspejler, hvad jeg har lært frigivelsessystemer, der arbejder med teams som Discovery Education, Morningstar, Target og REI. De hæves af indsigt fra kolleger hos Salesforce, Adobe, Atlassian, Shopify og Financial Times. Tak for nådig deling af din tid og praksis!

Output: Hvad er der frigivet?

Design-systemprogrammer frigiver mange typer output, ikke kun kode. Som et resultat skal et system differentiere og kommunikere denne række versionerede output til udviklere, designere og andre kunder.

Kode, sandhedens kilde

De fleste systemer tilbyder en enkelt kilde til sandhed i præsentationslagskoden som:

  • UI-komponentbibliotek som HTML-markering og CSS. Ofte benævnt "CSS" hviler denne pakks forbrug på at bruge eller kompilere CSS som en konsistent basislinje i visuel stil kombineret med genbrug af HTML-kodestykker.

og / eller ...

  • UI Components Library som Javascript: Mange systemer indpakker HTML & CSS med JavaScript for at styrke logikken, indkapslet stil og lette integration og vedligeholdelse mere direkte inden for et valg af rammer. Mens de fleste biblioteker er målrettet mod en bestemt ramme (React, Vue, Ember, Angular, ...), antyder industrisignaler et skift til at skabe webkomponenter til alle rammer. Min sidste seks systemindsats? Senere 2017: Vanilla HTML, Vanilla HTML. Tidligt 2018: React, Vue. Senere 2018: Webkomponenter, Webkomponenter.

Derudover kan andre fremtrædende output frigives separat:

  • Designtokens, der skaber en visuel stil via semantisk meningsfulde egenskabsværdipar. Tokens er variabler, der er tilgængelige i mange formater til brug på tværs af platforme (web, iOS, Android), forbehandlere (Sass og LESS) og rammer (som React). Nogle systemer administrerer tokens i et depot, der er adskilt fra UI-komponentkoden. Som et resultat kan deres bibliotek - sammen med andre implementeringer - også afhænge af token som en pakke.
  • Demo Apps / Sites som et miljø med sideeksempler bygget ved hjælp af komponentbiblioteket. Demo'erne er også til tutorials og hurtig prototype, inklusive af designere!
  • Cross-platform komponenter, der er egnede til iOS, Android og Windows.

Designaktiver

De fleste hold begrænser forståelsen af, hvad de frigiver til enkel ”vi frigiver kode.” Det åbnes for dem at indse, at de udgiver så mange andre værktøjer, der ændrer sig over tid. De omfatter:

  • Design værktøjssæt som skabelonfiler og symbolbiblioteker, der tilbydes i designsoftware. I dag er næsten altid skitse. I morgen Figma, Invision Studio og andre nye konkurrenter?
  • Skrifttyper, ikoner og endda Origamis billedsæt på grund af et systems ofte forventede rolle i distribution og versionering af sådanne biblioteker.
  • Andre designressourcer som illustration og farveprøve ASE / CLR-filer som springbræt til skræddersyede kunstværker. Disse samlinger ændres langsomt, mindre formelt og via bidrag fra lokalsamfundsmedlemmer, der ikke er en del af et systemkerneteam. Men fra kundens perspektiv og systemets kommunikation er det en del af systemet.

Dokumentationssite

Designsystemer har brug for et hjem, et sted, som alle ved, at de kan finde en vej til alt, hvad der har det nyeste og største. Huset ligger ved en mindeværdig URL og er ofte bygget med brugergrænseflade-komponenter, der er specifikke for dets mission.

  • Dokumentationssider beskriver funktioner (som en knap), nye brugere ombord og udløser processer som at få hjælp eller bidrage. Hold bygger oftere websteder ved hjælp af en statisk stedgenerator eller sjældnere med et indholdsstyringssystem.
  • Dokumentationskomponenter - kodeeksempel-par, do-dont, hex-kode, komponent-udforsker - afhænger af UI-komponentbiblioteket og tjener normalt kun doc-webstedet. Sådanne komponenter kan versioneres med dokumentationsstedet eller som et tredje, separat versioneret bibliotek i forhold til doc og UI-komponenterne, de ligger mellem.

Destinationer: Hvor går den hen?

Når du distribuerer kode og designaktiver, er det vigtigt at tilbyde koden på måder, der bedst forbruges af dine adoptionsingeniører. Dette betyder, at nogle systemer skal tilbyde valg på tværs af mange muligheder, mens andre kan stole på et enkelt valg som organisatorisk standard.

For kode

  • BEDSTE: Registreringer som npmjs (eller et internt modstykke som Sonatypes nexus), der giver adgang til og styring af frigivne kodepakker. Udviklere bruger derefter værktøjer som bower, npm, garn, webpack og babel til at integrere og opgradere denne kode glat i deres miljøer.
  • BEDRE: Hostede aktiver på CDN'er til direkte links til versioneret stil og script samt skrifttyper og ikoner, der ændres langsommere.
  • BARE OK: Repository Adgang til Github, Bitbucket eller lignende til at klone, gaffel eller på anden måde kompilere, bruge og måske - til sidst - bidrage.
  • HVIS NØDVENDIGT: Direkte kodeoverførsler, normalt af "ZIP-filen" af kompilerede eller ukompilerede systemaktiver fra docwebstedet til lokal brug og / eller manuel integration i et separat arkiv.

Bootstrap og Material Design Lite er eksempler, der frigives til 2+ destinationer.

Til designværktøjssæt

  • BEDSTE: Opret nyt som en synkroniseret, indlejret sti i et designværktøjs menu for at oprette en ny instans fra en skabelon.
  • BEDRE: Versioneret og distribueret ved hjælp af tilladelsesbaseret designadministrationssoftware som Abstract eller Lingo.
  • GOOD: Download direkte værktøjssæt fra et dokumentationssite, med en klar version angivet og tilhørende Getting Started-dokument i nærheden.
  • BARE OK: Delt drev via veldokumenteret og muligvis forenklet intern URL (f.eks. Http: //system.uitoolkit).
  • IKKE GODT RETT: Begravet på en side på fjerde niveau på et knap organiseret wiki-sted, som mange mennesker ikke kan finde.

Næste → # 2. Cadence