Ontwerpsystemen vrijgeven

Het leveren van onderling verbonden uitgangen aan Adopters na verloop van tijd

# 1 van 6 van de serie Releasing Design Systems:
Uitgangen | Cadans | Versies | Breken | Afhankelijkheden | Werkwijze

Bedrijven realiseren de waarde van een ontwerpsysteem bij het adopteren van producten en gebruiken een systeem om ervaringen te maken en te verzenden die hun klanten gebruiken. Als onderdeel van die waardeketen geeft het systeem in de loop van de tijd functies vrij. Hierdoor is het systeem in handen van de klant: ontwerpers en ingenieurs doen hun werk.

Sterke systeemteams nemen releases serieus. Ze zien zichzelf niet als het vrijgeven van alleen componentbibliotheekcode. In plaats daarvan leveren ze veel meer uitgangen: ontwerptokens, documentatie, ontwerpelementen en andere bronnen.

Deze serie beschrijft vele facetten van het vrijgeven van ontwerpsystemen. Het begint met het definiëren van de vele uitgangen van een systeem en waar deze worden afgeleverd. De volgende artikelen behandelen onderwerpen van cadans, versiebeheer, het doorbreken van wijzigingen, afhankelijkheden en een stapsgewijze aanpak.

Deze verhalen weerspiegelen wat ik heb geleerd bij het vrijgeven van systemen die werken met teams zoals Discovery Education, Morningstar, Target en REI. Ze worden verhoogd door inzichten van collega's van Salesforce, Adobe, Atlassian, Shopify en Financial Times. Bedankt voor het delen van je tijd en oefeningen!

Uitgangen: wat is vrijgegeven?

Ontwerpsysteemprogramma's geven veel soorten uitgangen vrij, niet alleen code. Als gevolg hiervan moet een systeem dit bereik van uitgangen met versiebeheer differentiëren en communiceren naar ontwikkelaars, ontwerpers en andere klanten.

Code, de bron van waarheid

De meeste systemen bieden een enkele bron van waarheid van presentatielaagcode als:

  • UI-componentenbibliotheek als HTML Markup & CSS. Vaak aangeduid als "de CSS", berust het verbruik van dit pakket op het gebruik of het compileren van CSS als een consistente basislijn van de visuele stijl in combinatie met het hergebruiken van HTML-fragmenten.

en / of ...

  • UI Components Library als Javascript: veel systemen omsluiten HTML en CSS met JavaScript om logica te versterken, stijl in te kapselen en integratie en onderhoud directer te vergemakkelijken in een kader naar keuze. Hoewel de meeste bibliotheken zich richten op een specifiek framework (React, Vue, Ember, Angular, ...), suggereren industriële signalen een verschuiving naar het maken van webcomponenten voor alle frameworks. Mijn laatste zes systeeminspanningen? Later 2017: Vanilla HTML, Vanilla HTML. Begin 2018: React, Vue. Later 2018: Web Components, Web Components.

Bovendien kunnen andere prominente uitgangen afzonderlijk worden vrijgegeven:

  • Ontwerp tokens die een visuele stijl creëren via semantisch betekenisvolle eigenschap-waarde paren. Tokens zijn variabelen die in veel formaten beschikbaar zijn voor gebruik op verschillende platforms (web, iOS, Android), preprocessors (Sass en MINDER) en frameworks (zoals React). Sommige systemen beheren tokens in een repository, gescheiden van de UI-componentcode. Als gevolg hiervan kan hun bibliotheek - samen met andere implementaties - ook afhankelijk zijn van token als een pakket.
  • Demo Apps / Sites als een omgeving met pagina-voorbeelden gebouwd met behulp van de componentenbibliotheek. De demo’s zijn ook voor tutorials en rapid prototyping, inclusief door ontwerpers!
  • Platformoverschrijdende componenten geschikt voor iOS, Android en Windows.

Ontwerpactiva

De meeste teams beperken het begrip van wat ze vrijgeven tot simpel "we geven code vrij." Het is een eye-opening voor hen om te beseffen dat ze zoveel andere tools publiceren die in de loop van de tijd veranderen. Ze bevatten:

  • Design Toolkits als sjabloonbestanden en symboolbibliotheken aangeboden in ontwerpsoftware. Tegenwoordig bijna altijd Sketch. Morgen, Figma, Invision Studio en andere opkomende concurrenten?
  • Lettertypen, pictogrammen en zelfs de afbeeldingssets van Origami vanwege de vaak verwachte rol van een systeem bij het distribueren en versiebeheer van dergelijke bibliotheken.
  • Andere ontwerpbronnen zoals illustratie- en kleurstaal ASE / CLR-bestanden als springplank voor op maat gemaakte illustraties. Deze collecties veranderen langzaam, minder formeel en via bijdragen van communityleden geen onderdeel van een systeemkernteam. Maar vanuit het perspectief van de klant en de communicatie van het systeem, maakt het deel uit van het systeem.

Documentatiesite

Ontwerpsystemen hebben een thuis nodig, een plek waarvan iedereen weet dat ze een weg kunnen vinden naar alles wat de nieuwste en beste zal hebben. Gehuisvest op een memorabele URL, wordt het vaak gebouwd met UI-componenten die specifiek zijn voor de missie.

  • Documentatiesites beschrijven functies (zoals een knop), nieuwe gebruikers aan boord en activeren processen zoals hulp vragen of bijdragen. Teams bouwen sites vaker met een statische sitegenerator of minder vaak met een contentbeheersysteem.
  • Documentatiecomponenten - codevoorbeeld-paar, niet doen, hex-code, component-verkenner - zijn afhankelijk van de UI-componentenbibliotheek en bedienen meestal alleen de doc-site. Dergelijke componenten kunnen worden bijgewerkt met de documentatie-site of als een derde, afzonderlijk versiegebaseerde bibliotheek ten opzichte van doc en de UI-componenten waartussen ze staan.

Bestemmingen: Waar gaat het heen?

Bij het distribueren van code en ontwerpmiddelen is het van vitaal belang om de code aan te bieden op manieren die het gemakkelijkst worden gebruikt door uw adoptie-ingenieurs. Dit betekent dat sommige systemen keuze uit een groot aantal opties moeten bieden, terwijl andere op een enkele keuze als organisatiestandaard kunnen vertrouwen.

Voor code

  • BESTE: registers zoals npmjs (of een interne tegenhanger zoals de nexus van Sonatype) die toegang en beheer bieden voor vrijgegeven codepakketten. Ontwikkelaars gebruiken vervolgens hulpmiddelen zoals bower, npm, garen, webpack en babel om die code soepel in hun omgeving te integreren en te upgraden.
  • BETER: Gehoste middelen op CDN's voor directe koppelingen naar versiestijl en script, evenals lettertypen en pictogrammen die langzamer veranderen.
  • GEWOON OK: Repository Toegang tot Github, Bitbucket of iets dergelijks om te klonen, forceren of anderszins compileren, gebruiken en misschien - uiteindelijk - bijdragen.
  • INDIEN NODIG: Direct Code Downloads, meestal van “het ZIP-bestand” van gecompileerde of niet-gecompileerde systeemactiva van de doc-site voor lokaal gebruik en / of handmatige integratie in een afzonderlijke repository.

Bootstrap en Material Design Lite zijn voorbeelden voor meer dan 2 bestemmingen.

Voor ontwerptoolkits

  • BESTE: maak Nieuw als een gesynchroniseerd, ingesloten pad in het menu van een ontwerptool om een ​​nieuwe instantie van een sjabloon te maken.
  • BETER: Versies en gedistribueerd met behulp van op toestemming gebaseerde ontwerpactiva-managementsoftware zoals Abstract of Lingo.
  • GOED: Directe toolkit-download van een documentatie-site, met duidelijke versie aangegeven en bijbehorend Aan de slag-document in de buurt.
  • ENKEL OK: Gedeelde schijf, via goed gepubliceerde en mogelijk vereenvoudigde interne URL (zoals http: //system.uitoolkit).
  • NIET GOED GENOEG: begraven op een pagina op het vierde niveau op een nauwelijks georganiseerde wikisite die veel mensen niet kunnen vinden.

Volgende → # 2. Cadans