Sauberer Handover vom Figma-Design zur Backend-Implementierung: Leitfaden für Agenturen in Deutschland

Ein sauber strukturierter Handover vom Figma-Entwurf und Funktionskonzept an die Backend-Umsetzung entscheidet darüber, wie schnell, stabil und performant Ihr Projekt live geht. Je klarer Designsystem, Zustände und funktionale Anforderungen beschrieben sind, desto weniger Rückfragen entstehen, Budgets bleiben planbar und Releases werden schneller. In der Zusammenarbeit mit Agenturen übernehmen Sie in der Regel Design und Frontend-Definition – JAR Media implementiert Backend, CMS/Shop-Logik und Integrationen, sodass Ihre Teams Inhalte effizient einpflegen und an Ihre Endkundschaft weiterreichen können.

Wir arbeiten agil, erstellen vorab eine Budget- und Kostenschätzung und rechnen stundenbasiert ab (95 € pro Entwicklerstunde, 105 € pro Beraterstunde). Ein guter Handover erlaubt präzisere Schätzungen, reduziert Schleifen in der Entwicklung und minimiert Risiken beim Go-Live. Nachfolgend finden Sie eine praxisnahe Checkliste und Spezifikationsvorlage, die sich in Projekten mit Marketing-, Design- und Werbeagenturen in Deutschland bewährt hat.

Handover-Checkliste: Frontend-Fundament für eine saubere Backend-Implementierung

Damit Backend, CMS/Shop-Logik und Integrationen zügig und fehlerfrei umgesetzt werden können, benötigen wir vom Frontend und UX folgende, klar strukturierte Artefakte:

• Designspezifikation und Designsystem

  • Figma-Datei in finalem Stand mit:
  • Komponentenbibliothek (Buttons, Inputs, Cards, Navigation, Modale), inklusive Variants und Auto-Layout
  • Typografie-Skalen, Farbpalette inkl. Semantik (Primary, Secondary, Success, Warning, Error) und Zustandsfarben
  • Spacing-, Grid- und Elevation/Shadow-Tokens
  • Naming-Konventionen (Komponenten, Layer, Variants) und eine kurze Legende
  • Redlines/Measurements für Abstände und responsive Verhalten

• Breakpoints und responsives Verhalten

  • Verbindliche Breakpoints (z. B. 360/375, 768, 1024, 1280, 1440 px)
  • Darstellung für mindestens Mobile, Tablet, Desktop je Screen
  • Regeln für Container-Breiten, Fluid-Typografie und Bildverhältnisse
  • Strategien für Navigationen, Tabellen, Filter und komplexe Module auf kleinen Viewports

• Zustände und Interaktionen

  • UI-States: Default, Hover, Focus, Active, Disabled, Error, Success, Loading/Skeleton
  • Formularvalidierung (inline vs. on submit), Fehlermeldungstexte, Masken und Placeholders
  • Interaktive Prototypen für kritische Flows (z. B. Checkout, Login, Kontakt, Suche, Filter)

• Barrierefreiheit (WCAG 2.2 AA)

  • Kontrastnachweise für Text, Buttons und interaktive Elemente
  • Fokus-Reihenfolge und sichtbare Focus Styles
  • Semantische Struktur (Headings, Listen, Landmark-Rollen), Alt-Texte und Labels
  • Tastaturbedienbarkeit und Fallbacks für Animationen/Bewegung

• Assets und Inhalte

  • Bildquellen und Exportformate (bevorzugt WebP/AVIF, inkl. Fallback)
  • Icon-Set (SVG, einheitliche Stroke/Fill-Regeln)
  • Beispielinhalte und -texte für alle Content-Typen zur realistischen Entwicklung und Testdaten-Erzeugung

Diese Handover-Basis verhindert Interpretationsspielräume, verkürzt die Einarbeitung und senkt die Fehlerquote bei der Anbindung an CMS/Shop und externe Systeme.

Technische Spezifikation: CMS-Modelle, Shop-Workflows, Schnittstellen, Tracking und SEO

Neben dem visuellen Handover ist eine schriftliche, technische Spezifikation der Schlüssel für Geschwindigkeit und Qualität. Bewährt haben sich schlanke, klar versionierte Dokumente (z. B. pro Epik/Feature ein Spez-Dokument).

• Content-Modelle im CMS

  • Content-Typen inkl. Felder, Datentypen, Validierungen und Pflichtfelder
  • Beispiel: Blog-Artikel (Titel, Slug, Teaser, Hero-Bild, Autor-Relation, Body-Rich-Text, Tags, SEO-Fields)
  • Relationen (1:n, n:m), Referenzen und Sortierlogik
  • Modularer Aufbau (z. B. Sections/Blöcke: Text, Bild, Galerie, FAQ, Teaser-Grid)
  • Rollen- und Rechtekonzept für Redakteure
  • URL-Strategie, Slug-Generierung, Redirect-Regeln (301), Canonicals
  • Versionierung und Freigabe-Workflows (Entwurf, Review, Freigabe)

• Shop-Workflows

  • Produkttypen, Varianten, Attribute (Größe, Farbe), Preise, Preisregeln, inkl. Mehrwertsteuer (DE)
  • Lagerbestand, Reservierungslogik, Backorders
  • Warenkorb-, Checkout- und Zahlfluss (Zahlarten, SCA, Stornos, Refunds)
  • Versandarten, Zonen, Kosten, Lieferzeiten, Sendungsverfolgung
  • Retouren-/RMA-Prozess, Statusübergänge und Benachrichtigungs-E-Mails
  • Schnittstellen zu ERP/PIM/CRM (Datenfelder, Synchronisationshäufigkeit, Fehlertoleranz)

• Schnittstellen und Integrationen

  • API-Verträge (REST/GraphQL), Endpunkte, Authentifizierung, Rate Limits
  • Webhooks, Event-Schema und Retry-Strategie
  • Fehlerbehandlung, Logging, Monitoring und Alerting
  • Sandbox-/Testumgebungen und Test-Credentials

• Tracking, Consent und Datenschutz (DE)

  • Consent-Management-Plattform (z. B. Usercentrics, Cookiebot) oder individuelle Lösung gemäß DSGVO/TTDSG
  • Tag-Management (z. B. GTM, optional server-side), Event-Schema (Views, Clicks, E-Commerce-Events)
  • Consent-Kategorien und bedingtes Laden von Skripten
  • IP-Anonymisierung, Do-Not-Track-Respektierung, Datenaufbewahrungsfristen
  • Trennung von Staging- und Produktions-Properties

• SEO- und Performance-Anforderungen

  • Meta-Tags, OG/Twitter Cards, Schema.org-Markup (z. B. Product, Article, FAQ)
  • XML-Sitemaps, robots.txt, hreflang (falls Mehrsprachigkeit vorgesehen)
  • Paginierung, Canonicals, facettierte Navigation (Indexierungssteuerung)
  • Performance-Budgets und Core Web Vitals-Ziele (LCP, CLS, INP), Bildoptimierung, Caching/CDN
  • Saubere 404/410-Strategie und Redirect-Matrix beim Relaunch

Die technische Spezifikation sollte kompakt sein, aber keine Unklarheiten bei Datenstrukturen, Zuständigkeiten und Sicherheitsanforderungen lassen. Versionieren Sie Änderungen (Changelog) und referenzieren Sie stets die zugehörigen Figma-Frames und User-Flows.

Akzeptanzkriterien, Tickets, Sprints und QA: Klarheit für planbare Budgets

Ein gut gepflegtes Backlog ist die Basis für verlässliche Schätzungen und zügige Umsetzung. So strukturieren Sie Tickets, Definitionen und Qualitätssicherung:

• Ticket-Zuschnitt und Inhalte

  • Epics für größere Themen (z. B. „Checkout“) mit untergeordneten User Stories (z. B. „Als Kunde kann ich mich im Checkout anmelden“)
  • Pro Ticket: Ziel, Scope/Non-Scope, Figma-Links, Spez-Dokument, Beispielinhalte, Abhängigkeiten, Testdaten
  • Klare Priorität und Business Value für realistische Sprint-Planung

• Akzeptanzkriterien (bevorzugt in Gherkin-Form)

  • Beispiel:
  • Gegeben ein eingeloggter Kunde mit einem Artikel im Warenkorb
  • Wenn er die Zahlungsart „Rechnung“ auswählt und „Jetzt kaufen“ klickt
  • Dann wird die Bestellung angelegt, eine Bestellbestätigungsseite angezeigt und eine Bestätigungs-E-Mail versendet
  • Ergänzend: Edge Cases (leerer Warenkorb, Timeout, abgelehnte Zahlung), Barrierefreiheits- und Performance-Anforderungen

• Definition of Ready (DoR) und Definition of Done (DoD)

  • DoR: Figma final, Texte vorhanden, API-Verträge abgestimmt, Testdaten definiert, Abhängigkeiten geklärt
  • DoD: Akzeptanzkriterien erfüllt, Unit-/Integrationstests grün, Accessibility-Checks, Lighthouse ≥ definiertem Schwellenwert, Code-Review abgeschlossen, Dokumentation aktualisiert

• Sprint-Setup und Kommunikation

  • Sprintlänge 1–2 Wochen, Backlog Refinements, Sprint Planning, Demo/Review, Retrospektive
  • Gemeinsamer Slack-/Teams-Kanal, fester Ansprechpartner auf Agenturseite, klarer Eskalationspfad
  • Stundenreporting je Sprint; Budget-Transparenz auf Basis der vereinbarten Stundensätze (95 €/105 €)

• QA-Setup und Teststrategie

  • Testpyramide: Unit-, Integrations-, E2E-Tests für kritische Flows (z. B. Checkout)
  • Visuelle Regressionstests (z. B. Percy), manuelle Accessibility-Tests (Tastatur, Screenreader-Stichproben)
  • Cross-Browser-/Device-Tests für definierte Support-Matrix
  • UAT-Slots mit Ihrem Team auf Staging; klarer Bug-Template (Schritte, Erwartung, Ist-Zustand, Umgebung, Screenshots)

Diese Struktur reduziert Rückfragen, schafft Vorhersehbarkeit und stellt sicher, dass die gelieferten Inkremente fachlich und technisch abnahmereif sind.

Staging, Go-Live-Workflow und Zusammenarbeit in Teilprojekten

Ein belastbarer Delivery-Prozess verhindert Überraschungen am Launch-Tag und erleichtert parallele Arbeit mit Ihren eigenen Entwicklerteams.

• Umgebungen und Branching

  • Entwicklungs-, Staging- und Produktionsumgebung mit konsistenter Konfiguration
  • Branching-Strategie (z. B. trunk-based mit Feature-Branches), automatisierte Deployments (CI/CD)
  • Isolierte Secrets/Keys pro Umgebung; Staging stets mit realitätsnahen (anonymisierten) Daten

• Daten, Migrationen und Inhalte

  • Migrationsskripte versionieren und reproduzierbar testen
  • Content-Freeze-Fenster vor dem Go-Live, falls erforderlich
  • Redaktions-Checkliste: Inhalte vollständig, Medien optimiert, interne Links geprüft

• Go-Live-Checkliste

  • SEO: Redirect-Matrix aktiv, Canonicals korrekt, Sitemaps generiert und bei Bedarf neu eingereicht
  • Performance: Caching/CDN aktiv, Bildtransformationen, kritische Pfade geprüft, Core Web Vitals innerhalb Budget
  • Sicherheit: HTTPS/ HSTS, CSP, sichere Header, Admin-Zugänge gehärtet, Backups/Restore getestet
  • Tracking/Consent: CMP live, richtige Properties/Container, E-Commerce-Events geprüft
  • Monitoring: Logs, Uptime-Checks, Error-Alerts; Smoke-Tests nach Deployment
  • Rollback-Plan und Verantwortlichkeiten für das Release-Fenster

• Tipps für Teilprojekte mit eigenen Dev-Teams

  • Klare Verantwortungsgrenzen: z. B. Agentur-Frontend vs. JAR Media Backend/CMS/Integrationen
  • API-First: frühzeitige API-Definitionen und Mock-Server, damit Frontend parallel entwickeln kann
  • Gemeinsamer Code-Standard und Review-Prozess; optionales Pairing auf Schnittstellen-Features
  • Gemeinsames Issue-Tracking (Jira o. ä.) mit Labels pro Team; einheitlicher Bug-Workflow
  • Integrations-Umgebung („Sandbox“) für frühe E2E-Tests zwischen Frontend und Backend
  • Gemeinsame Demo-Termine: fachliche Abnahme durch das Agenturteam, technische durch JAR Media
  • Kapazitätsplanung und Eskalation: wer übernimmt Hotfixes, wer pflegt Abhängigkeiten
  • Bei Bedarf Berater-Slots (105 €/h) für Architektur- und Performance-Reviews, um spätere Umbauten zu vermeiden

Mit diesem Vorgehen wird der Übergang vom Figma-Entwurf zur produktiven, performanten Lösung reibungslos: weniger Rückfragen, belastbare Budgetplanung und schnellere, sichere Releases. Für Agenturen in Deutschland schafft ein strukturierter Handover die Grundlage, die Stärken der Frontend-Gestaltung und die technische Umsetzung im Backend effizient zusammenzuführen – genau dort, wo am Ende Qualität, Zeit und Kosten entschieden werden.