Vor zwei bis drei Jahren haben wir damit begonnen, für einen unserer langjährigen Kunden ein Designsystem von Grund auf neu zu entwickeln — ein System, das Designinkonsistenzen reduziert, über mehrere Produkte hinweg skaliert und die Lücke zwischen Design und Entwicklung verringert. Wir haben aus erster Hand gesehen, wie viel schneller Projekte wann voranschreiten es gibt ein richtiges Designsystem.

Wir begannen mit dem Aufbau des Fundaments — der Erstellung von Abstandsskalen, benutzerdefinierten Primitiven, Typografie, Semantik und einer Reihe von maßgeschneiderten Komponenten. Es war ein guter Anfang, aber es wurde schnell klar, dass das Projekt ständig gewartet werden muss und viel mehr Zeit in Anspruch nehmen würde, als wir dafür aufwenden wollten. Also mussten wir unseren Prozess überarbeiten

In diesem Jahr haben wir uns für einen anderen Ansatz entschieden und ein ausgereiftes, vorgefertigtes Komponentenkit gekauft. Es enthielt eine vollständige Komponentenbibliothek, integrierte Barrierefreiheit, ein Token-System und das Figma UI Kit, mit dem wir das Design und die Entwicklung einfacher machen konnten.

Es schien das Beste aus beiden Welten zu sein, bis wir anfingen, es genauer zu prüfen.

‍

Was hat nicht funktioniert

Für die Entwicklung sah es recht einfach zu bedienen und zu warten aus, aber die Das Designteam hatte Mühe, sich anzupassen das UI-Kit, das unseren Bedürfnissen entspricht und das Erscheinungsbild unserer Kunden widerspiegelt. Vor allem das Token-System wurde zu einem Problem.

Wir haben mit den Stützpunkten gekämpft:

• Nichtübereinstimmende Token-Benennungskonvention und Fehlen einer guten semantischen Struktur
• Keine einfache Möglichkeit, zusätzliche Token-Sets hinzuzufügen
• Anpassungsrisiken — Updates könnten unsere Overrides leicht kaputt machen
• Keine native Unterstützung mehrerer Marken und Themen

‍

Wir hatten die Möglichkeit, uns anzupassen und Kompromisse einzugehen, vielleicht Teile der Marke fallen zu lassen oder an das System anzupassen, aber Etwas zu liefern, das „fast der Marke entspricht“, fühlte sich nicht wie der richtige Ansatz an.

‍

Anderer Ansatz: benutzerdefinierte Token, vorgefertigte Komponenten

Anstatt zur gesamten benutzerdefinierten Lösung zurückzukehren, haben wir beschlossen, sie in zwei Teile zu teilen.

Wir sind Beibehaltung der vorgefertigten Komponenten, sie waren solide und zugänglich, und Ersetzen der Token-Ebene durch unsere eigene. Das bedeutete, unser Token-System neu aufzubauen und es den Komponenten neu zuzuordnen.

‍

Wir haben uns auf Folgendes konzentriert:

• Maßgeschneiderte primitive Farbe
• Semantische Tokens
• Klare und konsistente Benennung
• Leicht verständliche Token-Struktur, die in Zukunft skaliert werden kann

‍

Wir glauben, dass uns dieser hybride Ansatz die Flexibilität bietet, die wir benötigen, um ein System bereitzustellen, das sowohl skalierbar als auch wirklich markengerecht ist — ohne auf alle Vorteile einer ausgereiften Komponentenbibliothek verzichten zu müssen.

Es gibt noch viel zu tun und wir sind noch nicht fertig. Aber sobald wir es vollständig eingeführt haben, können wir ein Follow-up mit den Ergebnissen veröffentlichen, was funktioniert hat, was wir ändern würden und welche Auswirkungen das auf Skalierbarkeit, Teamtempo, Konsistenz zwischen den Produkten hatte und vor allem, wie viel Wartungszeit wir eingespart haben.

Wenn Sie gerade dabei sind, Design-Workflows herauszufinden oder einfach nur versuchen, Ihr Team reibungsloser zu gestalten, sollten Sie sich Folgendes ansehen wie man einen Designer effizient in ein Produktteam einbaut, der Unterschied zwischen Mentoring und Coaching in Designteams, oder was ist ein UX-Audit und wann es sich lohnt, einen zu machen. Könnte ein paar nützliche Sachen drin sein, je nachdem, woran du gerade arbeitest.