Benötigte Komponenten aus zwei Produktansichten ableiten

Ein Designsystem wird leichter nutzbar, wenn sein erster Umfang aus echten Oberflächenaufgaben entsteht. Starten Sie deshalb mit Ansichten, die das Produkt tatsächlich benötigt. Eine lange Liste möglicher Komponenten sagt noch wenig darüber aus, welche Varianten Ihr Team einsetzen soll.

Zwei Ansichten mit ihren Aufgaben erfassen

Als ausgearbeitetes Beispiel dient ein fiktives Kundenportal. In der Projektübersicht sollen Auftraggeber ein Projekt erkennen und öffnen. In der Detailansicht sollen sie dessen Status lesen und freigegebene Dokumente herunterladen. Beide Ansichten gehören zum selben Produkt, erfüllen aber unterschiedliche Aufgaben.

Notieren Sie pro sichtbarem Element Zweck, Inhalt und mögliche Zustände. Ein ähnlicher Rahmen reicht nicht als Begründung für eine gemeinsame Komponente. Wichtig ist, ob auch Bedeutung und Verhalten übereinstimmen.

Gemeinsamen Kern und eigene Zusammensetzung entscheiden

Projektkarte und Dateizeile können kleine Grundbausteine teilen. Sie müssen deshalb nicht dieselbe große Komponente werden. Eine Ausnahme ist sinnvoll, wenn eine gemeinsame Variante die jeweilige Aufgabe unnötig verschleiert.

Einen Bibliothekseintrag konkret ausfüllen

Für die Statusanzeige hält das Beispiel fest: Einsatz in beiden Projektansichten; Statuswort aus den Projektdaten; Farbe nur als zusätzliche Darstellung; keine eigene Klickaktion. Offene Punkte sind die benötigten Statuswerte und der Umgang mit langen Übersetzungen. Diese Entscheidungen müssen vor der Umsetzung geklärt werden, statt durch beliebige Beispielwerte zu verschwinden.

Carbon beschreibt Komponenten als gestaltete und programmierte Lösungen für konkrete Oberflächenaufgaben. Verwenden Sie diese Perspektive auch bei der Auswahl: Dokumentieren Sie Zweck, Varianten und Grenzen eines Bausteins gemeinsam. Ein vorhandener Name in einer Bibliothek genügt nicht als Einsatzregel.

Den ersten Umfang an beiden Ansichten prüfen

Setzen Sie die ausgewählten Bausteine zunächst in beide Entwürfe ein. Prüfen Sie typische Inhalte und lange Übersetzungen; bei interaktiven Teilen auch Tastaturbedienung und Zustandswechsel. Halten Sie fest, welche Version verwendet wird und welche Abweichung bewusst bestehen bleibt. Das Beispiel liefert dafür einen Arbeitsstand, keine bereits implementierte Bibliothek. Der nächste Schritt ist eine überschaubare Auswahl mit geklärten offenen Punkten, die das Team anschließend umsetzen und prüfen kann.

Quellen

• Carbon: Components Overview