Tokens in ontwerpsystemen

10 tips voor het ontwerpen en implementeren van ontwerpbeslissingen voor iedereen

In een recente codebeoordeling bewogen mijn passies toen ik door de stijl van een pilonderdeel liep met een designteamgenoot.

Ik kon mijn opwinding nauwelijks bevatten:

"Kijken. Ja, het is code, maar kijk goed naar die tokens. Weet je hoe dit eruit ziet? Zoals specificaties! Dus? Ik kan dit lezen, net als jij. En we kunnen deze overal inpassen: doc, ontwerpen en convos ook. Overal!"

De reactie van mijn teamgenoot duidde op nieuwsgierigheid, zelfs als deze niet overeenkwam met de emotionele slag van mijn uitbarsting. Hij is geen nerd van het systeem zoals ik. Nog niet, tenminste. Maar hij begreep wat ertoe deed: er is een zichtbaar pad voor beslissingen die we nemen naar waar ze worden geïmplementeerd.

We hebben zoveel moeite gedaan om te proberen ontwerp uit onze variabelen te halen - die meest atomaire van herbruikbare codebits - ik voelde me onmiddellijk aangetrokken tot het idee om ontwerp weer in te zetten.

Dit is hoe we tokens hebben ontwikkeld, ontwikkeld en geïmplementeerd tijdens het ontwerp, de code en de samenwerking.

Van variabelen tot tokens

Elk ontwerpsysteem biedt opties. Kleuren kunnen bijvoorbeeld schalen van zwart over neutraal naar wit. Elke neutraal - geïdentificeerd via een HEX-code zoals # 2B303B - kan worden opgeslagen en beschikbaar worden gemaakt in een variabele $ color-neutral-20, voor gebruik in een preprocessor zoals Sass.

Variabelen halen het mysterie uit obscure waarden. Maar ze overbruggen de kloof tussen naamgeving en gebruik niet. Ze antwoorden "Welke opties heb ik?" Maar laten "Welke keuze moet ik maken?" Onduidelijk.

Opties zijn niet goed genoeg.

Ontwerpbeslissingen, een optie toegepast op een context

De kracht van een systeem komt van het weten hoe opties (zoals $ color-neutral-20) op contexten (zoals een conventionele donkere achtergrondkleur) moeten worden toegepast. Dit motiveert de optie als een beslissing.

Dat zijn beslissingen die ik met vertrouwen kan gebruiken!

Dergelijke beslissingen worden echter meestal nog steeds begraven in een bestand in een repo die wordt gebruikt door ontwikkelaars die werken aan het webgebaseerde product dat zij bezitten. Hoe zit het met ontwerpers? Andere webproducten? Op andere platforms zoals iOS en Android? We hebben voor iedereen gecodeerde beslissingen gecodeerd, maar ze bezaten in een kerker van een repo die niemand anders kan vinden.

Ontwerp tokens, beslissingen doorgegeven via een systeem

Salesforce UX biedt een glimp. Hun ideeën boeien me, vooral hun Living Style Guide-concept dat Design Tokens op producten toepast met hun open source Theo-tool.

Hier worden opties en beslissingen niet begraven in Sass-bestanden. In plaats daarvan worden ze gecentraliseerd en verspreid als tokens voor elk product, ontwerper of ontwikkelaar die het systeem gebruikt, in gemakkelijk te gebruiken, voorspelbare formaten.

Honderden tokens kunnen leesbare, opzettelijke en traceerbare beslissingen worden die in de producten van een portfolio of onderneming zijn verweven.

Zie je de beslissingen als een groot specificatieblad? Ik kan. Ontwerpers kunnen dat ook. Met zo'n zichtbaarheid en tooling herkennen ze de impact van hun beslissingen. Eerder hebben we gekozen voor $ color-neutral-80 voor een rand of achtergrond met een beetje eigenzinnigheid. Nu passen we op een doordachte, conventionele manier $ border-hairline of $ background-color-light toe.

Ontwerpers beginnen samen te werken. Ze nemen beslissingen met meer overleg en zelfvertrouwen, organiseren hun gedachten in een structuur die ze delen. Ontwikkelaars volgen dit voorbeeld.

Dit kan nauwgezette activiteiten zoals redlines en pixelmetingen omzetten in samenwerking die rijk is aan token talk. Overal in ons werk - kritiek geven op ontwerpconcepten, acceptatiecriteria schrijven, pull-aanvragen beoordelen - is de architectuur en implementatie van tokens altijd aanwezig.

Tokens voor architecten

Een succesvolle, duurzame tokenarchitectuur is afhankelijk van eenvoudige groepering, ordening, classificatie en besluitvorming.

# 1. Eerst opties weergeven, daarna beslissingen

Je kunt geen beslissingen nemen zonder opties. Tokens zijn een effectief instrument om het pad van de ene naar de andere te illustreren.

In onze tokenbestanden beginnen we met opties zoals beschikbare kleuren. Daarna passen we opties toe op contexten zoals ‘tekstkleur’ en ‘achtergrondkleur’.

Afhaalmaaltijden: organiseer uw beslissingen om hun atomaire basis voor te stellen: bouwen van opties tot beslissingen en eenvoudig tot complex.

# 2. Begin met kleur en lettertype en stop daar niet!

Ik heb het vaak over de grote drie van een ontwerptaal: kleur, typografie en iconografie. Het is dus geen verrassing dat ons tokenbestand begint met kleur- en typeopties en beslissingen (pictogrammen worden elders geautomatiseerd). Visuele stijl is echter samengesteld uit zoveel meer, en dus kunnen tokens.

Hoewel we beginnen met het toepassen van kleur op achtergrond en tekst, breiden we ons uit naar veel andere soorten beslissingen, waaronder dingen als:

Afhaalmaaltijden: begin met maar stop niet met alleen kleur en type. Breid uw beslissingen uit om de talloze zorgen van een ontwerptaal te dekken.

# 3. Varieer opties over zinvolle schalen

Veel tokenized concepten omvatten schalen om uit te kiezen, zoals maat t-shirts (XS, S, M, L, XL, XXL), progressies (zoals een geometrische 2, 4, 8, 16, 32, 64) of aangepaste terminologie (zoals compact, gezellig en comfortabel). Weegschalen kunnen ook beginnen met een paar opties (alleen S & M) en groeien naar meer als dat nodig is.

Schalen bieden de mogelijkheid om een ​​tokenhiërarchie te vertakken naar vergelijkbare maar toch verschillende varianten, zoals het verrijken van spatie-inzet (van XS tot XL) tot varianten van spatie-inzet-squish en spatie-inzet-stretch (beide bieden ook XS tot XL).

Het eens worden over een schaalmodel - t-shirts of progressies, u beslist! - voor bereiken als deze is een teamspecifiek streven. Nog moeilijker, u moet verharde schalen vermijden die niet bestand zijn tegen het later invoegen van een tussenstap.

Afhaalmaaltijden: schalen goedkeuren en tokeniseren en demonstreren hoe deze in verschillende scenario's worden toegepast.

# 4. Nodig bijdrage uit, maar beheer de verzameling

Wanneer rechtvaardigt een keuze een token? Eenmalig gebruik: nee, niet genoeg. Een seconde kan overtuiging missen. Maar drie? Als het zoveel opduikt, is het meestal symbolisch waard. Er zijn uitzonderingen, maar de criteria '3 keer gebruikt?' Roepen discussie op.

Dus wie is de token-poortwachter? Niemand, als we gezonde processen gebruiken voor ontwerp en ontwikkelaarsrecensies. Iedereen kan tokens voorstellen, kandidaten in een concept opduiken of pull-aanvragen. Ons Slack-kanaal praat ook veel.

Desalniettemin fungeer ik als tokencurator, werk scannen met oog voor tokenkandidaten. Ik mag de opmaak van een verzoek afronden en het JavaScript overslaan. Ik scan echter stijl- en tokenbestanden grondig om namen te verfijnen, eigenzinnige genomineerden opnieuw te classificeren en overmatige uitbreiding aan te vechten. Iedereen heeft een symbolische stem. Maar niet iedereen geeft genoeg of heeft tijd om tokens schoon te houden.

Afhaalmaaltijden: maak van tokens een team en probeer (zelfs als impliciet) een gestructureerde architecturale geest aan te wijzen om de collectie samen te stellen.

# 5. Gediplomeerde beslissingen van componenten tot tokens

Het is een afleiding om hersenkracht af te leiden om constant tokens, tokens, tokens te denken. “Moet dit een nieuw token zijn? Is dat een teken? Ik gebruik geen token? Oh nee! ”Niemand heeft deze wrijving nodig.

Mijn teamgenoot Kevin Powell heeft echter de gezonde gewoonte om variabelen op te slaan bovenaan een bestand met een componentstijl. Een deel van de variabelen die in de stijl van zijn formuliercomponent worden gebruikt, identificeren bijvoorbeeld vele toepassingen van tekstkleur om elementen te vormen, zoals inline-fouten, invoer, labels en plaatsaanduidingstekst.

Nieuw componentbestand aan de linkerkant, met bestandsspecifieke variabelen bovenaan eenvoudig te vergelijken en te overwegen voor het tokensbestand aan de rechterkant.

Deze componentspecifieke variabelen bieden een nuttige inventaris van kandidaten om af te studeren naar de tokenbibliotheek. Hier kunnen we een kans grijpen om een ​​minder specifieke uitgeschakelde kleur van $ color-neutral-90 te vervangen door een meer opzettelijke $ background-color-disabled in het bestand form_elements.styl. Aan de andere kant is de $ border-color-input-hover van het onderdeel minder waarschijnlijk voor hergebruik dan formulieren en dus een slechte tokenkandidaat.

Afhaalmaaltijden: stimuleer gewoonten in ontwerp en ontwikkeling die herbruikbare beslissingen - symbolische kandidaten - op een voorspelbare plaats zoals de bovenkant van een tekstbestand of hoek van designkunst parkeren.

# 6. Voorspelbaar omgaan met systemische verandering

Tokens zijn een prachtig hulpmiddel als je een volledig nieuw systeem formuleert. Maar hoe zit het met 18 maanden vanaf nu, wanneer ontwerpbeslissingen evolueren? Hoe verandert een token cascade? Wat zijn de risico's en hoe beperk je ze?

Tokens beschermen je tegen onvoorspelbare, wijdverspreide veranderingen gezien hun specificiteit en - als gevolg daarvan - beperkter en opzettelijk gebruik.

Zoeken naar een generieke variabele

Eerder kamde en evalueerde u een repository voor een # 2B303B hex-code of $ color-neutral-20 variabele toegepast op talloze verschillende elementen. Boe-geroep!

Zoeken naar een specifieke beslissing.

Nu traceer je de breedte van het gebruik van $ text-color-microcopy precies en beperk je het risico. Ja!

Afhaalmaaltijden: profiteer van de onderhoudsvoordelen van een token en gebruik dat als verkoopargument voor uw adoptieteam.

Tokens implementeren

De meeste teams beginnen beslissingen te consolideren als een enorme stapel voorspelbare, hiërarchische variabelenamen in een SASS- of Stylus-bestand. Maar dat bestand begraaft beslissingen op één plek, waardoor het gebruik tot die technologie wordt beperkt.

Dat laat de belofte van tokens onvervuld. Een eerste stap in het verspreiden van tokens door een systeem is ze te bevrijden met een open formaat zoals JSON.

# 7. Maak Token Data Herbruikbaar, via JSON

JSON is een ideale open standaard voor het coderen van hiërarchische naam / waarde-paren voor hergebruik in verschillende tools.

Met tokens in JSON kunt u beslissingen voor meerdere preprocessors - SASS, Stylus en MINDER - transformeren zoals uw community vereist. Dit opent de deur naar producten die beperkt zijn tot een preprocessor die ze niet kunnen of niet achterlaten, zelfs als dit niet de "aanbevolen" optie van het systeem is.

Op dezelfde manier maakt JSON een brug naar andere platforms, of deze nu rechtstreeks wordt gebruikt in iOS-werk of wordt omgezet in XML voor Android-teams.

Afhaalmaaltijden: codeer tokens in een formaat dat herbruikbaar is op verschillende platforms, zodat ze worden weergegeven in een vorm die iedereen kan gebruiken.

# 8. Beheer en lees tokengegevens gemakkelijk, via YAML

JSON is krachtig, hiërarchisch en flexibel. Het is echter imperfect als een plaats om gegevens te beheren. Syntaxis is uitgebreid, foutgevoelig bij handmatig beheer, mist commentaarondersteuning en mist variabelen.

Voer YAML in, een beter leesbare taal voor het opnemen van hiërarchische eigenschap / waarde-paren. YAML voegt variabelen en opmerkingen toe aan de hiërarchische mogelijkheden van JSON in een beter leesbaar formaat. YAML helpt snel tokens leesbaar te tonen aan elk publiek en de eenvoud opent een grens voor ontwerpers om nieuwe waarden te suggereren en zelfs zelf pull-aanvragen in te dienen.

Ons team gebruikt yamljs om de YAML-gegevens die we beheren als een enkele bron van waarheid om te zetten in een JavaScript-object als een stap van ons bouwproces.

Afhaalmaaltijden: Overweeg YAML om ontwerpers in staat te stellen met code te werken en eraan te werken, waardoor ze dichter bij code komen te staan ​​en degenen die code gebruiken.

# 9. Automatiseer documentatie met tokengegevens

Het inbedden van ontwerpbeslissingen in code is niet waardevol als ontwerpers en ontwikkelaars niet weten wat de beslissingen zijn en hoe ze kunnen worden benaderd. Daarom gebruiken we tokens evenveel inhoud als code.

In onze systemen verwerken we tokens als datastructuur (denk aan JSON) in sjablonen om beslissingen in een tokensreferentie en andere onderwerpen zoals spatie en themaknoppen weer te geven.

Basissjablonen voor documentatie-site, aangedreven door token-gegevens

Andere documentatie is meer aangepast, zoals een kleurentintstapel met namen, toegankelijkheidsscores en meer. Hoewel het geen eenvoudige lus door tokenhiërarchie is, kan de documentatie nog steeds rechtstreeks tokens gebruiken.

Afhaalmaaltijden: gebruik tokens om te verrijken hoe levend je levende gids kan zijn.

# 10. Ook tokengegevens insluiten in ontwerptools

Tokengegevens kunnen ideeën voor tools inspireren voor niet alleen ontwikkelaars, maar ook voor ontwerpers. We praten over het bouwen van aangepaste tools voor de ontwerpersgemeenschap van onze portfolio in tools zoals Sketch, Photoshop of (vroeger) InDesign.

Dergelijke software biedt variërend robuuste hooks om JSON-gegevens in uw voordeel te gebruiken. InVision's Craft is bijvoorbeeld afhankelijk van JSON-objecten die zijn opgeslagen als tekst in submappen, wat een mogelijke integratie suggereert met de output van het buildproces van ons systeem. Zulke verbindingen waren in het verleden moeiteloos genoeg stilgelegd om te negeren. Tegenwoordig voelen ze zich realistischer naarmate een systeem ouder wordt.

Afhaalmaaltijden: identificeer mogelijkheden om het systeem uit te breiden naar ontwerptools, met name ontwerpsoftware. Overweeg kosten - zowel installatie als onderhoud - in verhouding tot de voordelen voor de ervaring van uw systeemgebruiker.

Hoe meer mijn teams tokens gebruiken, hoe meer ik thuis het ontwerp bespreek. Door slimme beslissingen in te voeren die zijn gecodeerd met betekenisvolle namen, kan ik erop vertrouwen dat de output van mijn team op weg is naar het streven naar een meer samenhangend, onderhoudbaar systeem.

Wil je beginnen met een ontwerpsysteem of moet je dieper duiken om producten en spelers te bespreken? EightShapes geeft workshops voor systeemplanning en begeleidt klanten bij ontwerpsystemen. Laten we praten!