Atomic Design: Grundlage eines Design Systems
Im Jahr 2013 schrieb Brad Frost, dass Atomic Design nicht als ein absoluter und linearer Prozess, sondern als ein mentales Modell anzusehen ist. Dies soll helfen, eine Benutzeroberfläche als ein Ganzes und auch als einzelne Kleinteile zu betrachten. Das ist der Grund, warum wir das Modell in unseren anspruchsvollen Projekten immer als Grundlage nehmen und an die Projektanforderungen anpassen.
Erweiterung des ursprünglichen Konzepts
Über die ursprüngliche Grundlage (2013) von Atomic Design haben wir bereits gesprochen und alle dazu benötigten Informationen kannst du unter diesem Link finden: Atomic Design 1/2.
Das ständige Wachstum der digitalen Produkte trägt neue Voraussetzungen in deren Entwicklung mit sich. Immer mehr Unternehmen neigen dazu, parallel zu einem Produkt ein Design System zu entwickeln. Dies ermöglicht einen nachhaltigen Umgang mit einem sich konstant entfaltenden Produkt oder einer schnellen Erweiterung von Applikationen in einer Produktpalette.
Im Jahr 2019 reflektiert Brad Frost sein im Jahr 2013 veröffentlichtes Konzept und zeigt Konzepte auf, welche das Atomic Design nach jeweils bestimmten Anforderungen erweitern, um die visuelle und semantische Sprachen des Design Systems zu unterstützen. Das passiert mithilfe von Design Tokens, welche die unabhängige Konsistenz von Designelementen ermöglichen. Nun gehören die Design Tokens zu einem würdigen Teil der Atomic Design Methodik. Sie werden als "Ions" bezeichnet und gelten als die kleinste Einheit des User Interfaces.
Andererseits hat unsere Anforderung, die Bestandteile des Design Systems auf verschiedenen Plattformen oder Produktlinien zu nutzen, die Atomic Design Methodik zusätzlich in die rechte Richtung (siehe Bild unten) erweitert. So haben wir beschlossen, dass die größte Einheit des Systems eine Produktlinie oder ein bestimmtes Betriebssystem (z. B. iOS) sein kann. Diese bezeichnen wir als "Products" und platzieren sie am Ende des Atomic Design Modells.
Warum nutzen wir den Ansatz von Atomic Design?
Bequemlichkeit
Durch die Erstellung komplexer Komponenten aus einfacheren Komponenten ermöglicht das Atomic Design eine problemlose Anpassung selbst kleinster Elemente ohne großen Zeitaufwand. Musst du abgerundete Ecken des Buttons ändern? Wende sie einmal auf die Hauptkomponente an und siehe, wie sich diese Änderung auf alle anderen Instanzen in der Bibliothek auswirkt.
Konsistenz
Durch die Festlegung eines spezifischen Verhaltens- und Erscheinungsbildes für jedes Element eines Produkts verhindert das Atomic Design, dass einzelne Muster falsch genutzt und die Ästhetik oder Benutzerfreundlichkeit beeinträchtigt werden.
Einfachheit
Je einfacher das Design-System zu verarbeiten ist, desto häufiger wird es verwendet. Die aus „atomaren“ Gruppen anpassbare und austauschbare Komponentenbibliothek ist einfach zu warten, zu skalieren und anzupassen.
Wann nutzen wir den Ansatz von Atomic Design?
Wenn ein neues Produkt entwickelt wird: Der Ansatz von Atomic Design macht besonders dann Sinn, wenn wir komplexere Design-Systeme für Produkte entwickeln, die Discovery-Phase abgeschlossen haben und bereit für die Weiterentwicklung sind. Während der Discovery-Phase werden dich Sorgen um die Konsistenz des Designs nur bremsen. Ein guter Zeitpunkt um mit dem Aufbau eines Design Systems, und entsprechend mit dem Atomic Design Ansatz anzufangen, ist dann, wenn die ersten Wireframes entstehen und die visuelle Sprache des Produkts mit den Stakeholdern abgestimmt ist.
Wenn der Unternehmenswachstum geplant ist: Für Kunden, die beschlossen haben, bestehende Produkte an neue Technologien anzupassen und/oder eine neue Produktlinie zu entwickeln, spielt die Langlebigkeit eines Design-Systems eine große Rolle. Diese kann man mit dem Atomic Design Ansatz sehr gut realisieren. Hiermit wird das Wachstum durch wiederverwendbare Elemente stark gefördert.
Wie bauen wir unser UI mit dem Atomic Design-Ansatz?
Wie schon oben erwähnt, entscheiden wir in erster Linie im Team, ob ein Design-System mit Atomic Design-Ansatz uns überhaupt helfen kann, unsere Ziele im Projekt zu erreichen. Wenn das der Fall ist, dann kannst du nach folgenden Prinzipien weiter arbeiten:
Aufbau
Zuerst wird der Aufbau vom Design-System definiert. Hier beantworten wir die Fragen: Wie nutzen wir den Atomic Design-Ansatz? Wie wollen wir die einzelnen Bestandteile des Ansatzes benennen? Wollen wir mit Tokens oder ohne Tokens arbeiten? Solche Entscheidungen treffen wir gemeinsam im Team. Jede Kompetenz und Meinung ist wichtig und jeder soll verstehen, wie das System aufgebaut und genutzt wird. Hier geht es nicht nur um das UI Design, sondern auch um verschiedene Mittel für das Implementieren des Design-Systems, weshalb es wichtig ist, solche Entscheidungen zusammen mit Entwicklern zu treffen.
Lasst uns zusammen alle Teile eines Design Systems anschauen:
Prinzipien
Prinzipien definieren den Zweck und den Wert des Design-Systems deines Unternehmens. Sie erklären die Entscheidungsfindung und bestimmen, wie das Team das Design-System nutzen und weiterentwickeln kann.
Accessibility
Unter Accessibility versteht man das Konzept, wie ein Produkt oder eine Dienstleistung von jedem genutzt werden kann. Deshalb sollten Designer versuchen, alle potenziellen Nutzer in verschiedenen Nutzungskontexten zu berücksichtigen. Dies bringt deutliche Vorteile mit sich – vor allem aber bessere Designs für alle. Hier definieren wir, welche Gesetze zu berücksichtigen sind und inwieweit unser System basierend auf Nutzeranforderungen barrierefrei sein soll.
Content Strategy
So wie Produkte einheitlich aussehen und wirken sollten, sollten sie auch einheitlich sprechen. Wir versuchen übergreifend eine bestimmte Stimme zu nutzen und immer im gleichen Ton mit dem Nutzer zu reden. Zu diesem Teil gehört auch die Grammatik und das Vokabular. Jeder Nutzer des Produkts soll fachliche Begrifflichkeiten wiedererkennen, um das Produkt richtig nutzen zu können.
Design Tokens
Design Tokens sind alle Werte, die zum Aufbau und zur Pflege eines Design-Systems erforderlich sind – Abstand, Farbe, Typografie, Objektstile, Animation usw. – und die als Daten dargestellt werden. Sie werden anstelle von fest kodierten Werten verwendet, um Flexibilität und Einheitlichkeit über alle Produkterlebnisse hinweg sicherzustellen.
Design Tokens sind direkt in unsere Komponentenbibliothek integriert. Sie decken die verschiedenen Optionen von Komponentenzuständen und weitere ab.
Primitives und Business Components
Ein Primitive ist eine grundlegende Komponente, aus der man kompliziertere Komponenten, Muster oder Module erstellen kann. Ein Primitive kann nicht alleine verwendet werden und enthält keine Geschäftslogik.
Business Components umfassen Geschäftslogik und werden mit Geschäftsdaten gefüllt.
Patterns
Patterns sind Best Practice-Lösungen dafür, wie ein Benutzer sein Ziel erreicht. Sie zeigen wiederverwendbare Kombinationen von Komponenten und Vorlagen, die auf die häufigsten Use Cases zugeschnitten sind.
Modul
Jedes Modul trägt eine spezifische Funktion der Produkt- und Geschäftslogik in sich. Alle Module können auf Wunsch des Stakeholders ausgetauscht und weggelassen werden.
Templates
Ein Template ist eine Sammlung von verschiedenen Modulen, die thematisch zueinander passen. Die Templates können von potenziellen Nutzern des Systems verwendet werden, um schnell benötigte Views zu erstellen. Module in einem Template können entfernt, hinzugefügt oder getauscht werden.
Dokumentation
Als nächstes wird entschieden, ob die Design-System-Dokumentation stattfinden soll. In welcher Sprache und in welchem Tool ist sie am relevantesten zu erstellen? Dies ist meistens von dem Produktteam und der Produktart abhängig. Solche Themen sollen auf jeden Fall so früh wie möglich abgeklärt sein. Ansonsten besteht die Gefahr, dass wichtige Entscheidungen verloren gehen oder irreversible Prozesse in Gang gesetzt werden.
Konsistenz in Dateien
Die Struktur des abgestimmten Design-System-Aufbaus wird in das Design- und Dokumentationstool übertragen. Dies ermöglicht eine Konsistenz in allem, was wir bauen und alle Beteiligten können sich ganz gut innerhalb der Dateien orientieren.
Nun bist du bereit dich mit dem Design von Tokens, Komponenten oder Patterns zu beschäftigen, um deinen Kunden ein gutes und nachhaltiges Design-System zu gewährleisten.
Fazit
Nicht alle Projekte sollen mit dem Atomic Design-Ansatz gebaut werden. Besprich erst im Team, ob der Ansatz überhaupt etwas zum Erreichen des Projektziels beitragen kann. In einem MVP Projekt, wo der Fokus stark auf dem Testen der Ideen und der Evaluation liegt, ist es vielleicht produktiver ein UI Kit zu bauen. Ein UI Kit kann dir im Vergleich zu einem Design-System viel Zeit ersparen. Wenn es aber den Bedarf nach einem vollständigen Design-System gibt, empfehlen wir es, dem Ansatz zu folgen und ihn nach Produktbedürfnissen zu erweitern.
Dabei ist wichtig zu verstehen, dass jedes Produkt einzigartig ist und eine einzigartige Lösung anbieten soll.