Vier Disziplinen, fünf Übergaben. Jede Übergabe hat ein Artefakt — und ein typisches Risiko, wenn sie schiefgeht. Wer die Übergaben kennt, briefet besser.
Vier Disziplinen
Jede Disziplin liefert ein definiertes Artefakt. Die Farbe begleitet dich auf allen Folge-Seiten — sie zeigt sofort, wer für einen Schritt verantwortlich ist.
Content
Inhalts-Inventar, Strukturplan, Texte, Bildauswahl. Content sitzt in der Mitte — alle anderen liefern an Content und holen von Content ab. Die Disziplin definiert, welche Aussage eine Seite überhaupt trägt; Design, Frontend und Backend bauen drumherum.
Aufgabe
Briefings vom Kunden in pflegbare Inhalts-Bausteine übersetzen, Pflichtangaben für Förderprogramme oder Fahrpläne ableiten, Bildmotive und Texte beauftragen.
Artefakte
Inhaltsverzeichnis je Seitentyp, Texte mit Lese-Reihenfolge, Bildbriefings mit Format und Motiv, Pflichtfeld-Listen pro Element.
Design
Erst Konzept (Wireframes, User-Flows, Strukturskizzen), dann Layout (Farbe, Typografie, Bildsprache). Design verantwortet die sichtbare Form und die Pfade, auf denen Nutzerinnen durch die Seite kommen — von der Startseite bis zum Förder-Antrag.
Aufgabe
Strukturskizze pro Seitentyp, Komponenten-Bibliothek aufbauen, Mobile- und Desktop-Variante zeigen, mit Frontend prüfen, was teuer wird.
Artefakte
Wireframes (vor Farben), Figma-File mit annotierten Breakpoints, Design-System (Tokens), Komponenten-Specs mit allen Zuständen.
Frontend
Aus dem Figma-File wird eine klickbare Webseite: HTML, CSS, JavaScript, Bewegung. Output ist keine Live-Site, sondern eine statische Vorlage — Astro-Templates, die das Backend später 1:1 in TYPO3-Fluid übersetzt.
Aufgabe
Komponenten bauen, Responsive-Verhalten implementieren, Hover-/Animations-Verhalten definieren, Lighthouse- und Accessibility-Checks bestehen.
Artefakte
Astro-Templates pro Seitentyp, Komponenten-Library, Microinteractions als Code (nicht als GIF), Style-Build inkl. Tokens.
Backend
TYPO3, Server, Datenbanken, APIs, Pflegeoberfläche. Backend übersetzt die Frontend-Vorlage in Fluid-Templates, baut die Pflege-Felder und stellt sicher, dass die Seite skaliert — mit Backups, SSL, Monitoring und Performance-Cache.
Fluid-Templates 1:1 zur Frontend-Vorlage, CMS-Konfiguration mit Rechten, API-Anbindungen, Server-Setup mit Backup-Plan.
Die fünf Übergaben
Was passiert konkret an der Schnittstelle? Was wird übergeben — und woran erkennst du, dass die Übergabe sauber war?
01
Erst Inhalt, dann Form
Content→Design
Was passiert
Welche Inhalte gibt es, in welcher Hierarchie? Was muss auf die Startseite, was in die Tiefe? Content bringt das Inhalts-Inventar mit Prioritäten, Design baut die Struktur darum. Wenn die Reihenfolge umgedreht wird, entstehen hübsche Layouts mit "Lorem ipsum" — die später nicht zum Inhalt passen.
Artefakt
Inhalts-Inventar je Seitentyp: was steht da (Headline, Lead, Bild, Liste), in welcher Reihenfolge, mit welcher Priorität. Beispiel: Startseite Förderprogramme — oben drei aktive Programme als Cards, darunter ein Erklär-Block "Wie läuft eine Antragstellung", unten Kontakt.
Wenn's schiefgeht
Layout entsteht ohne Inhalt. Folge: leere Platzhalter im Pitch, die später nicht gefüllt werden können — oder die Hierarchie passt nicht (z.B. drei "Hero-Slots", aber nur ein wirklich wichtiges Thema).
Beispiel
Klima-Förderportal: Content liefert "Solar / Wärmepumpe / KfW" als gleichwertige Programme. Design entscheidet, ob das eine Card-Reihe oder Tabs werden — nicht umgekehrt.
02
Was kann gebaut werden, was wird teuer?
Design→Frontend
Was passiert
Frontend prüft das Designkonzept gegen die Realität von Mobile, Tablet, Desktop und Animations-Performance. Typische Fragen: Was passiert mit dem 4-Spalten-Grid auf 375px Breite? Funktioniert die Hover-Animation auf Touch-Geräten? Ist die Custom-Schrift in den nötigen Schnitten lizenziert? Diese Prüfung passiert vor der Programmierung — danach kostet Änderung Faktor 5.
Artefakt
Figma-File mit annotierten Specs, expliziten Breakpoints (mind. Mobile 375 / Tablet 768 / Desktop 1280), Komponenten-Zuständen (default, hover, focus, disabled, loading) und Anmerkungen zu Animationen.
Wenn's schiefgeht
Designs ohne Mobile-Variante. Folge: Frontend interpretiert frei — der Kunde sieht in der Präsentation einen perfekten Desktop-Hero, in der Umsetzung aber etwas völlig anderes auf dem Handy. Diskussion danach ist teuer.
Beispiel
ÖPNV-Fahrplan-Seite: Im Figma steht eine 5-Spalten-Tabelle mit Hover. Frontend fragt: "Was passiert auf 375px?" Lösung: gestapelte Cards statt horizontale Tabelle. Vorher klären, nicht beim Bauen entdecken.
03
Pflegbarkeit entscheidet sich hier
Frontend→Backend
Was passiert
Backend übersetzt die Frontend-Vorlage in Fluid-Templates. Damit das funktioniert, müssen pro Komponente die Felder klar sein: Was ist statisch, was wird gepflegt? Was ist Pflicht, was optional? Welcher Datentyp (Text, Rich-Text, Bild, Link, Liste)? Wenn das nicht steht, baut Backend, was es vermutet — und der Redakteur findet im CMS Felder, die niemand versteht.
Artefakt
Komponenten-Liste mit Feld-Definition: Name, Typ, Pflicht/Optional, Beispieldaten, Validierungs-Regeln. Plus: welche Felder werden vom Redakteur gepflegt vs. welche kommen aus einer API (z.B. Förderdaten).
Wenn's schiefgeht
Komponente ohne klare Felder-Definition. Folge: Backend baut nach Vermutung, Pflege-Felder heißen "Text 1 / Text 2 / Bild 1" — der Redakteur muss raten. Änderungen später sind doppelte Arbeit.
Beispiel
E-Ladesäulen-Karte: Frontend hat das Layout, aber sind die Standorte ein gepflegtes Feld oder eine API? Wenn API: Welche? Wenn gepflegt: brauchen wir Lat/Lng oder Adresse? Diese Klärung gehört vor die Programmierung.
04
Pflegeoberfläche gemeinsam bauen
Content→Backend
Was passiert
Welche Felder soll der Redakteur im TYPO3-Backend sehen, in welcher Reihenfolge, mit welchen Hilfetexten? Welche sind Pflicht, welche optional? Wer gibt frei? Diese Entscheidungen kommen NICHT aus dem Backend allein — Content (oft mit dem echten Redakteur des Kunden) muss mitreden, sonst wird die Oberfläche unbenutzbar.
Artefakt
Feld-Liste pro Element-Typ, Rechte-Matrix (wer darf was), Freigabeprozess (Vier-Augen-Prinzip Ja/Nein), inkl. Schulungs-Skript für den Redakteur.
Wenn's schiefgeht
Pflegeoberfläche wird ohne Redakteur entschieden. Folge: Felder, die niemand versteht oder pflegt — oder die immer leer bleiben, weil sie eigentlich nicht gebraucht wurden.
Beispiel
Förderprogramm-Element: Pflichtfelder sind Programm-Name, Förderhöhe, Antragsfrist. Optionale Felder: PDF-Anhang, Kontaktperson. Backend setzt das so auf, Content schult dazu.
05
Form und Inhalt briefen sich
Design→Content
Was passiert
Diese Übergabe ist nicht linear — sie läuft parallel und in beiden Richtungen. Content schickt Inhalts-Inventar, Design antwortet mit Strukturskizze, beide passen an, bis ein gemeinsamer Plan steht. Wenn jemand wartet, statt zu briefen, blockiert das ganze Projekt.
Artefakt
Gemeinsamer Strukturplan, abgenommen von Content UND Design — kein einseitiges "Hier ist mein Briefing, mach mal".
Wenn's schiefgeht
Designer wartet auf "fertigen Content", Content wartet auf "fertiges Layout". Folge: Stillstand, beide bauen am Ende doch ohne den anderen — und es passt nicht zusammen.
Beispiel
Mobilitäts-Kampagne "Stadtradeln": Content-Idee = Personen-Story-Slider mit Zitaten. Design schaut sich das an, sagt "5 Stories sind zu viele auf Mobile, lass uns 3 nehmen". Zurück an Content. So entsteht ein gemeinsamer Plan.
Parallel oder seriell?
Nicht alle Übergaben laufen strikt nacheinander. Drei Faustregeln:
Inhalts- + Designkonzept
Laufen parallel. Beide briefen sich — sonst entstehen Layouts ohne Inhalt oder Inhalt ohne Form.
Frontend + Backend-Infrastruktur
Teilweise parallel ab Phase 4. Server-Setup darf früh starten — die Fluid-Übernahme erst, wenn Frontend stabil ist.
Content-Pflege
Beginnt erst nach Phase 7 — vorher gibt es kein TYPO3, in das Content fließen kann.
Alle Übergaben sind in den 9 Phasen verankert — siehe Workflow.
Was bei Übergaben schief geht
Vier Muster, die jedes Projekt mindestens einmal trifft. Wer sie kennt, kann früh gegensteuern.
"Wir machen das Backend später."
Wenn Backend nicht ab Phase 5 mitdenkt, sind die Felder falsch benannt — und die Pflegeoberfläche wird ein Workaround.
"Content kommt während der Pflege."
Wenn Inhalte erst in Phase 8 entstehen, war Phase 1-4 Spekulation. Layouts passen oft nicht.
"Frontend kann das schon klären."
Designentscheidungen ohne Frontend-Stimme werden teuer — z.B. Animationen, die in TYPO3 nicht funktionieren.
"Mache ich kurz selbst."
Direktnachrichten an Devs umgehen Renana. Folge: doppelte Arbeit, verlorene Tickets, niemand hat den Überblick.