Von Figma zur fertigen Website: So gelingt die Übergabe an externe Development-Partner

Wenn eine Agentur ein Webdesign, einen Onlineshop oder ein digitales Produkt an einen externen Development-Partner übergibt, entscheidet sich der Projekterfolg selten erst in der Programmierung. Entscheidend ist vielmehr, ob die Übergabe strukturiert, vollständig und für beide Seiten eindeutig erfolgt. Gerade wenn Design-, Marketing- oder Werbeagenturen die Konzeption, Gestaltung und Kundenkommunikation übernehmen und ein externer Programmier-Dienstleister die technische Umsetzung verantwortet, braucht es eine gemeinsame Arbeitsgrundlage.

Figma-Dateien allein reichen dafür nicht aus. Ein sauberes Layout ist wichtig, aber Entwickler benötigen zusätzlich Informationen darüber, wie sich Komponenten verhalten, welche Inhalte später im CMS gepflegt werden sollen, welche Integrationen angebunden werden müssen und nach welchen Qualitätskriterien die Umsetzung abgenommen wird. Je weniger Interpretationsspielraum besteht, desto geringer sind Rückfragen, Nacharbeiten und Budgetabweichungen.

Für Agenturen bedeutet das: Die Übergabe sollte als eigener Projektschritt geplant werden. Idealerweise gibt es vor Entwicklungsbeginn einen gemeinsamen Kick-off, in dem Design, Funktionalität, technische Anforderungen, Prioritäten, offene Fragen und Verantwortlichkeiten abgestimmt werden. Dabei sollte klar definiert sein, welche Leistungen der Development-Partner vollständig übernimmt und welche Aufgaben bei der Agentur bleiben – etwa Content-Pflege, finale SEO-Texte, Tracking-Freigaben oder Kundenfeedback.

Besonders wichtig ist diese Klarheit bei White-Label-Projekten oder Teilprojekten. Wenn der externe Dienstleister nicht direkt gegenüber dem Endkunden auftritt, müssen Kommunikationswege, Reaktionszeiten und Freigabeprozesse eindeutig geregelt sein. So vermeiden Sie, dass Informationen verloren gehen oder Entscheidungen verzögert werden.

2. Diese Artefakte sollten vor Entwicklungsstart bereitstehen

Eine professionelle Übergabe besteht aus mehreren Bausteinen. Je vollständiger diese Artefakte vorliegen, desto zuverlässiger kann ein Development-Partner Aufwand, Timing und technische Risiken einschätzen.

Designsystem und Figma-Struktur:
Die Figma-Datei sollte sauber organisiert sein. Dazu gehören benannte Seiten, Frames, Varianten und Komponenten. Wichtig sind außerdem Design-Tokens für Farben, Typografie, Abstände, Schatten, Radien und Zustände. Wenn bereits eine Komponentenbibliothek existiert, sollte sie vollständig dokumentiert sein: Buttons, Formulare, Navigationen, Karten, Teaser, Modale, Tabs, Slider und weitere UI-Elemente sollten inklusive Hover-, Fokus-, Fehler- und Disabled-Zuständen vorliegen.

Responsive Breakpoints:
Neben Desktop-Designs sollten auch Tablet- und Mobile-Ansichten definiert sein. Es muss erkennbar sein, wie Layouts zwischen Breakpoints reagieren: Welche Elemente umbrechen, verschwinden, sticky werden oder ihre Reihenfolge ändern. Empfehlenswert ist eine klare Breakpoint-Tabelle, zum Beispiel für Mobile, Tablet, Small Desktop und Large Desktop. Falls Zwischenzustände nicht gestaltet sind, sollte beschrieben werden, ob Entwickler diese eigenständig ableiten dürfen oder ob Rücksprache erforderlich ist.

Funktionsmatrix:
Eine Funktionsmatrix hilft, Design und technische Umsetzung zusammenzuführen. Sie beschreibt pro Modul oder Seite, welche Funktion erwartet wird. Beispiele: Formular mit Validierung und Double-Opt-in, Produktfilter mit Mehrfachauswahl, Login-Bereich, Warenkorb, Gutscheinlogik, Merklistenfunktion oder Newsletter-Anbindung. Je konkreter diese Funktionen beschrieben sind, desto besser lassen sich Aufwand und Testbarkeit bewerten.

Content-Model und CMS-Felder:
Wenn die Website später von Agentur oder Endkunde gepflegt werden soll, ist ein durchdachtes Content-Model unerlässlich. Es sollte definiert sein, welche Inhaltstypen, Felder und Wiederholgruppen benötigt werden. Dazu zählen beispielsweise Überschrift, Subheadline, Bild, Alt-Text, CTA, Rich-Text, Download, Video, Kategorie, Veröffentlichungsdatum oder SEO-Metadaten. Auch Einschränkungen sind relevant: maximale Zeichenlängen, Pflichtfelder, erlaubte Dateiformate oder Bildformate.

SEO- und Tracking-Plan:
Technische SEO-Anforderungen sollten nicht erst kurz vor Go-live geprüft werden. Benötigt werden Angaben zu URL-Strukturen, Meta Titles, Meta Descriptions, Canonicals, Weiterleitungen, robots.txt, XML-Sitemap, hreflang, strukturierte Daten und Ladezeiten. Für Tracking sollten Tools, Events und Consent-Anforderungen beschrieben sein, etwa Google Tag Manager, Matomo, Meta Pixel, Conversion-Events, Formular-Events oder E-Commerce-Tracking.

Performance und Accessibility:
Definieren Sie frühzeitig Zielwerte, etwa für Core Web Vitals, Bildoptimierung, Caching, Lazy Loading und minimale JavaScript-Last. Ebenso wichtig sind Anforderungen an Barrierefreiheit nach WCAG oder BITV, insbesondere bei öffentlichen Auftraggebern oder Projekten mit hohen Compliance-Anforderungen. Dazu gehören Tastaturbedienbarkeit, Fokuszustände, Kontraste, semantische HTML-Struktur, Screenreader-Kompatibilität, Alt-Texte, Formularlabels und verständliche Fehlermeldungen.

Integrationen:
Externe Systeme müssen besonders sauber beschrieben werden. Bei Shops betrifft das Produktdaten, Varianten, Lagerbestände, Preise, Steuern, Versandarten, Gutscheine und Checkout-Prozesse. Bei Payment-Anbindungen sind Anbieter, Zahlungsarten, Testzugänge, Webhooks und Fehlerfälle relevant. CRM-, ERP-, PIM- oder Newsletter-Integrationen sollten inklusive Datenflüssen, Schnittstellen, Authentifizierung, Feldmapping und Verantwortlichkeiten dokumentiert werden.

3. Akzeptanzkriterien, Testfälle und Abnahme sauber formulieren

Damit ein Projekt nicht auf Basis subjektiver Eindrücke bewertet wird, sollten Anforderungen in überprüfbare Akzeptanzkriterien übersetzt werden. Statt „Das Kontaktformular soll funktionieren“ ist eine präzise Beschreibung sinnvoll: „Wenn ein Nutzer alle Pflichtfelder korrekt ausfüllt und die Datenschutzhinweise bestätigt, wird das Formular versendet, eine Erfolgsmeldung angezeigt, eine E-Mail an die definierte Adresse gesendet und der Eintrag im CRM angelegt.“

Gute Akzeptanzkriterien sind eindeutig, testbar und vollständig. Sie beschreiben Bedingungen, Aktionen und erwartete Ergebnisse. Besonders hilfreich ist das Schema: „Gegeben ist … Wenn … Dann …“. Beispiel: „Gegeben ist ein Produkt mit Varianten. Wenn der Nutzer eine Größe auswählt, dann aktualisiert sich die Verfügbarkeit entsprechend der hinterlegten Lagerdaten.“ Auf diese Weise wird aus einer allgemeinen Funktion eine konkret prüfbare Anforderung.

Ergänzend sollten Testfälle definiert werden. Diese sollten nicht nur den Idealfall abdecken, sondern auch Fehler- und Grenzfälle. Bei Formularen wären das leere Pflichtfelder, ungültige E-Mail-Adressen, nicht bestätigte Checkboxen oder Serverfehler. Bei Shops gehören fehlgeschlagene Zahlungen, ausverkaufte Produkte, ungültige Gutscheincodes oder abgebrochene Checkouts dazu.

Für die Abnahme empfiehlt sich ein klarer Prozess. Legen Sie fest, wer testet, in welchem Zeitraum Feedback gegeben wird und wie Fehler klassifiziert werden. Kritische Fehler blockieren den Go-live, während kleinere Darstellungsabweichungen gegebenenfalls nachgelagert behoben werden können. Wichtig ist auch, zwischen Bug, Änderungswunsch und Erweiterung zu unterscheiden. Ein Bug liegt vor, wenn eine vereinbarte Anforderung nicht erfüllt wird. Ein Änderungswunsch entsteht, wenn sich Anforderungen nachträglich ändern oder erweitern. Diese Unterscheidung ist besonders im Stundenmodell entscheidend für faire Budgetsteuerung.

4. Workflows, Verantwortlichkeiten und Budget im Stundenmodell

Ein reibungsloser Projektablauf hängt stark vom operativen Setup ab. Bewährt hat sich die Arbeit mit einem Ticketsystem wie Jira, GitLab, GitHub oder einem vergleichbaren Tool. Anforderungen sollten dort als Epics, User Stories oder Tasks gepflegt werden. Jedes Ticket sollte eine klare Beschreibung, Akzeptanzkriterien, relevante Designs, Abhängigkeiten und Priorität enthalten.

Eine gemeinsame Definition of Ready stellt sicher, dass Aufgaben erst dann in die Entwicklung gehen, wenn alle notwendigen Informationen vorliegen. Dazu zählen vollständige Designs, geklärte Funktionen, vorhandene Inhalte oder Platzhalter, Schnittstelleninformationen und Abnahmekriterien. Die Definition of Done beschreibt wiederum, wann eine Aufgabe abgeschlossen ist: Code umgesetzt, getestet, responsiv geprüft, barrierearme Anforderungen berücksichtigt, Review durchgeführt, auf Staging bereitgestellt und dokumentiert.

Für die Code-Zusammenarbeit ist ein Git-Workflow sinnvoll. Häufig bewährt sind Feature-Branches, Pull Requests, Code Reviews und getrennte Branches für Entwicklung, Staging und Produktion. Dadurch bleibt nachvollziehbar, welche Änderungen wann umgesetzt wurden. Außerdem reduziert ein strukturierter Review-Prozess technische Risiken und verbessert die Qualität.

Ebenso wichtig ist ein Staging- und Produktions-Setup. Die Staging-Umgebung sollte dem Live-System möglichst ähnlich sein, damit Tests realistische Ergebnisse liefern. Hier können Agentur und Endkunde Inhalte prüfen, Funktionen testen und Feedback geben. Der Go-live sollte geplant erfolgen: inklusive Deployment-Zeitfenster, Backup, Redirect-Prüfung, DNS-Themen, Tracking-Test, Formular-Test, Shop-Testbestellung und finaler Performance-Kontrolle.

Bei agiler Zusammenarbeit haben sich regelmäßige Sprint- und Review-Rhythmen bewährt. Je nach Projektgröße können ein- oder zweiwöchige Sprints sinnvoll sein. Kurze Abstimmungen helfen, offene Fragen schnell zu klären. Reviews auf Staging ermöglichen der Agentur, Zwischenergebnisse früh zu prüfen und gegebenenfalls gegenzusteuern. So werden Abweichungen nicht erst am Projektende sichtbar.

Für die Budgetierung im Stundenmodell ist Transparenz entscheidend. Eine Budget- und Kostenschätzung sollte nach Modulen, Funktionen oder Arbeitspaketen gegliedert sein. Sinnvoll sind Aufwandsspannen, weil gerade bei Integrationen, individuellen Funktionen oder unvollständigen Anforderungen Unsicherheiten bestehen können. Agenturen profitieren davon, wenn klar sichtbar ist, welche Annahmen der Schätzung zugrunde liegen und welche Punkte als Risikofaktoren gelten.

Auch laufendes Budget-Controlling sollte vereinbart werden. Regelmäßige Statusberichte mit verbrauchten Stunden, Restbudget, offenen Aufgaben und potenziellen Mehrwänden schaffen Vertrauen. Wenn zusätzliche Anforderungen entstehen, sollten diese vor Umsetzung kurz bewertet und freigegeben werden. So behalten Sie als Agentur die Kontrolle gegenüber Ihrem Endkunden und vermeiden unangenehme Überraschungen.

Gerade bei Teilprojekten ist eine klare Verantwortungsmatrix hilfreich. Wer liefert Inhalte? Wer prüft SEO? Wer erstellt Tracking-Konzepte? Wer kommuniziert mit Hosting-Anbietern? Wer gibt Designs frei? Wer nimmt Funktionen ab? Eine einfache RACI-Matrix mit Verantwortlichen, Mitwirkenden und Freigebenden kann Missverständnisse deutlich reduzieren.

Wenn Design, Anforderungen, Workflows und Abnahmeprozesse sauber ineinandergreifen, wird die Zusammenarbeit mit einem externen Development-Partner planbar und effizient. Für Agenturen entsteht dadurch ein verlässlicher Prozess: Sie behalten Kundenbeziehung, Strategie und Gestaltungshoheit, während die technische Umsetzung professionell, transparent und termingerecht erfolgt. So wird aus einer Figma-Datei nicht nur eine optisch ansprechende Website oder ein Onlineshop, sondern ein stabiles digitales Produkt, das bereit für den Go-live ist.