Design Systems · · 6 Min. Lesezeit
Design Systems für Deep-Tech-Produkte: eine Sprache von der Konsole bis zu den Firmware-Werkzeugen
Deep-Tech-Produkte umfassen Web-Konsolen, Kommandozeilenwerkzeuge, Dokumentation und Hardware. Warum sie ein Design System mehr brauchen als andere, und wie man eines baut, das Ingenieure nutzen.
Wer an Design Systems denkt, denkt an Consumer-Apps: Buttons, Farben, eine Komponentenbibliothek in Figma und im Code.
Deep-Tech-Produkte brauchen Design Systems mehr, nicht weniger. Nur eine andere Art.
Ein Security- oder Industrieprodukt ist selten eine einzige Oberfläche. Es ist eine Web-Konsole, ein Kommandozeilenwerkzeug, eine API, Dokumentation, Berichte für Auditoren, manchmal ein kleines Display am Gerät. Jeden Teil bauen andere Teams, oft mit anderen Werkzeugen. Ohne gemeinsame Sprache hat derselbe Begriff am Ende fünf Namen und drei Farben.
Was im Deep Tech anders ist
Das Vokabular ist das System. Bei Consumer-Produkten ist Konsistenz vor allem visuell. Im Deep Tech ist die größte Quelle der Verwirrung die Sprache. Ist es ein „Gerät“, ein „Asset“, ein „Knoten“ oder ein „Endpunkt“? Ist ein Befund „kritisch“, „hoch“ oder „schwer“? Sich auf Begriffe zu einigen und sie in Konsole, CLI, API und Doku durchzusetzen, ist hier die wertvollste Arbeit eines Design Systems.
Zustände tragen Risiko. Statusfarben und -bezeichnungen sind keine Dekoration. Menschen handeln danach. Sie müssen überall einheitlich sein, dürfen sich nie allein auf Farbe stützen, und ihre Bedeutung gehört so präzise dokumentiert wie eine API.
Ingenieure sind die Hauptbeitragenden. Viele Oberflächen im Deep Tech bauen Ingenieure ohne Designer im Raum. Das Design System muss für sie funktionieren: klare Regeln, gute Voreinstellungen, Komponenten, die leicht richtig und schwer falsch zu benutzen sind.
Datendichte ist real. Fachleute brauchen dichte Tabellen, Logs und Diagramme. Ein Design System für luftige Marketingseiten hilft ihnen nicht. Es braucht Muster für Dichte, die lesbar bleiben.
Wie ich eines bauen würde
1. Mit dem Glossar beginnen. Vor den Komponenten die Domänenobjekte, ihre Zustände und ihre Namen festlegen. Ins Repository, neben den Code, wo Ingenieure es sehen.
2. Semantische Tokens verwenden. Tokens nach Bedeutung benennen, nicht nach Wert: „status-critical“, nicht „red-600“. Nur so bleibt die Konsistenz zwischen Web-Konsole, Terminal-Farbschema und gedrucktem Bericht erhalten. Mehr dazu in Semantische Tokens.
3. Auch nicht-visuelle Oberflächen abdecken. Fehlermeldungen, CLI-Ausgabeformate, Log-Level, Berichtsvorlagen und API-Fehlercodes gehören zur Erfahrung. Geben Sie auch ihnen Regeln.
4. Barrierefreiheit einbauen. Kontrast, Tastaturbedienung, Fokuszustände und Textalternativen gehören in die Komponenten selbst, damit jedes Team sie automatisch bekommt. Siehe Barrierefreiheit in Security-Werkzeugen.
5. Klein halten und durchsetzen. Ein kurzes System, das überall genutzt wird, schlägt ein großes, das nirgends genutzt wird. Lint-Regeln, Checklisten für Code-Reviews und Vorlagen bewirken mehr als eine schöne Dokumentationsseite.
Warum es fürs Geschäft zählt
Konsistenz im Deep Tech dient nicht dem polierten Eindruck. Sie reduziert Fehler, verkürzt die Einarbeitung neuer Kunden und neuer Ingenieure und macht das Produkt leichter prüfbar und vertrauenswürdiger.
Wie ich in Das Design System ist tot. Lang lebe das Design System geschrieben habe: Die Werkzeuge ändern sich jedes Jahr. Der Bedarf an einer gemeinsamen Sprache nicht. In komplexen technischen Produkten ist dieser Bedarf nur offensichtlicher.