Tokens i designsystemer

10 tip til arkitekt og implementering af designbeslutninger for alle

I en nylig gennemgang af koden omrørte mine lidenskaber, da jeg gik gennem en pillekomponents stil med en designer-teamkammerat.

Jeg kunne næppe indeholde min spænding:

"Se. Ja, det er kode, men se nøje på disse symboler. Ved du hvordan det ser ud? Som specs! Og hvad så? Jeg kan læse dette, ligesom du kan. Og vi kan tråde disse overalt: doc, design og konvos også. Overalt!"

Min holdkammerats reaktion antydede nysgerrighed, selvom den ikke stemte overens med mit udbruds følelsesmæssige træk. Han er ikke et systems geek som mig. Ikke endnu, i det mindste. Men han fik det, der betyder noget: der er en synlig vej til beslutninger, vi træffer, hvor de implementeres.

Vi har brugt så meget arbejde på at få design ud af vores variabler - de mest atomare af genanvendelige kodebits - jeg følte mig øjeblikkelig tiltrukket af ideen om at sætte design tilbage i.

Det er sådan, vi udviklede, arkiverede og implementerede tokens gennem design, kode og samarbejde.

Fra variabler til tokens

Hvert designsystem tilbyder muligheder. For eksempel kan farver skaleres fra sort gennem neutrale til hvide. Hver neutral - identificeret via en HEX-kode som nr. 2B303B - kan gemmes og gøres tilgængelig i en variabel $ farve-neutral-20 til brug i en forarbejder som Sass.

Variabler tager mysteriet ud af uklare værdier. Men de overbryder ikke kløften mellem navngivning og brug. De svarer ”Hvilke muligheder har jeg?” Og lader dog ”Hvilket valg gør jeg?” Uklar.

Indstillingerne er ikke gode nok.

Designafgørelser, en mulighed, der anvendes på en kontekst

Et systems styrke kommer fra at vide, hvordan man anvender indstillinger (som $ farve-neutral-20) til sammenhænge (som en konventionel mørk baggrundsfarve). Dette begrunder muligheden som en beslutning.

Det er beslutninger, jeg kan bruge med tillid!

Imidlertid er sådanne beslutninger normalt stadig begravet i en fil i en vis repo, der bruges af udviklere, der arbejder på det webbaserede produkt, de ejer. Hvad med designere? Andre webprodukter? På tværs af andre platforme som iOS og Android? Vi har kodet beslutninger beregnet til alle, men de ejede i et fangehul i en repo, som ingen andre kan finde.

Designtokens, beslutninger, der er propageret gennem et system

Salesforce UX giver et glimt. Deres ideer betager mig, mest af alt deres Living Style Guide-koncept, der anvender Design Tokens på tværs af produkter ved hjælp af deres open source Theo-værktøj.

Her er indstillinger og beslutninger ikke begravet i Sass-filer. I stedet er de centraliseret og udbredt som symboler til ethvert produkt, designer eller udvikler, der indfører systemet, i brugervenlige, forudsigelige formater.

Hundredvis af tokens kan blive læsbare, forsætlige og sporbare beslutninger, der er vævet ind i en porteføljes eller virksomheds produkter.

Ser beslutningerne som et stort spec-ark? Jeg kan. Designere kan også. Med sådan synlighed og værktøj anerkender de virkningen af ​​deres beslutninger. Før besluttede vi os for $ farveneutral-80 til en grænse eller baggrund med en smule finurlig. Nu anvender vi $ border-hairline eller en $ baggrund-farvelys på en tankevækkende, konventionel måde.

Designere begynder at samarbejde. De træffer beslutninger med mere overvejelse og selvtillid, organiserede deres tanker i en struktur, de deler. Udviklere følger efter.

Dette kan omdanne omhyggelige aktiviteter som redlines og pixelmåling til samarbejde, der er rig med token talk. På tværs af vores arbejde - kritik af designkoncepter, skrivning af acceptkriterier, gennemgang af pull-anmodninger - er arkitekturen og implementeringen af ​​tokens altid til stede.

Arkitekterende tokens

En vellykket, vedvarende token-arkitektur afhænger af ligetil gruppering, rækkefølge, klassificering og beslutningstagning.

# 1. Vis indstillinger først, derefter beslutninger derefter

Du kan ikke tage beslutninger uden muligheder. Tokens er et effektivt instrument til at illustrere stien fra den ene til den anden.

I vores token-filer begynder vi med indstillinger som tilgængelige farver. Derefter anvender vi indstillinger i sammenhænge som 'tekstfarve' og 'baggrundsfarve'.

Takeaway: Organiser dine beslutninger for at foreslå deres atomiske grundlag: bygning fra muligheder til beslutninger og enkel til kompleks.

# 2. Start med farve & skrifttype, og stop ikke der!

Jeg taler ofte om et designsprogs store tre: farve, typografi og ikonografi. Så det er ingen overraskelse, at vores token-fil begynder med farve- og typeindstillinger og beslutninger (ikoner automatiseres andetsteds). Imidlertid er den visuelle stil sammensat af så meget mere, og det kunne også være tegn.

Mens vi begynder med at anvende farve på baggrund og tekst, udvides vi til mange andre typer beslutninger, herunder ting som:

Takeaway: Start med, men bliv ikke fast med bare farve og type. Udvid dine beslutninger til at dække de utallige bekymringer ved et designsprog.

# 3. Variable muligheder på tværs af meningsfulde skalaer

Mange tokeniserede koncepter inkluderer skalaer at vælge imellem, såsom størrelse på t-shirt (XS, S, M, L, XL, XXL), fremskridt (som en geometrisk 2, 4, 8, 16, 32, 64) eller brugerdefineret terminologi (som kompakt, hyggelig og behagelig). Skalaer kan også starte med et par muligheder (kun S & M) og vokse til at omfatte mere som berettiget.

Skalaer giver mulighed for at forgrene et tokenhierarki til lignende, men tydelige varianter, såsom berigende pladsindsat (fra XS til XL) til varianter af plads-inset-squish og space-inset-stretch (som begge også tilbyder XS til XL).

Enighed om en skaleringsmodel - t-shirts eller fremskridt, du bestemmer! - for områder som disse er en teamspecifik indsats. Endnu hårdere skal du undgå, at hærdede skalaer ikke er modstandsdygtige for at indsætte et trin imellem senere.

Takeaway: Vedtage og markere skalaer og demonstrere, hvordan de anvendes på tværs af forskellige scenarier.

# 4. Inviter bidrag, men sammenlæg samlingen

Hvornår garanterer et valg at blive et symbol? En enkelt brug: nej, ikke nok. Et sekund mangler muligvis overbevisning. Men tre? Hvis det dukker op så meget, er det normalt værd at fortælle. Undtagelser findes, men kriterierne "Brugt 3 gange?" Diskuterer.

Så hvem er symbolsk portvagt? Ingen, hvis vi anvender sunde processer til design og dev-gennemgang. Hvem som helst kan foreslå tegn, overflader på kandidater i et koncept eller trække anmodninger. Vores Slack-kanal har også meget token talk.

Ikke desto mindre tjener jeg som token-kurator og scanner arbejde med øje for token-kandidater. Jeg kan skumme en anmodnings markering og springe JavaScript over. Imidlertid scanner jeg grundigt stil- og tokenfiler for at finesse navne, omklassificere ærlige nominerede og udfordrer overdreven udvidelse. Alle har en symbolsk stemme. Men ikke alle bekymrer sig nok eller har tid til at holde symboler rene.

Takeaway: Lav tokens til et teambestræbelse, og (selv om det implicit) udpeger et struktureret arkitektonisk sind for at kuratere samlingen.

# 5. Graduate-beslutninger fra komponenter til tokens

Det er en distraktion at aflede hjernekræft til konstant at tænke symboler, symboler, symboler. ”Bør dette være et nyt token? Er det et tegn? Bruger jeg ikke et token? Åh nej! ”Ingen har brug for denne friktion.

Min teamkammerat Kevin Powell har imidlertid en sund vane med at lagre variabler øverst i en komponentstilfil. F.eks. Identificerer en del af variabler, der bruges i formkomponentens stil, mange applikationer af tekstfarve til at danne elementer som inline-fejl, input, etiketter og pladsholder-tekst.

Emerging-komponentfil til venstre med filspecifikke variabler øverst let at sammenligne med og overveje for tokens-filen til højre.

Disse komponentspecifikke variabler tilbyder en nyttig fortegnelse over kandidater, der skal dimittere til token-biblioteket. Her kan vi få en mulighed for at erstatte en mindre specifik deaktiveret farve på $ farve-neutral-90 med den er mere forsætlig $ baggrund-farve-deaktiveret i filen form_elements.styl. På den anden side er komponentens $ grænse-farve-input-hover mindre sandsynligt for genbrug ud over former og dermed en dårlig token-kandidat.

Takeaway: Opmuntrer vaner inden for design og udvikling, der parkerer genanvendelige beslutninger - token-kandidater - på et forudsigeligt sted såsom toppen af ​​en tekstfil eller hjørne af designkunst.

# 6. Cope med systemisk ændring Forudsigeligt

Tokens er et vidunderligt værktøj, når du formulerer et uberørt system fra bunden. Men hvad med 18 måneder fra nu, når designbeslutninger udvikler sig? Hvordan ændrer et symbol kaskade? Hvad er risiciene, og hvordan afhjælpes du?

Tokens beskytter dig mod uforudsigelige, udbredte ændringer på grund af deres specificitet og - som et resultat - mere begrænset og forsætlig brug.

Søger efter en generisk variabel

Tidligere kammer du og vurderer et oplagringssted for en # 2B303B hex-kode eller $ color-neutral-20 variabel anvendt til utallige forskellige elementer. Boo!

Søger efter en bestemt beslutning.

Nu sporer du bredden i brugen af ​​$ tekst-farve-mikrokopi nøjagtigt og indsnævrer risikoen. Ja!

Takeaway: Udnyt et token's vedligeholdelsesfordele, og brug det som et salgsargument for dit adoptionsteam.

Implementering af tokens

De fleste hold begynder at konsolidere beslutninger som en enorm stak med forudsigelige, hierarkiske variablenavne i en SASS- eller Stylus-fil. Men denne fil begraver beslutninger et sted, hvilket begrænser brugen til denne teknologi.

Det efterlader løftet om symboler uopfyldte. Et første skridt i spredning af symboler i et system er at frigøre dem med et åbent format som JSON.

# 7. Gør token data genanvendelige via JSON

JSON er en ideel åben standard til kodning af hierarkiske navn / værdipar til genbrug på tværs af værktøjer.

Med symboler i JSON kan du transformere beslutninger for flere forbehandlere - SASS, Stylus og MINDRE - som dit samfund kræver. Dette åbner døren til produkter, der er begrænset til en forbehandler, de ikke kan eller ikke vil efterlade, selvom det ikke er systemets "anbefalede".

Tilsvarende skaber JSON en bro til andre platforme, hvad enten de direkte forbruges i iOS-arbejde eller omdannes til XML til Android-teams.

Takeaway: Koder tokens i et format, der kan genanvendes på tværs af platforme, og udsæt dem i en form, som alle kan bruge.

# 8. Håndter & læs token data let via YAML

JSON er kraftfuld, hierarkisk og fleksibel. Det er dog ufuldstændigt som et sted at administrere data. Syntaks er ordret, tilbøjelig til fejl, når manuelt er samlet, mangler kommentarstøtte og mangler variabler.

Indtast YAML, et mere menneskeligt læsbart sprog til registrering af hierarkiske egenskaber / værdipar. YAML tilføjer variabler og kommentarer til JSONs hierarkiske kapacitet i et mere læseligt format. YAML hjælper hurtigt med at vise symboler læsbart for ethvert publikum, og dens enkelhed åbner en grænse for designere til at foreslå nye værdier og endda sende selv anmodning om pull.

Vores team bruger yamljs til at omdanne de YAML-data, vi administrerer som en enkelt-kilde til sandhed, til et JavaScript-objekt som et trin i vores build-proces.

Takeaway: Overvej YAML til at give designere mulighed for at engagere sig i og arbejde med kode, så de nærmer sig koden og dem, der bruger kode.

# 9. Automatiser dokumentation med token data

Det er ikke værdifuldt at integrere designbeslutninger i kode, hvis designere og udviklere ikke ved, hvad beslutningerne er, og hvordan de får adgang til dem. Derfor bruger vi tokens som indhold så meget som vi koder.

I vores systemer trækker vi tokens som en datastruktur (tænk: JSON) i skabeloner for at vise beslutninger i en tokensreference og andre emner som mellemrum og temaknapper.

Grundlæggende skabeloner til dokumentationssite, drevet af tokendata

Anden dokumentation er mere tilpasset, f.eks. En farvetone stack, der inkluderer navne, tilgængelighedsresultater med mere. Selvom det ikke er en simpel loop gennem tokenhierarki, kan dokumentationen stadig bruge tokens direkte.

Takeaway: Brug symboler til at berige, hvordan din levevej kan leve.

# 10. Integrer token-data i designværktøjer, også

Token data kan inspirere ideer til værktøjer til ikke kun udviklere, men også designere. Vi taler om at oprette brugerdefinerede værktøjer til vores porteføljes designer-community i værktøjer som Sketch, Photoshop eller (tilbage i dagen) InDesign.

Sådan software tilbyder varierende robuste kroge til at bruge JSON-data til din fordel. For eksempel er InVisions Craft afhængig af JSON-objekter, der er gemt som tekst i undermapper, hvilket antyder en mulig integration med output fra vores systems build-proces. Sådanne forbindelser var anstrengende og tavede nok i fortiden, at de ville blive ignoreret. I dag føler de sig mere realistiske, efterhånden som et system modnes.

Takeaway: Identificer muligheder for at udvide systemet til designerværktøjer, især designsoftware. Overvej omkostninger - både opsætning og vedligeholdelse - i forhold til fordelene for din systembrugers oplevelse.

Jo mere mine teams bruger tokens, jo mere hjemme føler jeg mig for at diskutere design. Trådning af smarte beslutninger kodet med meningsfulde navne hjælper mig med at stole på, at output fra mit team går mod ambitionen om et mere sammenhængende, vedligeholdeligt system.

Om at gå i gang med et designsystem eller har brug for at dykke dybere for at diskutere produkter og spillere? EightShapes afholder systemplanlægningsworkshops og coacher klienter i designsystemer. Lad os tale!