Design-Systeme freigeben

Bereitstellung miteinander verbundener Ausgänge für Anwender im Laufe der Zeit

# 1 von 6 der Reihe Releasing Design Systems:
Ausgänge | Trittfrequenz | Versionen | Brechen | Abhängigkeiten | Verarbeiten

Unternehmen erkennen den Wert eines Designsystems, wenn sie Produkte einführen, die ein System verwenden, um Erfahrungen zu machen und zu vermitteln, die ihre Kunden nutzen. Als Teil dieser Wertschöpfungskette gibt das System Funktionen im Laufe der Zeit frei. Dies gibt das System in die Hände seiner Kunden: Designer und Ingenieure erledigen ihre Arbeit.

Starke Systemteams nehmen Releases ernst. Sie sehen sich nicht nur als Herausgeber von Komponentenbibliothekscode. Stattdessen liefern sie viel mehr Ergebnisse: Entwurfstoken, Dokumentation, Entwurfsressourcen und andere Ressourcen.

Diese Serie beschreibt viele Facetten der Freigabe von Designsystemen. Es beginnt damit, die vielen Ausgänge eines Systems zu definieren und zu bestimmen, wo sie geliefert werden. In den folgenden Artikeln werden die Themen Trittfrequenz, Versionierung, wichtige Änderungen und Abhängigkeiten sowie eine schrittweise Vorgehensweise behandelt.

Diese Geschichten reflektieren, was ich gelernt habe, um Systeme freizugeben, die mit Teams wie Discovery Education, Morningstar, Target und REI zusammenarbeiten. Sie werden durch die Erkenntnisse der Kollegen von Salesforce, Adobe, Atlassian, Shopify und Financial Times ergänzt. Vielen Dank für das freundliche Teilen Ihrer Zeit und Übungen!

Outputs: Was ist freigegeben?

Design Systems-Programme geben viele Arten von Ausgaben frei, nicht nur Code. Aus diesem Grund sollte ein System diesen Bereich versionierter Ausgaben für Entwickler, Designer und andere Kunden differenzieren und kommunizieren.

Code, die Quelle der Wahrheit

Die meisten Systeme bieten eine einzige Quelle für den Code der Präsentationsschicht:

  • UI Component Library als HTML Markup & CSS. Oft als "CSS" bezeichnet, beruht der Verbrauch dieses Pakets auf der Verwendung oder Kompilierung von CSS als konsistente visuelle Stilgrundlage in Verbindung mit der Wiederverwendung von HTML-Snippets.

und / oder ...

  • UI-Komponentenbibliothek als Javascript: Viele Systeme binden HTML und CSS in JavaScript ein, um die Logik zu stärken, den Stil zu kapseln und die Integration und Wartung direkter in einem Framework Ihrer Wahl zu vereinfachen. Während die meisten Bibliotheken auf ein bestimmtes Framework abzielen (React, Vue, Ember, Angular,…), deuten Industriesignale auf eine Verlagerung hin, um Webkomponenten für alle Frameworks zu erstellen. Meine letzten sechs Systemanstrengungen? Später 2017: Vanilla HTML, Vanilla HTML. Anfang 2018: Reagieren Sie, Vue. Später 2018: Webkomponenten, Webkomponenten.

Darüber hinaus können andere wichtige Ausgänge separat freigegeben werden:

  • Design-Token, die über semantisch bedeutsame Eigenschaftswertpaare einen visuellen Stil etablieren. Tokens sind Variablen, die in vielen Formaten für die plattformübergreifende Verwendung (Web, iOS, Android), für Präprozessoren (Sass und LESS) und für Frameworks (wie React) verfügbar sind. Einige Systeme verwalten Token in einem vom UI-Komponentencode getrennten Repository. Infolgedessen kann ihre Bibliothek - zusammen mit anderen Implementierungen - auch vom Token als Paket abhängen.
  • Demo-Apps / Sites als Umgebung mit Seitenbeispielen, die mithilfe der Komponentenbibliothek erstellt wurden. Die Demo eignet sich auch für Tutorials und Rapid Prototyping, auch von Designern!
  • Plattformübergreifende Komponenten für iOS, Android und Windows.

Design Assets

Die meisten Teams beschränken sich auf das Verständnis der von ihnen veröffentlichten Inhalte auf das einfache Freigeben von Code. Es ist für sie eine Augenweide, zu erkennen, dass sie so viele andere Tools veröffentlichen, die sich im Laufe der Zeit ändern. Sie beinhalten:

  • Design-Toolkits als Vorlagendateien und Symbolbibliotheken, die in der Design-Software angeboten werden. Heute fast immer Skizze. Morgen, Figma, Invision Studio und andere aufstrebende Wettbewerber?
  • Schriftarten, Symbole und sogar Origamis Bildersätze aufgrund der häufig erwarteten Rolle eines Systems bei der Verteilung und Versionierung solcher Bibliotheken.
  • Weitere Designressourcen wie ASE / CLR-Illustrations- und Farbmusterdateien als Sprungbrett für maßgeschneiderte Grafiken. Diese Sammlungen ändern sich langsam, weniger formal und durch Beiträge von Community-Mitgliedern, die nicht Teil eines Systemkernteams sind. Aus Sicht des Kunden und der Systemkommunikation ist es jedoch Teil des Systems.

Dokumentationsseite

Designsysteme brauchen ein Zuhause, einen Ort, von dem jeder weiß, dass er einen Weg zu allem finden kann, was das Neueste und Beste bietet. Es befindet sich unter einer einprägsamen URL und besteht häufig aus UI-Komponenten, die für die jeweilige Mission spezifisch sind.

  • Dokumentationsseiten beschreiben Funktionen (wie eine Schaltfläche), binden neue Benutzer ein und lösen Prozesse wie das Abrufen von Hilfe oder das Bereitstellen von Beiträgen aus. Teams erstellen Websites häufiger mit einem statischen Websitegenerator oder seltener mit einem Inhaltsverwaltungssystem.
  • Dokumentationskomponenten - Code-Beispiel-Pair, Do-Dont, Hex-Code, Komponenten-Explorer - hängen von der UI-Komponentenbibliothek ab und dienen normalerweise nur der Dokumentsite. Solche Komponenten können mit der Dokumentationssite oder als dritte, separat versionierte Bibliothek in Bezug auf doc und die UI-Komponenten, zwischen denen sie liegen, versioniert werden.

Reiseziele: Wohin geht es?

Bei der Verteilung von Code und Design-Assets ist es wichtig, den Code in einer Weise anzubieten, die von Ihren Adoptionsexperten am einfachsten verwendet wird. Dies bedeutet, dass einige Systeme eine Auswahl aus vielen Optionen bieten müssen, während andere sich auf eine einzige Auswahl als Organisationsstandard verlassen können.

Für Code

  • BEST: Registries wie npmjs (oder ein internes Gegenstück wie Sonatypes Nexus), die den Zugriff auf und die Verwaltung von veröffentlichten Code-Paketen ermöglichen. Entwickler verwenden dann Tools wie bower, npm, yarn, webpack und babel, um diesen Code nahtlos in ihre Umgebung zu integrieren und zu aktualisieren.
  • BESSER: Gehostete Assets auf CDNs für direkte Links zu versioniertem Stil und Skript sowie zu Schriftarten und Symbolen, die sich langsamer ändern.
  • NUR OK: Repository-Zugriff auf Github, Bitbucket oder ähnliches, um zu klonen, abzweigen oder auf andere Weise zu kompilieren, zu verwenden und - möglicherweise - beizutragen.
  • FALLS ERFORDERLICH: Direktcode-Downloads, in der Regel von der ZIP-Datei kompilierter oder nicht kompilierter Systemressourcen von der Doc-Site zur lokalen Verwendung und / oder manuellen Integration in ein separates Repository.

Bootstrap und Material Design Lite sind Beispiele für die Freigabe von 2 oder mehr Zielen.

Für Design Toolkits

  • BEST: Neu erstellen als synchronisierter, eingebetteter Pfad im Menü eines Design-Tools, um eine neue Instanz aus einer Vorlage zu erstellen.
  • BESSER: Versioniert und verteilt mit einer auf Berechtigungen basierenden Design Asset Management Software wie Abstract oder Lingo.
  • GUT: Direkter Toolkit-Download von einer Dokumentationssite mit Angabe der eindeutigen Version und zugehörigem Erste-Schritte-Dokument in der Nähe.
  • NUR OK: Geteiltes Laufwerk über eine gut publizierte und möglicherweise vereinfachte interne URL (z. B. http: //system.uitoolkit).
  • NICHT GENUG GUT: Vergraben auf einer Seite der vierten Ebene auf einer kaum organisierten Wiki-Site, die viele Leute nicht finden können.

Weiter → # 2. Kadenz