CP Registry

Wissensbasis

Zusammenarbeit

Sieben rollenübergreifende Routinen — wo Reibung entsteht oder verhindert wird. Beispiele aus dem echten Projekt-Alltag.

7 Routinen + Szenarien
  1. Konzeptions-Termin braucht schriftliches Briefing
  2. Design-Freigabe schließt Phase 3 — nichts anderes
  3. Schnittstellen vor Phase 7 schriftlich klären
  4. Pflegefelder entstehen mit dem Redakteur, nicht ohne ihn
  5. QS läuft in festgelegter Reihenfolge, nicht gleichzeitig
  6. BFSG ist Teamaufgabe — nicht Frontend-Problem
  7. Brand-Override über CSS-Tokens, nicht Component-Fork
  8. Szenarien aus dem Alltag
Für den Gesamt-Workflow siehe /digital-unit/workflow, für Tickets und Goldene Regeln /digital-unit/spielregeln.
wichtig

Konzeptions-Termin braucht schriftliches Briefing

Ohne klare Vorgaben produziert der Termin Wunschlisten statt Entscheidungen.

Problem: Wenn der Konzeptions-Termin ohne klare Vorgaben startet, entsteht kein Ergebnis — sondern ein Protokoll offener Fragen.

Phase 2 (Design) baut auf unklaren Annahmen auf, alles später wird teurer.

  1. Briefing verschicken

    Renana schickt das ausgefüllte Briefing mindestens drei Werktage vor dem Termin an alle Beteiligten.

  2. Entscheider klären

    Renana klärt vorab mit dem Kunden, wer im Termin Entscheidungen treffen darf — nicht nur zuhört.

  3. Termin vorbereiten

    Hendrik moderiert die visuelle Richtung. Marc-Andre bringt Machbarkeits-Realitäten, sortiert Wünsche in machbar/nicht-machbar.

  4. Ergebnis protokollieren

    Lina notiert visuelle Anker. Renana protokolliert Vereinbarungen schriftlich — Ergebnis ist eine Entscheidungs-Liste, kein Fragenkatalog.

  5. Phase 2 freigeben

    Erst wenn alle offenen Punkte aus dem Protokoll geschlossen sind, gibt Renana Phase 2 frei.

Renana (PM)

Koordination

Laedt ein, stellt Briefing-Vorlage bereit, klärt vorab mit dem Kunden, wer auf Kundenseite entscheidet.

Marc-Andre (FE/UX)

Realitäts-Check

Bringt Workflow-Realitäten ein (Vorlauf, technische Grenzen) und sortiert Wünsche in machbar/nicht-machbar.

Hendrik (Design)

Moderation

Moderiert visuelle Richtung, eskaliert Themen, die den Rahmen sprengen.

Lina (UI/Motion)

Aufnahme

Hoert mit, notiert visuelle Anker für Phase 2.

Dragan (Backend)

Optional

Kommt nur dazu, wenn Schnittstellen oder Pflegelogik im Raum stehen — sonst Phase 5/6.

Du (PM oder FE)

Vorbereitung

Bringst die schriftliche Anforderung, Zielgruppe und eine Liste offener Fragen.

Beispiel

Service-Hub-Relaunch

Briefing lag eine Woche vor dem Termin vor. Renana hatte mit dem Kunden geklärt, welche Seiten-Typen in Scope sind. Im Termin entschieden Marc-Andre und Hendrik in 60 Minuten. Phase 2 startete am nächsten Tag.

Gegenbeispiel

Landingpage ohne Briefing

Der Kunde brachte nur "wir wollen sowas wie Seite X" mit. 90 Minuten Klärung ohne Ergebnis. Phase 2 verschoben, Phase 3-4 im Vorlauf zerfallen.

Weiter: Workflow Phase 1 · Vorlaufzeiten

Vertiefung

Briefing-Mindeststandard: eine Seite Text mit Zielgruppe, Use-Case, Erfolgskriterium. Beispiel-Inhalt (echte Texte, nicht Lorem) oder klare Zusage, wann Content kommt. Liste der Stakeholder auf Kundenseite mit Entscheidungs-Rolle.

kritisch

Design-Freigabe schließt Phase 3 — nichts anderes

Frontend startet erst, wenn das Design schriftlich freigegeben ist.

Problem: Frontend startet auf Mockups, die noch im Fluss sind.

Components werden gebaut, dann verworfen — der Vorlauf verbrennt.

  1. Design fertigstellen

    Lina + Hendrik setzen Mockups in Figma final, inklusive States (Hover, Focus, Active, Disabled) und Mobile-Variante.

  2. Pre-Review FE

    Marc-Andre prüft Token-Kompatibilität, lange Strings, Touch-Targets. Gibt Designs frei oder schickt zurück mit konkreter Liste.

  3. Kundenfreigabe

    Renana holt schriftliche Kundenfreigabe per Awork-Ticket. Erst danach gilt Phase 3 als geschlossen.

  4. Frontend startet

    Brandon startet Phase 4 erst nach Freigabe-Ticket. Vorher: keine Component-Implementierung.

  5. Tokens exportieren

    Designer exportiert Tokens, Spec-Werte und kennzeichnet neue Components vs. wiederverwendete.

Beispiel

Produkt-Card mit vier States

Lina lieferte alle vier States plus 320px-Variante. Marc-Andre fand zwei Token-Mismatches in 20 Minuten, Lina fixte sie am selben Tag. Renana holte Kundenfreigabe in 48 Stunden. Phase 4 startete sauber.

Gegenbeispiel

Karten-Komponente — muendliche Freigabe

Hendrik gab muendlich frei. Brandon baute drei Tage. Dann forderte der Kunde andere Iconografie. Drei Tage neu.

Weiter: Workflow Phase 3 · Theme-Generator

Vertiefung

Im Figma-Handoff stehen: Component-Name (passend zu CP-Registry), Token-Bezug pro Element (Farbe, Spacing, Schrift), States explizit als Frames (nicht als Notiz), Mobile-Variante ab 320px.

kritisch

Schnittstellen vor Phase 7 schriftlich klären

Was aus dem CMS kommt und was statisch bleibt, muss vor der Programmierung stehen — nicht danach.

Problem: Wenn niemand vorher klärt, welche Inhalte aus dem CMS kommen und welche statisch bleiben, baut Frontend Markup, das Backend nicht abbilden kann.

Phase 7 (Übernahme) stockt wochenlang wegen unklarer API-Verträge.

  1. Slots markieren

    Marc-Andre + Brandon markieren in den Astro-Templates, was Inhalt ist (Slot, Prop) und was Strukturteil bleibt.

  2. TYPO3-Pfad mappen

    Dragan + Chris mappen pro Component den TYPO3-Datenpfad (TCA, Content-Element-Typ, FlexForm) und nennen Fluid-Pendants.

  3. Termin moderieren

    Renana moderiert den 60-Minuten-Termin (Phase 5) und protokolliert Vereinbarungen.

  4. Datenmodell dokumentieren

    Lukas oder Henri dokumentieren das Datenmodell pro Page-Typ, bevor Phase 7 startet.

  5. Schriftlich klären

    Offene Punkte schriftlich klären, nicht in Teams-Chat — sonst sind sie nächste Woche vergessen.

Beispiel

Service-Listen-Page

Phase 5 mit 45 Minuten angesetzt. Brandon und Chris klärten: Eintrag-Titel und -Text aus CMS, Kennzahl als FlexForm-Zahl, Filter-Kategorien aus Sys-Categories. Phase 7 lief 4 Tage später ohne Rueckfragen.

Gegenbeispiel

Störungsticker-Widget

Phase 5 fast übersprungen. Folge: 3 Wochen Verzögerung in Phase 7 — Backend hatte einen externen Feed erwartet, Frontend hatte hartkodierte Beispieldaten.

Weiter: Workflow Phase 5

Vertiefung

Im Schnittstellen-Protokoll stehen: Component-Name (Astro) und Fluid-Pendant, Felder mit TCA-Typ (input, text, inline IRRE, sys_category), Pflicht/optional pro Feld, Default-Werte für leere Inhalte.

wichtig

Pflegefelder entstehen mit dem Redakteur, nicht ohne ihn

Wenn Backend frei entscheidet, bekommt der Redakteur zu viele Schalter oder zu wenige.

Problem: Wenn Backend frei entscheidet, welche Felder im TYPO3-Backend sichtbar sind, ist das Ergebnis entweder Chaos oder ein Dauerbrenner für Tickets.

Felder, die niemand versteht oder braucht, bleiben leer — oder jede Änderung braucht einen Deploy.

  1. Redakteur befragen

    Lass den Kunden-Redakteur beschreiben, welche Inhaltsteile sich pro Seite oder Quartal ändern. Nicht raten.

  2. Pflegeliste erstellen

    Renana übersetzt die Anforderungen in eine Pflegeliste pro Page-Typ — maximal 8 Felder. Was darüber ist, ist Struktur.

  3. Technisch umsetzen

    Chris und Dragan entscheiden, was als TCA-Feld, was als FlexForm, was als Inline-Element abgebildet wird.

  4. Robustheit prüfen

    Marc-Andre prüft: Brechen leere Strings oder fehlende Bilder das Layout? Wenn ja: Defaults definieren.

  5. Anleitung übergeben

    Du bekommst eine schriftliche Pflege-Anleitung pro Page-Typ. Kein Ticket für Standardpflege.

Redakteur (Kunde)

Anforderung

Beschreibt, welche Inhaltsteile sich pro Seite/Quartal ändern.

Renana (PM)

Übersetzung

Uebersetzt das in eine Pflegeliste pro Page-Typ.

Chris + Dragan

Technisch

Entscheiden, was als TCA-Feld, was als FlexForm, was als Inline-Element abgebildet wird.

Marc-Andre (FE)

Prüfung

Prüft, ob die Pflegestruktur die Component-Robustheit nicht bricht (leere Strings, fehlende Bilder).

Du (Content)

Ergebnis

Bekommst am Ende eine schriftliche Pflege-Anleitung pro Page-Typ.

Beispiel

Produkt-Detailseite

Renana, Chris und Marc-Andre einigten sich auf 6 Pflegefelder (Titel, Lead, Kennzahl, Frist, Zuständige Stelle, Linkliste). Alles andere ist Struktur. Redakteure pflegen seit 4 Monaten ohne Ticket.

Gegenbeispiel

Kampagnen-Eventseite

Phase 6 ausgelassen ("Event ist einmalig"). Drei Wochen vor dem Event aenderte sich der Veranstaltungsort — pflegbar war nur der Titel. Backend musste deployen.

Weiter: Workflow Phase 6 · TYPO3-Pflege

kritisch

QS läuft in festgelegter Reihenfolge, nicht gleichzeitig

Wenn alle gleichzeitig prüfen, kollidieren Bugs — und Sachen fallen durch.

Problem: QS ist nicht eine Prüfung, sondern fünf parallele — ohne Reihenfolge kollidieren gemeldete Bugs mit laufenden Fixes.

Stunden gehen für Klärung drauf, ob ein gemeldeter Bug schon gefixt ist — oder er fällt ganz durch.

  1. FE Smoke-Test

    Brandon: Smoke-Test direkt nach Phase-7-Übernahme — Routen 200, Console clean, kein gebrochenes Layout.

  2. BE Pflege-Test

    Chris/Lukas: Pflege-Test im TYPO3-Backend — alle Felder befüllbar, keine Fluid-Errors.

  3. Design Visual-Diff

    Lina + Hendrik: Visual-Diff gegen Mockups, States, Mobile.

  4. A11y-Smoke

    Marc-Andre: Tab-Reihenfolge, Kontraste, Focus-Visible.

  5. Kunden-Walkthrough

    Renana: Kunden-Walkthrough mit Pflege-Anleitung. Erst danach Phase 9 (Deployment).

Beispiel

Produkt-Hub-Relaunch

QS in 2 Tagen: FE-Smoke (Tag 1, 2h), BE-Pflege (Tag 1, 3h), Design-Visual (Tag 2 Vormittag), A11y (Tag 2 Mittag), Kunden-Walkthrough (Tag 2 Nachmittag). Deployment Tag 3.

Gegenbeispiel

Kampagnen-Card — gleichzeitige QS

Design und FE prueften gleichzeitig in derselben Staging-Umgebung. Lina meldete 12 Spacing-Bugs, von denen 9 schon im FE-Branch gefixt waren — aber nicht deployed. 4 Stunden Klärung.

Weiter: A11y-Audit · Bug/Feature/Schönheitsfehler

kritisch

BFSG ist Teamaufgabe — nicht Frontend-Problem

Frontend kann weder Alt-Texte verfassen noch Kontrast-Entscheidungen treffen noch Audit-Trails führen.

Problem: BFSG / WCAG 2.2 AA wird oft als "Frontend-Problem" abgeladen.

Pflichten fallen zwischen die Stühle — und ein Audit-Befund 4 Wochen vor Launch bedeutet 2 Tage Nachpflege-Sprint.

  1. Relevanz prüfen

    Kläre im Kick-off: Ist das Projekt BFSG-relevant? Bei öffentlichen Web-Angeboten und Formularen mit Endkunden: ja.

  2. Design-Pflichten delegieren

    Lina und Hendrik prüfen Farbkontraste >=4,5:1, Touch-Targets >=44px, Focus-Indikatoren und alle States bereits in Figma.

  3. Frontend-Pflichten delegieren

    Marc-Andre und Brandon setzen semantisches HTML, ARIA nur wo nötig, Tastatur-Navigation und Skip-Links um.

  4. Content-Pflichten delegieren

    Redakteur liefert Alt-Texte, Linktexte mit Kontext, korrekte Heading-Hierarchie. Alt-Text-Feld im TCA ist Pflichtfeld.

  5. PM-Pflicht sichern

    Renana plant Barrierefreiheits-Erklärung, Feedback-Mechanismus und Audit-Trail ein — nicht als Nacharbeit, sondern als Briefing-Feld.

Lina + Hendrik

Design

Farbkontraste >=4,5:1, Touch-Targets >=44px, Focus-Indikatoren, alle States. Prüfung schon in Figma.

Marc-Andre + Brandon

Frontend

Semantisches HTML, ARIA nur wo nötig, Tastatur-Navigation, Reduced-Motion, Skip-Links.

Redakteur

Content

Alt-Texte für Bilder, Linktexte mit Kontext, korrekte Heading-Hierarchie.

Renana

PM

Erklärung zur Barrierefreiheit, Feedback-Mechanismus, Audit-Trail.

Dragan + Chris

Backend

Alt-Text-Feld im TCA als Pflichtfeld konfiguriert, Validierung.

Beispiel

Service-Hub-Relaunch

Alt-Text-Felder im TCA als Pflichtfelder konfiguriert (Chris). Kontraste schon in Figma geprüft (Lina). Skip-Links und Focus-Visible (Brandon). Erklärung zur Barrierefreiheit eingeplant (Renana). Audit clean.

Gegenbeispiel

Kampagnen-Microsite

Alt-Texte waren optional. Redakteur lud 60 Bilder ohne Text hoch. Audit-Befund 4 Wochen vor Launch: 60 Verstöße. Nachpflege über 2 Tage.

Weiter: A11y-Audit

wichtig

Brand-Override über CSS-Tokens, nicht Component-Fork

Wer statt Tokens einen Component forkt, verdoppelt jeden kuenftigen Bugfix.

Problem: Eine Tochtermarke oder ein Projekt-Brand bekommt eigene Farben und Schrift. Wenn Designer und Frontend nicht koordiniert arbeiten, entstehen Component-Forks.

Jeder kuenftige Bugfix muss in zwei Branches nachgezogen werden — der Brand-Layer ist tot.

  1. Tokens definieren

    Lina + Hendrik definieren die Brand-Tokens (Primary, Surface, Schrift, Iconografie) im Theme-Generator.

  2. Stabilität prüfen

    Marc-Andre prüft, ob alle existierenden Components auf den neuen Tokens stabil bleiben (kein Component-Fork nötig).

  3. Brand-File ausrollen

    Brandon rollt das Brand-File als Override-CSS aus und registriert es im Build.

  4. Dokumentieren

    Renana dokumentiert die Brand-Datei im Projekt-Awork-Ticket und holt Freigabe.

  5. Tokens als JSON

    Designer liefert Tokens als JSON oder via Theme-Generator-Export — keine PNGs.

Beispiel

Tochtermarken-Brand

Brand-Override in 4 Stunden: Lina exportierte Tokens aus dem Theme-Generator, Marc-Andre verifizierte Component-Stabilität, Brandon registrierte brand-tochtermarke.css. Kein Component-Fork.

Gegenbeispiel

Sub-Brand als Component-Fork

Designer baute CardA → CardB als neuen Component. Vier Wochen später: Bugfix in der Original-Card musste in beiden Branches nachgezogen werden.

Weiter: Theme-Generator

Vertiefung

Brand-Override-Mindeststandard: Tokens als CSS-Custom-Properties (OKLCH bevorzugt). Datei-Konvention: brand-<projekt>.css. Kein zusätzliches HTML/JS — nur CSS-Variablen.

Szenarien aus dem Alltag

Vier Situationen, die jede Woche vorkommen. Klick für die richtige Reaktion.

Designer hat eine Idee, die Frontend nicht in der Vorlaufzeit umsetzen kann. Was tust du?

Im Termin benennen: "Idee notiert, Vorlauf-Prüfung mit Marc-Andre nach dem Termin, Antwort innerhalb 24h." Die Idee nicht stehen lassen ohne Prüfung — und sie nicht im Termin ohne Prüfung killen. Wenn Marc-Andre "nicht in Vorlauf" sagt: Renana entscheidet, ob sie in eine Folgephase wandert oder gestrichen wird.

Wann NICHT: Wenn die Idee aus dem Briefing stammt und bereits kundenseitig abgesegnet wurde, prüfst du nur noch Machbarkeit im aktuellen Tech-Stack.

Frontend ruft an: "Backend hat keine API geliefert, aber wir müssen morgen bauen." Was tust du?

Sofort an Renana eskalieren. Renana klärt mit Dragan, ob Phase 5 versäumt wurde oder ob die Schnittstelle erst später geplant war. Frontend nicht mit Mock-Daten weiterbauen lassen, ohne dass das schriftlich abgesegnet ist — sonst landen Mock-Daten im Live-System.

Wann NICHT: Wenn Phase 5 protokolliert ist und Mock-Daten als explizite Zwischenlösung schriftlich abgestimmt wurden, darf Frontend weiterbauen — bis zum protokollierten Datum der finalen API-Lieferung.

Designkonzept für eine neue Produkt-Card — wer gibt frei?

Marc-Andre (Pre-Review) + Lina/Hendrik (Design-Owner intern) + Renana (Kundenfreigabe). Wenn nur einer der drei freigibt, ist Phase 3 nicht geschlossen. Frontend startet nicht.

Wann NICHT: Bei einer reinen Token-Korrektur an einer bereits freigegebenen Component reicht Marc-Andres Einzelfreigabe — Lina/Hendrik und Renana müssen nur informiert werden.

Bug-Meldung: "Auf 320px überlappt der Such-Filter mit dem Headerlogo." An wen?

Frontend (Brandon) — es ist Layout/CSS. Gegenbeispiele: "Kennzahl wird nicht angezeigt" → Backend (Datenfeld falsch gemappt) oder Content (Feld nicht gepflegt). "Eintrag-Titel falsch geschrieben" → Content. "Filter sortiert nicht nach Datum" → Backend oder Frontend je nach Implementierung.

Wann NICHT: Wenn der Bug auf einem Kunden-spezifischen Gerät außerhalb der getesteten Viewports auftritt, kläre zuerst mit Renana, ob dieses Gerät im Scope ist — bevor du den Fix-Auftrag gibst.

Weiter im Material: 9-Phasen-Workflow · Spielregeln · Wissensbasis Projektmanager