Wer baut das Frontend? Rollen im Composable-Commerce-Team

In einem Composable-Commerce-Stack ist das Backend ein Bündel von Services, und das Frontend ist der Ort, an dem all diese Services zu einem Storefront werden, den ein Kunde wirklich benutzt. Damit ist das Frontend die meistgenutzte gemeinsame Fläche im ganzen Team, und die eine Stelle, an der Rollen-Grenzen schnell verschwimmen. Dieser Beitrag ist der Überblick, wer was tut: Developer und Architekt, Product- und Marketing-Owner, Merchandiser, Designer und Operations. Er benennt auch die Ebene, die diese Rollen vor Kollisionen bewahrt, damit fünf Personen am selben Storefront arbeiten können, ohne sich gegenseitig in die Quere zu kommen.

Das Frontend ist Teamarbeit, kein Job-Titel

Die meisten Stack-Diagramme hören an der API auf. commercetools, Shopware oder ein Headless-CMS liefern Daten; der Storefront macht daraus Seiten, Kampagnen und einen Checkout. Der Fehler, den viele Teams machen: Sie nehmen an, eine Rolle besitze diese Ebene. In der Praxis schreiben mindestens fünf Rollen jede Woche hinein, und die Reibung liegt selten am Können. Sie liegt an unklarer Ownership: Wer darf ein Hero-Banner veröffentlichen, wer gibt eine Komponenten-Änderung frei, wer ist verantwortlich, wenn eine Seite bei den Core Web Vitals abrutscht. Die Rollen zu benennen ist der erste Schritt, um diese Linien zu ziehen.

Die fünf Rollen, die den Storefront anfassen

Developer und Architekt

Der Developer und Architekt besitzen die Bausteine: Komponenten, Daten-Bindungen und die Integration ins Commerce- und Content-Backend. In einem Composable Headless Frontend heißt das: wiederverwendbare Sections und Blocks definieren, sie an den richtigen Service anbinden und die Type-Contracts stabil halten, damit nichts weiter unten kaputtgeht. Was sie nicht tun sollten: bei jedem Banner-Verschieben ein Ticket bearbeiten. Ihre Aufgabe ist das System, nicht die tägliche Änderung.

Product- und Marketing-Owner

Der Product Owner entscheidet, was der Storefront leisten soll und in welcher Reihenfolge, und übersetzt Geschäftsziele in eine Roadmap für Seiten, Flows und Kampagnen. Der Marketing Manager betreibt die Kampagnen-Ebene obendrauf: Landing-Pages, saisonale Aktionen und den Text, der diese Woche live geht. Beide müssen aus freigegebenen Komponenten komponieren und veröffentlichen können, ohne ein Developer-Ticket. Wenn das nicht geht, staut sich die Roadmap hinter der Engineering-Kapazität, und das ist der häufigste Grund, warum sich Composable-Projekte nach dem Go-live langsam anfühlen.

Merchandiser

Der Merchandiser besitzt, was Shopper sehen und in welcher Reihenfolge: Produkt-Platzierung, Kategorie-Kuratierung, Suche und Discovery sowie die Conversion-Hebel auf der Seite. Diese Rolle sitzt am nächsten am Umsatz und überschneidet sich oft mit dem CRO-Spezialisten, der die Experimente und die Personalisierung fährt, die aus Platzierungs-Entscheidungen gemessenen Lift machen. Merchandising ist eine Frontend-Aufgabe, weil sie in der Präsentations-Ebene lebt, nicht im Katalog-Service, der die Daten speichert.

Designer

Der UX/UI-Designer besitzt die Brand-Konsistenz und die Interaktions-Muster über jede Seite. In einem Composable-Setup ist das Risiko der Design-Drift: zehn Teams bauen zehn leicht unterschiedliche Button-States. Der eigentliche Hebel des Designers ist die Komponenten-Bibliothek und die Design-Tokens, damit eine einmal getroffene Entscheidung überall auftaucht. Das funktioniert nur, wenn der Storefront tatsächlich dieselben Tokens verwendet, die der Designer definiert, statt eines separaten Handoffs, der mit der Zeit zerfällt.

Operations

Operations taucht selten auf einem Rollen-Diagramm auf, aber jemand betreibt Performance-Budgets, Barrierefreiheits-Compliance, Locale-Sync und den Release-Prozess. In vielen Teams ist das aufgeteilt zwischen dem Content Manager für die redaktionelle Governance und einer Plattform- oder DevOps-Funktion für Uptime und Core Web Vitals. Ops ist die Rolle, die merkt, wenn eine gut gemeinte Änderung einen LCP von 2,4 Sekunden ausliefert, und die Rolle, die Guardrails braucht, um das abzufangen, bevor ein Kunde es tut.

Wo Ownership meistens bricht

Das Muster ist vorhersehbar. Marketing wartet auf Developer für Änderungen, die Self-Service sein sollten. Developer werden von der Roadmap abgezogen, um Content-Tippfehler zu fixen. Ops findet Regressionen erst, nachdem sie live sind, weil niemand das Performance-Budget zum Publish-Zeitpunkt geprüft hat. Jede dieser Stellen ist eine Ownership-Lücke, keine Skill-Lücke. Über die Verantwortungs-Seite haben wir in der RACI, die die meisten Teams nach dem Go-live überspringen geschrieben, über die strategische Version der Frage in wem der Storefront gehört.

Frontend Management als gemeinsame Ebene

Die Lösung ist nicht eine sechste Rolle. Sie besteht darin, den fünf eine gemeinsame Betriebs-Ebene zu geben, damit jeder auf der richtigen Flughöhe arbeitet. Frontend as a Service ist Laioutrs Name für diese Ebene: Developer definieren Komponenten und Daten-Bindungen einmal, dann komponieren und veröffentlichen Product, Marketing und Merchandising aus diesen Komponenten über das Content Management, ohne Deploy. Die Tokens des Designers sind dieselben Tokens, die der Storefront rendert. Performance-Budgets und Barrierefreiheits-Regeln gelten für jede Änderung, egal wer sie macht, sodass Ops Guardrails bekommt statt nachträglicher Aufräumarbeit.

Wer macht was

• Developer und Architekt. Besitzt: Komponenten, Daten-Bindungen, Integrationen. Arbeitet in: Code, Schema, Komponenten-Bibliothek.
• Product- und Marketing-Owner. Besitzt: Roadmap, Kampagnen, veröffentlichte Seiten. Arbeitet in: Komposition, kein Deploy nötig.
• Merchandiser. Besitzt: Platzierung, Discovery, Conversion-Hebel. Arbeitet in: Präsentations-Ebene, Experimente.
• Designer. Besitzt: Brand-Konsistenz, Interaktions-Muster. Arbeitet in: Design-Tokens, Komponenten-Bibliothek.
• Operations. Besitzt: Performance, Barrierefreiheit, Releases. Arbeitet in: Guardrails, Monitoring, Governance.

So überträgst du das auf dein Team

1. Benenne den Owner für jede Fläche. Komponenten, Seiten, Kampagnen, Merchandising und Release brauchen je eine verantwortliche Rolle, kein geteiltes Postfach.
2. Trenne das System von der Änderung. Developer besitzen, wie eine Komponente funktioniert; die Leute, die sie täglich nutzen, sollten kein Ticket brauchen, um ihren Inhalt zu ändern.
3. Mach die Guardrails automatisch. Performance- und Barrierefreiheits-Budgets sollten zum Publish-Zeitpunkt greifen, damit Ownership nicht davon abhängt, dass sich jemand ans Prüfen erinnert.

FAQ

Wem gehört das Frontend im Composable-Commerce-Team? Keiner einzelnen Rolle. Developer besitzen Komponenten und Integrationen; Product, Marketing und Merchandising besitzen, was komponiert und veröffentlicht wird; der Designer besitzt die Konsistenz; Ops besitzt Performance und Releases. Eine gemeinsame Ebene hält diese Linien sauber.

Ist Merchandising eine Frontend- oder eine Backend-Rolle? Frontend. Platzierung, Discovery und Conversion-Hebel leben in der Präsentations-Ebene. Der Katalog-Service speichert die Daten, aber die Entscheidungen darüber, was Shopper sehen, fallen im Storefront.

Wie unterscheidet sich das von einem reinen Design-System? Ein Design-System definiert die Komponenten. Frontend Management ist der Ort, an dem jede Rolle sie nutzt: komponieren, veröffentlichen, merchandisen und ausliefern gegen dieselben Tokens, Budgets und Regeln.

Nächster Schritt

Willst du diese fünf Rollen auf dein eigenes Team und deinen Storefront übertragen? Sprich mit dem Laioutr-Team und wir gehen durch, wo jede Rolle arbeitet und wo die gemeinsame Ebene die Reibung wegnimmt.