Über uns

Die Initialzündung
Die Hoffnung war, KI würde Silos abbauen. Jetzt haben wir neben Figma und Code noch weitere: Die Prototypen-Silos.

Solche und ähnliche Sätze hörten wir in den vergangenen Jahren immer öfter. Denn der Einzug von KI hat vieles beschleunigt – aber Design-Prozesse nicht vereinfacht.

Ein Beispiel: Das Prototyping explodiert. In Unternehmen werden über das Designteam hinaus, über alle Abteilungen hinweg, immer mehr funktionale Prototypen erstellt. Und weil so schnell so viel Überzeugendes entsteht, wachsen die Begehrlichkeiten in der Umsetzung. „Das ist doch quasi schon fertig.“ So landen immer mehr Tasks beim Designteam – das dadurch noch stärker zum Engpass wird. Denn jetzt gibt es drei Design-Wahrheiten, die auseinanderdriften: Figma, Code und diverse Prototypen.

Diese Entwicklung kann KI nicht lösen – Prozesse verbessern können nur Menschen. Die Antwort auf den Wildwuchs ist kein Vibe-Coding-Verbot, sondern eine geteilte, versionierte Design-Grundlage: ein Designsystem als Ressource.

Gerade weil die Fachbereiche heute so viel selbst prototypen können, braucht es etwas, das alles wieder verbindet – kein weiteres Werkzeug, sondern ein gemeinsames Fundament. Genau das war die Initialzündung für Componiq.

Das Kern-Team

Systemdenken trifft Problemdenken.

Porträt von Sascha Rinaldi
Design System Engineering

Sascha Rinaldi

Kennt Corporate-Scrum-Teams von innen und die wiederkehrenden Reibungspunkte eingebundener Design-Teams. Getrennte Tool-Welten erzeugen getrennte Sprachkulturen – und genau dort, an der Naht zwischen Design und Code, brechen Handover-Prozesse.

Die Erkenntnis: Ein besseres Designsystem ist selten das eigentliche Problem. Meistens scheitert es an den Abstimmungsprozessen zwischen Fachabteilungen, Design und Entwicklung. Ob ein System trägt, entscheidet sich nicht an der Oberfläche, sondern in der Struktur.

Porträt von Christian Wiener
Product / CX

Christian Wiener

Stellt zuerst die unbequeme Frage: Welches Problem lohnt es überhaupt zu lösen? Das Wissen kommt aus Dutzenden Enterprise-Projekten und drei eigenen Gründungen – woran komplexe Produktentwicklung gelingt, und woran sie scheitert.

Der Ansatz: im Kontakt mit echten Nutzern bleiben und immer wieder validieren. So fallen Designsystem-Entscheidungen dort, wo sie strategisch werden: zwischen Nutzerbedarf, Organisation und Technologie.

Die zwei Ebenen der Transformation
Bisher war ein Designsystem Sache des Designteams. Jetzt ist es Sache der ganzen Organisation.

Auf der einen Ebene geht es um Handwerk: wie genau Tokens strukturiert werden, welche Architektur tragfähig ist, wie Komponenten, Themes und Distribution ineinandergreifen. Das ist präzise, technische Arbeit – und ohne sie bleibt jedes Designsystem ein Versprechen ohne Substanz.

Aber ein Designsystem, das nur technisch sauber ist, scheitert trotzdem. Es liegt dann gepflegt im Repository, während die Organisation drumherum weiterarbeitet wie zuvor – mit denselben Abstimmungswegen, denselben Silos, denselben Brüchen zwischen Design und Code.

Denn auf der anderen Ebene geht es um Wandel: darum, wie Teams Entscheidungen treffen, wie Wissen geteilt wird, wer was wann beiträgt. Ein Designsystem verändert, wie eine Organisation arbeitet – ob sie das will oder nicht. Es ist immer auch ein digitaler Transformationsprozess.

Wer nur die Technik sieht, baut ein System, das niemand nutzt. Wer nur die Transformation sieht, redet über Prozesse, ohne dass je etwas Tragfähiges entsteht. Beides gehört zusammen – und genau an dieser Naht arbeiten wir. Nicht das eine vor dem anderen, sondern beides als dasselbe Projekt.

Reden wir über
Transformation.