Entwurfssystemarchitektur-Diagramme

Ein visuelles Vokabular, um Systeme, Produkte und Marken in Beziehung zu setzen

So viele Unternehmen präsentieren Ökosysteme, die weitaus komplexer sind als „ein Design-System, alle unsere Produkte“. Ich fand Diskussionen zwischen Gruppen und Systemleitern immer schwieriger. Bisher fehlte mir das Vokabular, um die Breite dieser vielen Systeme und die Art und Weise, wie sie verschiedene interne Kunden mit unterschiedlichen Funktionen bedienen, schnell zu zeigen und zu lehren.

Dieser Artikel enthält ein visuelles Vokabular von Marken, Systemen und Produkten. Das Vokabular kennzeichnet die unterschiedlichen Ausgaben, Dokumentationen, Annahmen und organisatorischen Grenzen eines Entwurfssystems. Abschließend wird das Vokabular anhand eines vollständigen, szenariobasierten Beispiels veranschaulicht.

Symbole

In Systemarchitekturdiagrammen werden Symbole (Rauten, Kreise und Quadrate) verwendet, um Objekte (Systeme, Produkte bzw. Markenidentitäten) zu kennzeichnen.

System, als Diamant

Jede Raute stellt einen expliziten oder impliziten Entwurfssystem-Funktionsumfang dar, einschließlich, aber nicht beschränkt auf einen definierten visuellen Stil, der auf eine oder mehrere UI-Komponenten angewendet wird, die als Entwurfs- und / oder Code-Assets angeboten werden.

Titel- und Beschreibungsetiketten werden optional rechts oben bei einer Drehung von 45 Grad angezeigt. Während die Position der Beschriftung angepasst werden kann, wenn ein Diagramm erstellt wird, ist es am unwahrscheinlichsten, dass diese Standardeinstellung mit Objekten und Konnektoren in Konflikt steht.

System-Tools - Design Assets & Code - als Semi-Diamonds

Jedes System bietet Design-Assets (wie Sketch, Figma oder Invision Studio), eine Codebibliothek oder beides. Aus diesem Grund wird der Systemdiamant unterteilt, um anzuzeigen, ob er Design-Assets (ein rotes D in der linken Hälfte des Symbols), Code (ein blaues C in der rechten Hälfte des Symbols) oder beides für seine Kunden bietet.

Gestaltungsrichtlinien & Code-Referenz als Diamanthintergrund

Die meisten Entwurfssysteme dokumentieren Beispiele visuell und - falls verfügbar - den Code, der zur Erzeugung dieses Ergebnisses verwendet wurde. Nicht alle Entwurfssysteme bieten jedoch tiefere Entwurfsrichtlinien und Code-Referenzmaterial. Beide werden normalerweise über eine gut gestaltete, webbasierte Website kommuniziert. Gelbe Hintergründe auf der linken und rechten Seite der Systemraute weisen daher auf die Verfügbarkeit von Gestaltungsrichtlinien bzw. Verweisen auf Codes hin.

Zum Beispiel bieten IBM Carbon, Shopify Polaris, Morningstar und REI Cedar (Offenlegung: Ich habe zu den beiden letztgenannten beigetragen) detaillierte Gestaltungsrichtlinien und Code-Referenzmaterial. Daher würde jeder einen vollen gelben Diamanten hinter den D & C-Ausgängen enthalten.

Andererseits bietet das Origami der Financial Times eine Codereferenz ohne Gestaltungsrichtlinien. Googles Material hatte lange Zeit umfangreiche Gestaltungsrichtlinien ohne Code bereitgestellt, obwohl sich dies kürzlich durch die locker gekoppelten Richtlinien und den Code in verschiedenen Architekturen einer viel breiteren Site geändert hat.

Salesforce Lightning Design System bietet relativ begrenzte Konstruktionsrichtlinien, die in die ansonsten codezentrierte Komponentendokumentation integriert sind. Daher möchte ich nur ungern darauf hinweisen, dass es auf der Website an detaillierten Gestaltungsrichtlinien mangelt.

Produkte als Kreise

Die grafische Darstellung der Verbindungen zwischen einem Konstruktionssystem und seinen Kunden ist unerlässlich. Einige betrachten ihre Arbeit möglicherweise nicht als „Produkt“ an sich. Ein Kreis steht jedoch für jedes digitale Erlebnis (oder einen Teil davon), das von einem Team erstellt wurde, das sich für die Einführung eines Systems entscheiden könnte.

Zum Beispiel kann ein E-Commerce-Erlebnis für jeden Schritt des Prozesses unterschiedliche Gruppen haben: Startseite, Suchergebnisse, Ziel- und Kategorieseite (n), Produktseite, Warenkorb, Kaufabwicklung, Bestellstatus und -rückgabe sowie Kontoprofil. Jeder würde in einem Diagramm unterschiedlich dargestellt.

Produktmenge als Abzeichen

Konsolidieren Sie für ein Ökosystem mit vielen Produkten das Symbol für viele und geben Sie die Menge mit einem Abzeichen an.

Produktannahmestatus als Farbe

Die Produktakzeptanz eines Systems ist unregelmäßig. Verwenden Sie daher Farbe, um den Status als Übernahme unter Verwendung des Systemcodes (schwarz) zu kennzeichnen, das Systemdesign in den maßgeschneiderten Code eines Produkts einzubetten (grau) oder das System überhaupt nicht zu übernehmen (weiß).

Diese können auch mit Abzeichen für die Menge konsolidiert werden.

Anschlüsse, Leitungen von oben nach unten

Vertikale Anschlüsse von oben nach unten stellen Produkte dar, die von den Systemen abhängen. Während Links-Rechts- und Radialanzeigen unterschiedliche Möglichkeiten bieten (insbesondere radiale „Schönheit“), verbessert die Ausrichtung von oben nach unten die visuelle Effizienz, verbessert das Verständnis und vereinfacht die Produktion und Wartung.

Die Linien drehen sich über abgerundete Winkel von 90 Grad. Gerade oder gebogene Anschlüsse überlappen sich und stehen in Konflikt mit anderen Anschlüssen und Objekten, wodurch die Präsentation chaotisch wird und es schwieriger wird, den Routen zu folgen.

Diese Diagramme stehen in engem Zusammenhang mit Abhängigkeitsdiagrammen, die Konnektoren mit einem Pfeil abschließen. Die Rückmeldungen deuteten jedoch nachdrücklich darauf hin, dass die vertikale Ausrichtung des Diagramms Richtungsabhängigkeit impliziert. "Pfeile machen das Diagramm unübersichtlich", versicherten meine Kollegen. Verlassen Sie sich daher auf die einfache, kontrastärmere Farbe einer Linie, um Objekte zu verbinden.

Markenidentitäten als Quadrate

Es ist manchmal amüsant zu sehen, wie Design-System-Profis überrascht sind, wenn sie daran erinnert werden, dass ihr System nicht die Spitze der Pyramide ist. Jedes (digitale) Designsystem, an dem ich gearbeitet habe, erbt visuelle Elemente - Farbe, Typografie, Illustration - und andere Eigenschaften von einer oder mehreren Markenidentitäten, die von einer Marke oder einem Marketingteam verwaltet werden. Marken werden als Quadrat dargestellt.

Mehrere Marken als Eltern eines Systems

Das Anzeigen von Marken ist nützlich, um viele Identitäten darzustellen, die von einem einzelnen System unterstützt werden. Beispielsweise enthielt ein Marriott-Designsystem Regeln für bestimmte Hotelobjekte wie Courtyard, Renaissance und JW Marriott.

Organisationsgrenzen als Spalten

Keine Architektur von Designsystemen im gesamten Unternehmen ist vollständig, ohne die Angabe der Organisationseinheit (en), die von jeder Organisationseinheit bedient werden. Dies können Domänen, Stämme und Trupps sein. Oder vielleicht Branchen. Oder Teile einer Kundenreise. Unabhängig davon, wie Ihr Unternehmen die Arbeit und die Teams aufteilt, hat es, wenn es eine Größenordnung hat, Abteilungen.

Ich habe mich dafür entschieden, violette Grenzen zu verwenden, die gestrichelt und dicker sind als Linien, die Knoten verbinden. Zusätzlich kennzeichnen ein- oder zweistufige violette Beschriftungen, die sich an der Grundlinie des Diagramms orientieren, jeden Bereich eindeutig.

Beispiele

Um das visuelle Vokabular in Aktion zu sehen, präsentiere ich eine Reihe von Beispielen, die durch beschreibende Geschichten unterstützt werden, um den Kontext festzulegen und die Herausforderungen aufzuzeigen, denen sich das betreffende System (die betreffenden Systeme) gegenübersieht.

Beispiel: Ein zentrales System mit Vermittlern

Diese Entwurfssystemarchitektur bezeichnet ein anerkanntes, einzelnes System, von dem alle digitalen Produkte abhängen. Einige Produkte übernehmen das System direkt. In anderen Fällen wird das System von Teams vermittelt, die React- und Vue-basierte JavaScript-Übersetzungen ihrer Vanilla-HTML- und CSS-Bibliothek anbieten.

Das Design-System-Team erkannte die Redundanz und Komplexität der Architektur und führte die nächste Generation von Arbeiten an, um Webkomponenten anzubieten, die den Bedarf an solchen Übersetzungen verringern.

Beispiel: Kleine Banken und Versicherungen

Viele Versicherungsunternehmen und Banken organisieren digitale Produktteams, während der Trichter vom .com-Marketing über Verkaufstrichter, die Kunden akquirieren, bis hin zu Serviceleistungen für die Verwaltung von Transaktionen, z. B. Schaden- und Geldtransfers, fließt. Dies kann zu mindestens zwei Entwurfssystemen führen, die mindestens .com aufteilen und warten, wenn nicht sogar zu einem dritten System für Flows, die Kunden in dem gespaltenen Zwischenraum gewinnen.

Beispiel: Software-as-a-Service (Ausbildung)

Betrachten Sie ein Software-Portfolio unter dem Dach eines Mutterunternehmens. Ihr System entstand durch eine Neugestaltung ihres Flaggschiff-Angebots: Inhalte und interaktive Medien als Lehrplan.

Nach der Einführung der Flaggschiffe verwendeten die Teams das System für produktübergreifende Tools (Authentifizierung, Startseite, Dashboards, Suche und Kontoverwaltung) und Verwaltungskonsolen, auf denen die Pädagogen die Daten und den Zugriff der Schüler verwalteten. Mit wachsendem Erfolg begannen sie, nach einer Geschwistereinheit Ausschau zu halten, die maßgeschneiderte Websites mit weißen Etiketten für Kunden produzierte.

Beispiel: Geschäftsbereiche nach Kundentyp

Ein Unternehmen organisierte digitale Teams in Produktentwicklungseinheiten, die Verbraucher, Arbeitgeber und deren Mitarbeiter sowie große Institutionen in ihrem Bereich separat betreuten. Infolgedessen entstanden in jeder Einheit unterschiedliche Systeme.

Die Systemteams teilten Vorgehensweisen und Tools, blieben jedoch autonom, um unterschiedliche Kunden optimal zu bedienen. Auf diese Weise konnten Herausforderungen vermieden werden, z. B. die vorzeitige Konvergenz einer noch nicht prioritären Designsprache.

Beispiel: Software-as-a-Service (Enterprise)

Ein Softwareunternehmen hat ein starkes zentralisiertes System eingerichtet, das auf alle Flaggschiff- und Sekundärprodukte angewendet wird. Abgesehen von den universell angewendeten codierten Komponenten wurde eine separate Erfahrung in der Designdokumentation beibehalten. Einige Schlüsselprodukte erweiterten das System, ob Designer von Produkten A & B, die Sketch-Bibliotheken verwalten, oder eine Ingenieurin, die den Komponentencode für ihre Teams verwaltet. Darüber hinaus wird eine potenzielle Akquisition eine Diskussion über die Integration auf Produkt-, System- und Markenebene auslösen.

Sie können die hier gezeigte Skizzendatei mit Symbolen und Beispielen herunterladen.