Designsystem Audit

Da wo es weh tut

Bevor ein Designsystem refactoriert, skaliert oder übergeben werden kann, braucht es eine ehrliche Bestandsaufnahme. Wir prüfen Token-Reife, Komponentenabdeckung, Governance und Barrierefreiheit — und legen offen, wo das System trägt, wo es Geld kostet und wo es Sie blockiert. Ergebnis ist kein Bericht zur Ablage, sondern eine priorisierte Liste, mit der Sie weiterarbeiten können.

Arbeitspakete

Bestandsaufnahme

Token-Inventur, Komponenten-Katalog, Dependency-Graph. Was ist tatsächlich da, was wird wirklich verwendet, und welche Versionen leben parallel im Repo.

Gap-Analyse

API-Brüche zwischen Design und Code, undokumentierte Komponenten, Vendor-Risiken im Stack. Wir messen Reife pro Bereich statt eine Gesamtnote zu vergeben.

Bewertung

Jedes Findings bekommt Aufwand, Wirkung und Risiko. Priorisierung nach Hebel, nicht nach Lieblingsthemen. Ergebnis ist eine sortierte Liste, keine Punktwolke.

Empfehlung

Konkreter nächster Schritt mit Budgetrahmen — Quick Win, mittelfristiger Umbau oder Neuaufbau. Klare Ja/Nein-Empfehlungen statt 80-Seiten-Report.

Fragen

Fragen, die ein Audit beantwortet.

  • Token-Coverage

    Welche Tokens leben tatsächlich im Code — und welche nur in Figma?

  • Komponenten-Reife

    Wie weit decken Ihre Komponenten reale Produkt-Flows ab, ohne dass Teams forken?

  • API-Stabilität

    Was bricht, wenn Sie die Token-Schicht minor-bumpen — und wer würde es merken?

  • Doku-Lücken

    An welchen Stellen greifen Teams am Designsystem vorbei, weil die Doku fehlt?

  • Vendor-Risiken

    Welche externen Abhängigkeiten würden Sie bei einem Audit nicht erklären können?

  • Accessibility

    Welche Ihrer Komponenten würden eine BFSG-Prüfung heute bestehen?

Reden wir über
Ihren Audit-Bedarf.