Refactoring der Button-Komponente
Ein Blick hinter die Kulissen: Wie ich die Button-Komponenten von Edifire UI durch parametrische Logik, Slot-basiertes Design und Figma-Properties von 432 Varianten auf nur noch 32 reduziert habe. Diese Case Study zeigt das Konzept, die Tools und die Cleanup-Strategie hinter einem skalierbaren, Token-basierten System u2013 solo entwickelt und bereit fu00fcr Open Source.
Überblick
Überblick
Edifire UI ist ein persönliches, Token-basiertes Design-System. Von mir allein entwickelt, mit einem klaren Ziel: komplett Open-Source zu werden. Der Button – ohne Zweifel das meistgenutzte Element in jedem UI-Kit – war einer der ersten Bausteine, an die ich mich gewagt habe. Mein Anspruch damals: an absolut alles denken. Das Ergebnis? Ein Berg von 432 Varianten. Verschiedene Status, Größen, Farben, Icons, Hierarchien und Themes. Was als Liebe zum Detail begann, wurde schnell zur reinsten Maintenance-Hölle. So wurde der Button zum perfekten Testfall für einen neuen, disziplinierten und skalierbaren Ansatz.
Wie ich meine Button-Varianten in meinem Solo Design System (Edifire UI) von 432 auf 32 reduziert habe
Als ich anfing, Edifire zu entwickeln – ein eigenes Design System, von Grund auf konzipiert mit dem Ziel, Open Source zu werden –, dachte ich, ich wäre gründlich. Sogar besonders clever. Denn was ist schon ein Design System ohne eine Button-Komponente, die jeden erdenklichen Sonderfall und jeden visuellen Wunsch abdeckt?
Ich erstellte Status für Hover, Focus, Disabled und Loading. Ich berücksichtigte verschiedene Größen, Icon-Platzierungen, Tonalitäten und Hierarchien nach Wichtigkeit.
Anfangs wirkte es überschaubar: ein simpler Frame mit einem Label. Vielleicht ein Icon. Vielleicht zwei. Dann kamen die Größen. Die Farben. Die Status. Die Icon-Ausrichtungen. Die Theme Modes. Ehe ich mich versah, hatte sich mein ordentliches Komponenten-Panel in ein unübersichtliches Chaos aus 432 Button-Varianten verwandelt.
Es war das absolute Chaos … aber es war mein Chaos.
Wie ich meine Button-Varianten in meinem Solo Design System (Edifire UI) von 432 auf 32 reduziert habe
Als ich anfing, Edifire zu entwickeln – ein eigenes Design System, von Grund auf konzipiert mit dem Ziel, Open Source zu werden –, dachte ich, ich wäre gründlich. Sogar besonders clever. Denn was ist schon ein Design System ohne eine Button-Komponente, die jeden erdenklichen Sonderfall und jeden visuellen Wunsch abdeckt?
Ich erstellte Status für Hover, Focus, Disabled und Loading. Ich berücksichtigte verschiedene Größen, Icon-Platzierungen, Tonalitäten und Hierarchien nach Wichtigkeit.
Anfangs wirkte es überschaubar: ein simpler Frame mit einem Label. Vielleicht ein Icon. Vielleicht zwei. Dann kamen die Größen. Die Farben. Die Status. Die Icon-Ausrichtungen. Die Theme Modes. Ehe ich mich versah, hatte sich mein ordentliches Komponenten-Panel in ein unübersichtliches Chaos aus 432 Button-Varianten verwandelt.
Es war das absolute Chaos … aber es war mein Chaos.
Der Ausgangspunkt
Edifire UI begann als persönliches Projekt. Ich wollte ein skalierbares, visuell ausgewogenes Design-System bauen, das ich für eigene Nebenprojekte nutzen und später veröffentlichen kann. Mein Ziel: minimalistisch, flexibel und voll tokenisiert.
Der Button ist das am häufigsten genutzte Element in jedem UI-Kit – also ging ich ihn als Erstes an. Mein Ansatz: „Bedenke einfach alles.“ Und genau das habe ich getan. Ich habe es völlig übertrieben.
Der Knackpunkt: Wenn Flexibilität zur Last wird
Es war kein optischer Fehler. Nichts war kaputt, verschoben oder technisch falsch. Aber irgendetwas fühlte sich schwerfällig an. Mein Konstrukt war total aufgebläht.
Es gab keine Fehlermeldungen, der Button funktionierte einwandfrei. Was mich stresste, war die mentale Last bei der Nutzung. Ich hatte unbewusst eines der häufigsten, aber am seltensten besprochenen Probleme in Design-Systemen geschaffen: den Varianten-Overload.
In Figma artete das Komponenten-Panel in endlose Scrollerrei aus. Jedes Mal, wenn ich einen einfachen Button brauchte, versank ich in verschachtelten Menüs und komplizierten Varianten-Namen. Als ob Sie einen Kaffee bestellen wollen und eine Karte mit über 400 Kombinationen vorgesetzt bekommen.
Figma kam damit klar – ich nicht. Die Erkenntnis daraus? Komponenten-Overload ist der stille Killer in vielen Design-Systemen.
Die Inspiration
Ich stieß auf einen Vortrag des Uber-Design-System-Teams. Sie erklärten, wie sie ihr Badge-Element von dutzenden starren Varianten auf wenige hochdynamische Konfigurationen reduzierten – durch den Wechsel zu einem parametrischen Design-Modell.
Ihr Badge konnte jede Form, Farbe oder jeden Status annehmen, ohne die Variantenliste aufzublähen. Es nutzte nur wenige Props wie tone, size, icon und message, gesteuert durch Tokens und kontextabhängige Logik. Einfach, intelligent und skalierbar.
Das blieb hängen.
Als ich meinen eigenen Button betrachtete, sah ich ihn plötzlich nicht mehr als starre visuelle Option, sondern als parametrisches System. Dieser Perspektivenwechsel – weg vom Aussehen, hin zum Verhalten – veränderte alles.
Inspiriert von Ubers „Parametric Components“-Ansatz
Hier anschauen: https://youtu.be/-z9JX8Lz5lI?si=9l5XZCbpWZF0OQee
In diesem Talk zeigt Uber, wie sie das Badge-Element reduzierten, indem sie von Permutationen auf parametrische Steuerungen über Tokens und Props umstellten.
Der Ausgangspunkt
Edifire UI begann als persönliches Projekt. Ich wollte ein skalierbares, visuell ausgewogenes Design-System bauen, das ich für eigene Nebenprojekte nutzen und später veröffentlichen kann. Mein Ziel: minimalistisch, flexibel und voll tokenisiert.
Der Button ist das am häufigsten genutzte Element in jedem UI-Kit – also ging ich ihn als Erstes an. Mein Ansatz: „Bedenke einfach alles.“ Und genau das habe ich getan. Ich habe es völlig übertrieben.
Der Knackpunkt: Wenn Flexibilität zur Last wird
Es war kein optischer Fehler. Nichts war kaputt, verschoben oder technisch falsch. Aber irgendetwas fühlte sich schwerfällig an. Mein Konstrukt war total aufgebläht.
Es gab keine Fehlermeldungen, der Button funktionierte einwandfrei. Was mich stresste, war die mentale Last bei der Nutzung. Ich hatte unbewusst eines der häufigsten, aber am seltensten besprochenen Probleme in Design-Systemen geschaffen: den Varianten-Overload.
In Figma artete das Komponenten-Panel in endlose Scrollerrei aus. Jedes Mal, wenn ich einen einfachen Button brauchte, versank ich in verschachtelten Menüs und komplizierten Varianten-Namen. Als ob Sie einen Kaffee bestellen wollen und eine Karte mit über 400 Kombinationen vorgesetzt bekommen.
Figma kam damit klar – ich nicht. Die Erkenntnis daraus? Komponenten-Overload ist der stille Killer in vielen Design-Systemen.
Die Inspiration
Ich stieß auf einen Vortrag des Uber-Design-System-Teams. Sie erklärten, wie sie ihr Badge-Element von dutzenden starren Varianten auf wenige hochdynamische Konfigurationen reduzierten – durch den Wechsel zu einem parametrischen Design-Modell.
Ihr Badge konnte jede Form, Farbe oder jeden Status annehmen, ohne die Variantenliste aufzublähen. Es nutzte nur wenige Props wie tone, size, icon und message, gesteuert durch Tokens und kontextabhängige Logik. Einfach, intelligent und skalierbar.
Das blieb hängen.
Als ich meinen eigenen Button betrachtete, sah ich ihn plötzlich nicht mehr als starre visuelle Option, sondern als parametrisches System. Dieser Perspektivenwechsel – weg vom Aussehen, hin zum Verhalten – veränderte alles.
Inspiriert von Ubers „Parametric Components“-Ansatz
Hier anschauen: https://youtu.be/-z9JX8Lz5lI?si=9l5XZCbpWZF0OQee
In diesem Talk zeigt Uber, wie sie das Badge-Element reduzierten, indem sie von Permutationen auf parametrische Steuerungen über Tokens und Props umstellten.
Der Audit: Ordnung im Chaos
Ich habe einen Schritt zurückgemacht und jede erdenkliche Kombination visualisiert.
Dazu habe ich die Anatomie der Buttons inklusive aller Größen genau analysiert. Ziel war es herauszufinden, welche Eigenschaften wir in parametrische Variablen umwandeln können.
Folgende Elemente habe ich dabei genau untersucht:
Buttongröße
Schriftgröße
Zeilenhöhe
Abstand zwischen den Elementen
Vertikales Padding
Horizontales Padding
Eckenradius
Der Audit: Ordnung im Chaos
Ich habe einen Schritt zurückgemacht und jede erdenkliche Kombination visualisiert.
Dazu habe ich die Anatomie der Buttons inklusive aller Größen genau analysiert. Ziel war es herauszufinden, welche Eigenschaften wir in parametrische Variablen umwandeln können.
Folgende Elemente habe ich dabei genau untersucht:
Buttongröße
Schriftgröße
Zeilenhöhe
Abstand zwischen den Elementen
Vertikales Padding
Horizontales Padding
Eckenradius
Der Relaunch
Der Relaunch
Dieses Mal bin ich an den Button herangegangen wie ein Entwickler an eine Komponenten-API.
Ich habe die visuellen und funktionalen Aspekte in Eigenschaften zerlegt, die sich umschalten und skalieren lassen. Dafür habe ich Token-Variablen definiert und diese dem Button zugewiesen – natürlich passend für Light und Dark Mode.
Statt Hunderten von starren Varianten gibt es jetzt eine Kernstruktur mit 32 intelligenten Konfigurationen. Jede Entscheidung beruhte auf zwei Fragen:
„Lässt sich das ohne Duplikate skalieren?“
„Reduziert das den Denkaufwand für alle, die damit arbeiten – mich selbst in der Zukunft eingeschlossen?“
Dieses Mal bin ich an den Button herangegangen wie ein Entwickler an eine Komponenten-API.
Ich habe die visuellen und funktionalen Aspekte in Eigenschaften zerlegt, die sich umschalten und skalieren lassen. Dafür habe ich Token-Variablen definiert und diese dem Button zugewiesen – natürlich passend für Light und Dark Mode.
Statt Hunderten von starren Varianten gibt es jetzt eine Kernstruktur mit 32 intelligenten Konfigurationen. Jede Entscheidung beruhte auf zwei Fragen:
„Lässt sich das ohne Duplikate skalieren?“
„Reduziert das den Denkaufwand für alle, die damit arbeiten – mich selbst in der Zukunft eingeschlossen?“
Das Ergebnis: Vom Chaos zur Brillanz
Die Reduzierung von 432 auf 32 Varianten brachte nicht nur Ordnung. Sie schuf echten Freiraum – für Speed, Fokus und Konsistenz.
Schnellere Performance in Figma
Weniger Risiko für Fehler oder Abweichungen
Einfaches Theming durch Token-Hooks
Verlässliches Verhalten über alle Breakpoints hinweg
Wenn ich jetzt einen Button brauche, passe ich kurz ein paar Eigenschaften an. Das war’s. Keine endlosen Listen an Varianten mehr, kein visuelles oder mentales Chaos.
Das Ergebnis: Vom Chaos zur Brillanz
Die Reduzierung von 432 auf 32 Varianten brachte nicht nur Ordnung. Sie schuf echten Freiraum – für Speed, Fokus und Konsistenz.
Schnellere Performance in Figma
Weniger Risiko für Fehler oder Abweichungen
Einfaches Theming durch Token-Hooks
Verlässliches Verhalten über alle Breakpoints hinweg
Wenn ich jetzt einen Button brauche, passe ich kurz ein paar Eigenschaften an. Das war’s. Keine endlosen Listen an Varianten mehr, kein visuelles oder mentales Chaos.
Barrierefreiheit
Komplexität reduzieren – aber nicht auf Kosten der Usability. Barrierefreiheit war von Anfang an ein zentraler Design-Faktor, kein nachträgliches Add-on. Das hatte direkten Einfluss auf den Button-Rebuild:
Jeder Farb-Token, ob Text oder Hintergrund, wurde streng auf die WCAG AA Kontrast-Standards geprüft – im Light und Dark Mode. Was nicht bestand, flog rigoros raus.
Barrierefreiheit
Komplexität reduzieren – aber nicht auf Kosten der Usability. Barrierefreiheit war von Anfang an ein zentraler Design-Faktor, kein nachträgliches Add-on. Das hatte direkten Einfluss auf den Button-Rebuild:
Jeder Farb-Token, ob Text oder Hintergrund, wurde streng auf die WCAG AA Kontrast-Standards geprüft – im Light und Dark Mode. Was nicht bestand, flog rigoros raus.
Was ich gelernt habe
Allein an Edifire zu arbeiten, gab mir die volle Kontrolle – bedeutete aber auch die volle Verantwortung. Keine Team-Reviews, keine gemeinsamen Standards. Das System musste von Grund auf resilient sein.
Das habe ich aus diesem Prozess gelernt:
Eine Komponente sollte sich wie ein Werkzeug anfühlen, nicht wie eine Falle.
Flexibilität entsteht durch klare Grenzen, nicht durch Chaos.
Wer allein designt, macht sein zukünftiges Ich zum härtesten Stakeholder.
Komponenten-Logik schlägt visuelles Stapeln.
Design-Systeme sollen Entscheidungen reduzieren, nicht nur Dinge wiederverwendbar machen.
Tokens, Slots und Props sind Ihre besten Freunde.
Sobald es sich schwerfällig anfühlt: Zeit für ein Refactoring.
Was ich gelernt habe
Allein an Edifire zu arbeiten, gab mir die volle Kontrolle – bedeutete aber auch die volle Verantwortung. Keine Team-Reviews, keine gemeinsamen Standards. Das System musste von Grund auf resilient sein.
Das habe ich aus diesem Prozess gelernt:
Eine Komponente sollte sich wie ein Werkzeug anfühlen, nicht wie eine Falle.
Flexibilität entsteht durch klare Grenzen, nicht durch Chaos.
Wer allein designt, macht sein zukünftiges Ich zum härtesten Stakeholder.
Komponenten-Logik schlägt visuelles Stapeln.
Design-Systeme sollen Entscheidungen reduzieren, nicht nur Dinge wiederverwendbar machen.
Tokens, Slots und Props sind Ihre besten Freunde.
Sobald es sich schwerfällig anfühlt: Zeit für ein Refactoring.
Wie es weitergeht
Der Button-Refactor war nur der erste Schritt. Wir machen Edifire zu einem durchdeckten, skalierbaren System, das einfach Spaß macht.
Als Nächstes übertragen wir diesen Ansatz auf Modale, Dropdowns, Tabs und Inputs. Logik statt komplexer Ebenen führt hier das Design.
Edifire wird bald Open Source. Und dann ist es weit mehr als nur eine Sammlung von UX/UI-Teilen. Klein bauen. In Systemen denken. Reibung reduzieren. Raum für Wachstum lassen.
Mein Fokus liegt darauf, Design und Development perfekt zu verbinden. So können Sie das System sofort nutzen. Die React-Code-Snippets der Edifire-UI-Komponenten binde ich direkt via Figma MCP und Cursor in Zeroheight ein.
Wie es weitergeht
Der Button-Refactor war nur der erste Schritt. Wir machen Edifire zu einem durchdeckten, skalierbaren System, das einfach Spaß macht.
Als Nächstes übertragen wir diesen Ansatz auf Modale, Dropdowns, Tabs und Inputs. Logik statt komplexer Ebenen führt hier das Design.
Edifire wird bald Open Source. Und dann ist es weit mehr als nur eine Sammlung von UX/UI-Teilen. Klein bauen. In Systemen denken. Reibung reduzieren. Raum für Wachstum lassen.
Mein Fokus liegt darauf, Design und Development perfekt zu verbinden. So können Sie das System sofort nutzen. Die React-Code-Snippets der Edifire-UI-Komponenten binde ich direkt via Figma MCP und Cursor in Zeroheight ein.
Mehr Projekte
Mehr Projekte
Voicery
Webdesign und Umsetzung für Voicery · 2026. Für dieses spezialisierte KI-Voice-Produkt brauchte es eine cleane, moderne und conversion-starke UX/UI. Technisch anspruchsvoll, um sofortige Glaubwürdigkeit zu vermitteln. Gleichzeitig einfach gehalten, damit der Kernnutzen für jeden User sofort greifbar ist.
Axonex AI
Ein umfassendes Figma-zu-Framer-Projekt für Axonex AI im Jahr 2026. Als visionäres KI-Unternehmen brauchten sie eine makellose Umsetzung ihres komplexen Webdesigns. Entstanden ist eine voll animierte, responsive Website. Absolut originalgetreu, blitzschnell und flüssig auf jedem Device.
Schreiben Sie uns
Schreiben Sie uns
Angebot anfordern
Gespräch buchen
Schreiben Sie uns
Angebot anfordern
Gespräch buchen
Schreiben Sie uns
Lieber per E-Mail?
hello@jayhans.design
hello@jayhans.design
Folgen Sie uns auf
© 2026 Joyce Hanson
© 2026 Joyce Hanson
Designt & entwickelt in Framer · Hamburg, DE
Designt & entwickelt in Framer · Hamburg, DE
Zertifizierter Framer Pro Expert
Premium-Websites und Branding für Unternehmen, die Kunden lieber gewinnen als ihnen hinterherzulaufen. Hamburg → weltweit.
RECHTLICHES
STATUS
© 2026 StudioHans
Kreiert & geschmiedet in 🔥 · Hamburg, DE
Zertifizierter Framer Pro Expert
Premium-Websites und Branding für Unternehmen, die Kunden lieber gewinnen als ihnen hinterherzulaufen. Hamburg → weltweit.
RECHTLICHES
STATUS
© 2026 StudioHans
Kreiert & geschmiedet in 🔥 · Hamburg, DE
Zertifizierter Framer Pro Expert
Premium-Websites und Branding für Unternehmen, die Kunden lieber gewinnen als ihnen hinterherzulaufen. Hamburg → weltweit.
RECHTLICHES
STATUS
© 2026 StudioHans
Kreiert & geschmiedet in 🔥 · Hamburg, DE