Composable-Stacks splitten dein Backend sauber. Sie splitten auch den Marketing-Alltag. Das CMS lebt hier. Search-Ranking-Rules drueben. Personalization-Varianten woanders. Produkt-Copy gehoert ins PIM. Promotions gehoeren in die Promotion-Engine. Sechs Tools, drei Drafts, zwei Preview-Environments und ein Slack-Thread, in dem geklaert wird, welches Tool fuer die Kampagne kanonisch ist, die am Dienstag live geht.

Die architektonische Entscheidung war richtig. Die Editor-Experience, die folgte, oft nicht. Nachdem viele Editor-Teams gegen ihren eigenen Stack gekaempft haben, fuenf UX-Patterns, die den Workflow zuverlaessig wieder zusammenfuehren, ohne das Team zurueck in einen Monolithen zu zwingen.

Das hier ist ein Team-Voice-Stueck, das die Architektur-Debatte ueberspringt und in dem Editor-Stuhl sitzt.

Pattern 1: Eine Shell, viele Services

Das Pattern: der Editor sieht ein einziges Canvas. Service-Boundaries verstecken sich hinter Data-Source-Labels, nicht hinter Tools.

Wie das in der Praxis aussieht:

• Der Marketer oeffnet „Hero auf PDP-Shoes-FR" und bekommt ein Panel mit Hero-Copy, Hero-Image, CTA, optionalen Personalization-Varianten und Search-Ranking-Rule-Overrides fuer dieselbe Page.
• Jedes editierbare Feld hat ein kleines „Source: CMS"- oder „Source: Search Tuner"-Label, damit der Marketer weiss, was er anfasst.
• Switching zwischen Feldern bedeutet kein Switching zwischen Tools. Der Marketer loggt sich nie in ein zweites Admin ein.

Anti-Pattern: ein Launcher-Tile-Menu aus sechs Admin-Tools, verkleidet als Portal. Das ist keine Shell. Das ist ein Redirect mit Corporate-Header.

Workflow-Snippet (Acceptance-Criteria fuer Vendor oder Build-Team):

GIVEN ein Marketer editiert eine Page
WHEN  die Page Hero-Copy (CMS), Search-Rules (Search Tuner) und
      eine Personalization-Variante (Personalization) enthaelt
THEN  alle drei Felder sind in einer Shell editierbar
AND   kein Feld oeffnet ein neues Tool, Fenster oder Login
AND   das Field-Source-Label ist ohne Hover sichtbar

Pattern 2: Composite-Preview, das ehrlich bleibt

Das Pattern: Preview zieht den aktuellen Draft-State jeder Section aus dem Service, dem sie gehoert. Preview luegt nie ueber den gezeigten State.

Wie das in der Praxis aussieht:

• Click auf Preview, sehe die Page so, wie sie rendern wird mit: CMS-Draft-State, aktuellen Search-Ranking-Rules inkl. ungespeicherter Tweaks, der aktiven Personalization-Variante, dem aktiven Promo-Banner und den Live-PIM-Daten.
• Jede gepreviewte Section hat einen kleinen Indikator-Strip mit Draft-State pro Service: „CMS: Draft v3", „Search: live", „Personalization: Variant B Preview".
• Wenn ein Service nicht verfuegbar ist (degradiertes API, Auth-Issue), zeigt Preview die Section mit klarem „konnte nicht laden: PIM"-State, statt still auf Live-Daten zurueckzufallen.

Das Anti-Pattern, das damit stirbt: das CMS-Preview, das eine schoene Page zeigt, die nichts mit dem zu tun hat, was Search in Production produziert. Oder das Personalization-Tool-Preview, das den CMS-Draft, den du gerade editierst, ignoriert.

Ehrlichkeit ist das ganze Pattern. Ein Preview, das auch nur einmal luegt, macht den Marketer jedem zukuenftigen Preview misstrauisch.

Pattern 3: Cross-Service-Save-State mit Dependency-Surfacing

Das Pattern: wenn ein Edit in Service A beeinflusst, was Service B tun wird, surface die Dependency vor dem Save, nicht nach dem Publish.

Wie das in der Praxis aussieht:

• Der Marketer benennt eine Product-Collection im CMS um. Der Editor surfaced: „Diese Umbenennung betrifft 12 Search-Ranking-Rules und 3 Personalization-Varianten. Vor dem Save reviewen."
• Click auf die Zahl oeffnet ein Side-Panel mit den betroffenen Items und Quick-Edit-Zugang. Kein neues Tool.
• Der Save selbst bricht die abhaengigen Rules nicht still. Er updated sie im Gleichschritt oder markiert sie mit explizitem Review-State.

Warum das zaehlt: Cross-Service-Bruch ist der stille Killer von Vertrauen in Composable-Editoren. Der Marketer publisht eine Copy-Aenderung. Drei Tage spaeter sehen die Search-Results fuer die umbenannte Collection falsch aus. Niemand verbindet die zwei Events eine Woche lang. Der Slack-Thread beschuldigt den Search-Vendor.

Snippet, wie die Dependency-Oberflaeche in der UI aussieht:

Umbenannt: Collection „Summer-Heat" zu „Summer Heat 2026"
Betroffen:
  - 12 Search-Ranking-Rules (Rename-Token-Mismatch)
  - 3 Personalization-Varianten (Segment-Condition nutzt alten Namen)
  - 1 Redirect-Rule
[ Alle 16 reviewen ]  [ Wo sicher auto-updaten ]  [ Ohne Update saven ]

Der Marketer ist nicht blind. Die Dependency ist auf dem Screen, bevor der Save committed.

Pattern 4: Federated Search ueber Asset-Origin

Das Pattern: eine Suchbox, Results aus jedem Service, Origin klar getaggt.

Wie das in der Praxis aussieht:

• Der Marketer tippt „winter boots" in die Editor-Suchbar.
• Results kommen zurueck: CMS-Pages mit dem Term, PIM-Produkte mit dem Tag, Search-Synonyme, die darauf mappen, Personalization-Varianten mit „winter boots"-Intent, Promo-Banner mit der Copy, Redirect-Rules.
• Jedes Result ist mit seiner Origin getaggt, Click-Through oeffnet das Feld in derselben Shell.

Anti-Pattern: Marketer oeffnet vier Tools, faehrt dieselbe Suche viermal, gleicht die Results mental ab. Das ist ein halber Arbeitstag pro Kampagne.

Federated-Search funktioniert, wenn der Editor saubere API-Contracts mit jedem Service hat. Es ist das Engineering-aufwaendigste der fuenf Patterns. Es ist auch das, was Editoren als erstes bemerken, wenn es funktioniert.

Pattern 5: Atomic Multi-Service-Publish mit explizitem Rollback

Das Pattern: ein Campaign-Level-Publish committed alle betroffenen Services oder keinen. Rollback-Pfade sind explizit, kein Vendor-by-Vendor-Cleanup.

Wie das in der Praxis aussieht:

• Der Marketer launcht eine „Winter Sale"-Kampagne. Die Kampagne touched: CMS-Landing-Page, Search-Ranking-Rules, Personalization-Variante, Promo-Banner und Redirect-Rule.
• Click auf Publish einmal. Der Editor committed alle fuenf Changes atomar. Wenn einer scheitert, committed keiner, und das Failure surfaced mit Retry-Pfad.
• Rollback ist eine einzelne Action, die alle fuenf Changes auf den Vorstand zurueckdreht. Kein Slack-Thread, in dem geklaert wird, welcher Vendor welchen manuellen Fix braucht.

Das Pattern ist das schwerste zu shippen und das mit dem hoechsten Impact auf Editor-Vertrauen. Sobald ein Marketer einen Atomic-Publish erlebt, der ein Mid-Deploy-Failure ueberlebt, hoert er auf, sich vor dem Publish-Button zu fuerchten. Diese eine Verhaltens-Aenderung spart mehr Zeit als die anderen vier Patterns kombiniert.

Der Trade-off: die Orchestrierungs-Logik fuer Atomic-Multi-Service-Publish muss irgendwo leben. In einer Frontend Management Platform ist das ein First-Class-Feature. In einem hand-rolled Stack sind das sechs Monate Platform-Engineering. Beide Pfade funktionieren. Den Trade-off vorher zu kennen, ist der Unterschied zwischen einem Editor, den das Marketing-Team liebt, und einem, den es toleriert.

Wie das zusammen aussieht

Gestapelt machen die fuenf Patterns aus einem Multi-Service-Composable-Stack eine einzelne Editing-Oberflaeche, die:

• Service-Boundaries hinter Data-Source-Labels versteckt, nicht hinter Tool-Menues.
• Ehrlich previewed, inkl. Draft-State pro Service.
• Cross-Service-Impact vor dem Save surfaced, nicht nach dem Publish.
• ueber jede Origin in einer Query sucht.
• Atomar publisht, mit explizitem Rollback.

Die Composable-Architektur darunter bleibt dieselbe. Der Marketer kaempft nicht mehr gegen sie.

Zwei angrenzende Reads, wenn ihr das designed oder einkaufed:

• Die Composable-Visual-Page-Builder-Page zeigt, wie der Laioutr-Editor diese Patterns auf realen Customer-Stacks umsetzt.
• Das Composable-Korrektur-Engineering-Stueck deckt die Engineering-Seite desselben Problems ab: was darunter wahr sein muss, damit die Editor-Patterns guenstig zu shippen sind.

Die Editor-Experience ist kein Luxus-Layer auf einem Composable-Stack. Sie ist der Layer, in dem das Marketing-Team jeden Tag lebt. Behandelt sie als load-bearing, designed sie wie eine.