Designsystem und Gast-Checkout bei einer E-Commerce-Plattform

Problem und Rahmenbedingungen

Ich kam als erster dedizierter Frontend-Entwickler zu einer E-Commerce-Plattform. Bis dahin hatte das Backend-Team das Frontend neben der eigenen Arbeit gebaut, ohne eine wiederverwendbare Komponentenschicht, auf der sich aufbauen ließ.

Zwei Kräfte bestimmten die Arbeit. Erstens brauchte das Produkt vor dem öffentlichen Start eine komplette Überarbeitung des Designs, und die Figma-Dateien aus dem UI-Design waren der Vertrag; wie etwas aussah, entschied am Ende das Design. Zweitens zeigten die Produktdaten klar, wo Geld verloren ging: Product Owner und UX-Forschung fanden heraus, dass viele Kaufwillige eine Produktseite erreichten, auf Kaufen klickten, auf eine Login-Seite umgeleitet wurden und nie zurückkamen.

Das Team arbeitete ohne formale Hierarchie: vier Personen im Backend, die in Elixir arbeiteten, eine für Datenbank und DevOps zugleich, zwei für Flutter und die mobilen Apps und ich fürs Web. Alle verantworteten ihren eigenen Bereich und entschieden darin, abgestimmt mit dem Product Owner; die großen Entscheidungen fielen gemeinsam mit der technischen Leitung (CTO). Was gebaut wurde, kam von CTO, Produkt und Design; meine Entscheidungen betrafen, wie es im Web umgesetzt wurde. Mein Bereich waren die Überarbeitung des Designs, die Komponentenbibliothek, der Checkout sowie Authentifizierung und Autorisierung; später kam das Mentoring für zwei Nachwuchskräfte im Frontend dazu.

Die Arbeit verlief in Etappen. Die Überarbeitung setzte ich allein in zwei Wochen um, von der Startseite bis zur kleinsten Menüseite, und schloss sie rechtzeitig zum öffentlichen Start ab. Danach folgten kleinere Verbesserungen an UI, UX und Logik als Jira-Vorgänge aus Test und Design, und parallel begann ich mit der Komponentenbibliothek, denn das Produkt hatte noch keine.

Architektur

Auf der Plattform sitzen zwei Client-Apps: die Web-App (Vue 3 mit Quasar, Pinia für den Zustand und die Komponentenbibliothek) und eine Flutter-App für iOS und Android. Das Backend war mitten in der Migration von einem Monolithen zu parallelen Elixir-Microservices.

Der neue Registrierungs- und Kaufablauf brauchte drei Wege: ein Konto anlegen, sich bei einem bestehenden Konto anmelden und einen Gast-Checkout, der nur das abfragt, was der Kauf braucht. Das Backend für die Registrierung war zuerst fertig; im Frontend ging es dort darum, es anzubinden und das State Management sauber darauf abzustimmen. Das Backend für den Checkout war noch nicht fertig und brauchte weitere zwei bis drei Monate.

Der Checkout lief deshalb als bewusste Zwischenlösung im Client: Das Frontend baute den Warenkorb, berechnete Rabatte pro Artikel und pro Bundle, rief den Zahlungsanbieter direkt auf und erhielt das Ergebnis, weil das Backend noch keine Live-Preise liefern konnte. Pinia-Stores hielten den Checkout-Zustand über alle Schritte, die Auth-Sitzungen und die Admin- und Nutzerkontexte, mit rollenbasierten Zugriffsprüfungen im Router. Bis die Autorisierung im Backend vollständig angebunden war, war das Frontend praktisch die Zugriffskontrolle, also musste jeder Schritt jeder User Story auf Lecks und falsche Navigationspfade durchgegangen werden. Die Entscheidungen dahinter stehen im Entscheidungsprotokoll unten, jede mit der Alternative, gegen die sie sich durchgesetzt hat.

Ergebnisse

Der Gast-Checkout verbesserte die Conversion-Rate messbar: Die Abbruchstelle, die die UX-Forschung gefunden hatte, war schlicht beseitigt. Das Designsystem gab dem Team eine gemeinsame Komponentenschicht, die die Entwicklung neuer Features beschleunigte: rund hundert Komponenten, vom ganzen Team übernommen, passend zu den Figma-Entwürfen und mit Quasar darunter. Tests wurden vertrauenswürdig und für jedes Feature Pflicht, und eine Caching-Schicht in GitHub Actions, die ich ergänzte, verkürzte den Workflow zum Paketieren der App, der bei jedem Merge, Release und Test-Build lief, um rund 40 %.

Die Nachwuchskräfte, die ich betreute, entwickelten sich vom Pair-Programming über Anleitung anhand von Issues dahin, eigenständig besser zugeschnittene PRs mit schnelleren Review-Zyklen zu liefern.

Lehren

Ich hätte Quasar bei der ersten echten Unbequemlichkeit fallen lassen. Je länger es blieb, desto schwerer fiel der Abschied, und seine stark gestylten, mit Klassen überladenen Komponenten an die maßgeschneiderten Vorgaben des Designs anzupassen, war ein ständiger Aufpreis auf genau die Arbeit, die das Designsystem billiger machen sollte. Ein gestyltes Komponenten-Framework unter einem pixelgenauen Designsystem zu kapseln heißt, ständig gegen seine eingebauten Konventionen anzukämpfen; wenn das Design der Vertrag ist, sind Headless-Primitive (oder eigene) das solidere Fundament. Es ist der deutlichste Fall vom Sog versunkener Kosten, den ich erlebt habe, und er hat verändert, wie schnell ich bereit bin, eine Grundsatzentscheidung neu zu verhandeln.