Dev Staging Production für Designer: Leitfaden 2026

Die meisten Designer lernen Entwicklung, Staging und Produktion kennen, indem sie etwas in der falschen Umgebung kaputtmachen. Ein Loom-Update wird verschickt. Ein Entwickler zuckt zusammen. Ein Thread auf Slack beginnt mit: „Moment mal, welche URL ist das?“ Das ist das gesamte Onboarding.

Diese Erklärung hättest du am ersten Tag bekommen sollen. Kein Fachjargon um des Fachs willen, kein Herumlavieren, sondern einfach die drei Umgebungen, wer in welcher arbeitet und was du als Designer dort tun sollst.

Wenn du jemals gefragt hast: „Ist das schon live?“, während du auf dem falschen Tab warst, ist dieses Dokument genau das Richtige für dich.

Warum es überhaupt drei Umgebungen gibt

Software hat ein Problem, das physische Produkte nicht haben. Sobald sie veröffentlicht ist, wird sie sofort und gleichzeitig an alle verteilt. Es gibt keine Produktionshalle, keinen Testmarkt, keine standardmäßige langsame Einführung. Eine fehlerhafte Änderung kann Millionen von Nutzern in der Zeit treffen, die zum Aktualisieren einer Seite benötigt wird.

Drei Umgebungen existieren, damit das Team Fehler machen kann, bevor die Nutzer sie bemerken. In der Entwicklungsumgebung (Dev) darf man sich noch richtig irren. In der Testumgebung (Staging) sind kleinere Fehler erlaubt. In der Produktionsumgebung (Production) darf man sich keine Fehler mehr erlauben, denn echte Menschen beobachten die Entwicklung.

Man kann sich das wie einen Artikel vorstellen, der drei redaktionelle Durchgänge durchläuft. Der erste Entwurf ist noch unfertig, die Druckfahnen sind größtenteils fehlerfrei, und das gedruckte Magazin wurde bereits von zehn Personen gelesen. Aus demselben Grund veröffentlicht niemand den ersten Entwurf, und niemand geht direkt in die Produktion.

Teams, die Phasen überspringen, tun dies, weil sie klein, schnell oder leichtsinnig sind. Manchmal trifft alles drei zu. Die Struktur ist so angelegt, dass das Team seine Leichtsinnigkeit überwinden kann, ohne dabei an Tempo einzubüßen.

Die Drei-Umgebungen-Übersicht

Bevor wir tiefer in die Materie einsteigen, hier die Übersicht, die Sie als Screenshot speichern können und nach der Sie nie wieder fragen müssen.

| Umgebung | Zweck | Zielgruppe | Daten | URL-Muster | Deployment-Trigger | Review-Stil |

|---|---|---|---|---|---|---|

| Dev | Frei entwickeln und Fehler beheben | Ein Entwickler, manchmal du | Gefälscht oder mit Seeding versehen, oft fehlerhaft | localhost:3000 oder deinname.dev.app | Lokale Codeänderungen | Pairing, Bildschirmfreigabe |

| Staging | Letzte Prüfung vor der Veröffentlichung | Internes Team, Designer, QA | Realistisch, anonymisiert, aktualisiert | staging.app.com oder pr-123.app.com | PR-Merge oder manueller Push | Asynchrone Überprüfung, Loom, Figma Vergleich |

| Produktion | Die Realität | Kunden, die ganze Welt | Real, sensibel, unwiderruflich | app.com | Getaggte Version oder Merge des Hauptzweigs | Monitoring, QA nach dem Launch |

Wenn du dir nur eine Zeile merken musst, dann die Datenzeile. Die Entwicklungsumgebung enthält Testdaten, die Staging-Umgebung realistische Daten und die Produktionsumgebung die Daten, die dich verklagen könnten, wenn du sie manipulierst. Behandle die drei Umgebungen entsprechend.

Entwicklung: Der Ort, an dem Entwickler arbeiten, wo Dinge absichtlich kaputtgehen

Entwicklung ist alles, was ein Entwickler auf seinem Laptop oder in einer persönlichen Cloud-Sandbox ausführt. Es wird üblicherweise als localhost bezeichnet. Es läuft auf dem Rechner des Entwicklers, kommuniziert mit einer simulierten Datenbank und ist immer nur für eine Person gleichzeitig zugänglich. Diese Umgebung sieht man so gut wie nie, und das ist auch gut so.

Wenn ein Entwickler sagt: „Es funktioniert auf meinem Rechner“, meint er die Entwicklungsumgebung. Dort funktioniert es oft nur, weil die Daten simuliert sind, die Netzwerkverbindung schnell ist und sonst nichts passiert. In der anderen Hälfte funktioniert es, weil die Entwicklung erst vor fünf Minuten abgeschlossen wurde und noch nicht unter realen Bedingungen getestet wurde.

Neue Komponenten tauchen auch zuerst in der Entwicklungsumgebung auf. Wenn Sie ein Kartenmuster in Figma übergeben haben, existiert es zum ersten Mal im echten Code in der Entwicklungsumgebung eines Entwicklers. Dieser wird Ihnen wahrscheinlich einen Screenshot oder ein Loom-Ergebnis von localhost schicken. Das ist der Rohling, nicht die finale Version.

In der Entwicklungsumgebung geht es nicht um Pixel-Optimierung. Sie überprüfen die Struktur, das Verhalten und die beabsichtigte Funktion. Pixel-Anmerkungen heben Sie sich für die Staging-Umgebung auf.

Staging: Die Generalprobe

Im Staging testet das Team seine Anwendung, bevor die Kunden sie sehen.

Die Staging-Umgebung läuft auf realer Infrastruktur mit realistischen Daten unter einer URL, die üblicherweise mit „staging“ vor der regulären Domain beginnt.

Alle Teammitglieder können die Staging-Umgebung einsehen, Kunden jedoch nicht.

Hier findet der Großteil der Designprüfung statt. Sie vergleichen die Anwendung mit der Datei Figma. Sie durchlaufen den Ablauf auf einem realen Gerät. Dabei achten Sie auf Dinge, die in Figma immer korrekt aussehen, im Code aber fehlerhaft sind: Zeilenhöhen, Fokuszustände, das Verhalten bei einem 40 Zeichen langen Namen oder das Verhalten bei fehlenden Daten.

Die Staging-Umgebung bildet die Produktionsumgebung so genau wie möglich ab. Gleiche Datenbankstruktur, gleiche Drittanbieterdienste im Testmodus, gleiche Feature-Flags, gleicher Authentifizierungsablauf. Je näher die Staging-Umgebung an der Produktionsumgebung ist, desto weniger Überraschungen gibt es bei der Veröffentlichung. Teams, die die Staging-Umgebung vom Produktivsystem entfernen, liefern am Ende Fehler aus, die sie hätten kostenlos beheben können.

In der Staging-Umgebung finden Sie auch heraus, ob der Entwickler Ihr Design so interpretiert hat, wie Sie es beabsichtigt haben. In der Hälfte der Fälle ist dies der Fall. In der anderen Hälfte beginnt die eigentliche Kommunikation.

Produktion: Hier arbeiten echte Menschen

Die Produktion ist die Live-Website. Sie ist das, was Ihre Kunden sehen, wenn sie Ihre URL in einen Browser eingeben. Sie läuft auf einer realen Infrastruktur mit echten Daten, echtem Geldfluss und realen Konsequenzen für jede Änderung. Wenn Sie sich durch die Website klicken, interagieren Sie mit demselben System wie Ihre Benutzer.

In dieser Umgebung hören Sie auf, Designer zu sein, und werden zum Gast. Sie klicken nicht in der Produktion herum, um Ideen zu testen. Sie probieren keine Dinge aus. Sie melden sich nicht als Testbenutzer an, um zu sehen, was passiert, denn in der Produktion gibt es keine Testbenutzer, sondern nur echte Benutzer mit echten Datensätzen, die Sie versehentlich beschädigen können.

Die Produktion dient der Überwachung, Stichproben nach einem Deployment und dem Erstellen von Screenshots von bereits live befindlichen Funktionen. Wenn Sie etwas testen müssen, kehren Sie zur Staging-Umgebung zurück. Falls die Staging-Umgebung das gewünschte Ergebnis nicht anzeigt, fordern Sie eine Vorschau an. Die Produktionsumgebung wird nicht beeinträchtigt.

Der Reifegrad eines Teams zeigt sich darin, wie konsequent diese Regel befolgt wird. Junior-Teams arbeiten ständig in der Produktionsumgebung. Erfahrene Teams behandeln sie wie einen Reinraum.

Der Lebenszyklus einer einzelnen Änderung

Eine einzelne Designänderung durchläuft alle Umgebungen, bevor sie einem Benutzer angezeigt wird. Dieses Wissen um den Lebenszyklus unterscheidet Designer, die Entwickler frustrieren, von solchen, die sie begeistern.

So läuft eine Änderung konkret ab:

1. Sie übergeben das Design in Figma mit Anmerkungen, Zuständen und Sonderfällen.

2. Ein Entwickler lädt die Änderung in seine Entwicklungsumgebung und erstellt sie lokal.

Anschließend wird die Arbeit für das Team freigegeben:

3. Das Team erstellt einen Pull Request, der eine Vorschau-Bereitstellung mit einer eindeutigen URL startet.

4. Sie überprüfen die Vorschau, hinterlassen Kommentare, fordern Änderungen an und genehmigen die Änderung.

Und schließlich erreicht es die Nutzer:

5. Der Pull Request wird zusammengeführt und die Änderung zur letzten Teamprüfung in die Staging-Umgebung übertragen.

6. Nach der Freigabe in der Staging-Umgebung wird die Änderung in die Produktionsumgebung übertragen und ist für die Nutzer sichtbar.

Schritte drei und vier sind der entscheidende Vorteil. Dank Preview-Deployments müssen Sie nicht mehr auf die Staging-Umgebung warten, um Ihre Arbeit im Code zu sehen. Sie sehen sie sofort, sobald der Entwickler seinen Branch pusht. Früher war das ein Luxus, heute ist es Standard.

Wenn Ihr Team noch keine Preview-Deployments nutzt, ist das die wirkungsvollste Neuerung, die es einführen könnte. Setzen Sie sich dafür ein.

Preview-Deployments haben alles verändert

Vor zehn Jahren bedeutete eine Designprüfung entweder, schnell zum Entwickler zu fahren oder bis zum Staging-Push am nächsten Dienstag zu warten. Heute vergibt jede moderne Hosting-Plattform für jeden Pull Request eine eigene URL. BRAND6 nennt sie Preview-Deployments, Netlify nennt sie Deploy-Previews, und Render, Cloudflare und AWS Amplify bieten ähnliche Funktionen.

Das bedeutet in der Praxis: Jeder Branch, jeder Pull Request (PR), jede Änderung, die gerade bearbeitet wird, hat eine interaktive URL, die Sie sofort überprüfen können. Der Entwickler pusht seinen Branch, der Preview-Build ist in zwei Minuten fertig, und ein Bot fügt die URL automatisch in den PR ein. Sie klicken darauf, überprüfen die URL, kommentieren sie und können weitermachen.

Preview-Deployments verkürzen den Design-Review-Zyklus von Tagen auf Minuten. Außerdem werden Loom-Videos dadurch deutlich überflüssiger, da eine Preview-URL ein interaktives Loom-Video ist. Falls Sie diese Funktion noch nicht nutzen, bitten Sie Ihren Entwickler, Ihnen den Bot-Kommentar zu einem offenen PR zu zeigen. Der Link ist direkt dort zu finden.

Wichtige Hinweise zu Previews: Sie werden mit Staging- oder Testdaten ausgeführt, niemals mit Produktionsdaten. Sie sind temporär und werden nach dem Schließen des PRs gelöscht. Jeder Branch hat seine eigene URL, sodass Sie zehn davon gleichzeitig für zehn verschiedene Funktionen geöffnet haben können.

Umgebungsvariablen, Konfigurationen und warum der „Testmodus“ angezeigt wird

Jede Umgebung führt denselben Code aus, kommuniziert aber mit unterschiedlichen Diensten. Die Entwicklungsumgebung (Dev) verwendet eine Testdatenbank, die Staging-Umgebung eine Staging-Datenbank und die Produktionsumgebung die Live-Datenbank. Jede Umgebung verwendet außerdem unterschiedliche Versionen von Drittanbieter-Tools: Stripe im Testmodus in der Entwicklungs- und Staging-Umgebung, Stripe im Live-Modus in der Produktionsumgebung. Dasselbe gilt für E-Mail-Versender, Analysetools, Authentifizierung und alle externen Abhängigkeiten.

Teams behalten mithilfe von Umgebungsvariablen, auch Konfigurationen oder Secrets genannt, den Überblick. Dies sind kleine, benannte Werte wie DATABASE_URL oder STRIPE_KEY, die sich je nach Umgebung ändern. Tools wie Doppler, Vercel-Umgebungsvariablen, AWS Secrets Manager oder 1Password Connect verwalten diese.

Warum das für Sie als Designer wichtig ist: Wenn Sie sehen, dass Stripe Testkartennummern in der Staging-Umgebung anzeigt, ist das der Staging-Schlüssel Stripe. Wenn Sie Ihr eigenes Entwicklerprofilbild, aber eine komplett fiktive Kreditkarte in der Entwicklungsumgebung sehen, greift die Entwicklungsumgebung auf eine Testdatenbank zu, verwendet aber eine echte Clerk-Authentifizierung. Wenn etwas in der Staging-Umgebung funktioniert, aber in der Produktionsumgebung nicht, liegt es in 90 % der Fälle an einer fehlenden oder abweichenden Umgebungsvariablen.

Sie müssen diese Variablen nicht verwalten. Sie müssen nur wissen, dass sie existieren, damit Sie verstehen, was ein Entwickler meint, wenn er sagt: „Moment, das verwendet den Produktionsschlüssel Stripe, klicken Sie nicht auf diese Schaltfläche.“

Datenparität: Was Sie tatsächlich sehen werden

Die Daten in jeder Umgebung bestimmen, was Sie testen können und was nicht. Das ist der Punkt, den Designer am häufigsten übersehen.

Die Entwicklungsumgebung (Dev) enthält üblicherweise Testdaten – eine kleine Anzahl von simulierten Benutzern, Produkten und vielem mehr. Diese Daten werden oft jeden Morgen neu befüllt. Die Namen sind albern, die Adressen stammen aus Springfield und die Avatare sind winzige graue Quadrate. Versuchen Sie nicht, leere Zustände oder Grenzfälle anhand dieser Daten zu bewerten, da sie für den Normalfall optimiert wurden.

Die Staging-Umgebung enthält in der Regel entweder anonymisierte Produktionsdaten oder einen sorgfältig zusammengestellten, realistischen Datensatz. Reale Formen, Längen und Grenzfälle – aber Namen und E-Mail-Adressen sind entfernt. Hier sehen Sie, wie Ihre Designs mit einem Kunden namens Christopher Hassan-Williamson III. oder einer Bestellung mit 63 Positionen aussehen. Nur hier können Sie echte Design-Qualitätssicherung betreiben.

Die Produktionsumgebung enthält echte Daten. Genau deshalb sollten Sie diese nicht manipulieren. Sie können zwar Momentaufnahmen und Dashboards verwenden, aber die Produktionsumgebung sollte niemals als Testumgebung dienen.

Die Rolle des Designers in jeder Umgebung

Am einfachsten lässt sich Ihre Arbeit in jeder Umgebung strukturieren, indem Sie sich jeweils eine andere Rolle zuweisen.

In der Entwicklungsumgebung sind Sie ein Teammitglied. Sie führen kurze Check-ins per Bildschirmfreigabe durch, stellen sicher, dass der Entwickler das Design verstanden hat, und erkennen frühzeitig größere strukturelle Probleme. In der Entwicklungsumgebung markieren Sie nichts, da der Entwickler noch an der Implementierung arbeitet.

In der Staging-Umgebung sind Sie für die Qualitätssicherung des Designs zuständig. Sie vergleichen mit der Datei „BRAND5“, überprüfen die Status und erstellen die Mängelliste. Hier führen Sie Ihre detaillierte Überprüfung durch, hinterlassen strukturierte Kommentare und genehmigen oder blockieren die Änderung. Die Staging-Umgebung ist Ihr Bereich.

In der Produktionsumgebung sind Sie ein Gast. Sie überprüfen die ausgelieferte Änderung, erstellen einen Screenshot und analysieren die Daten, falls dies zu Ihren Aufgaben gehört. In der Produktionsumgebung klicken Sie nicht einfach herum, um Dinge zu testen, und probieren auch nicht „mal kurz etwas aus“.

Wenn Sie sich diese drei Rollen verinnerlichen, werden Sie einer der umgänglichsten Designer sein, mit denen Ihr Entwicklungsteam je zusammengearbeitet hat.

Die häufigsten Fehler von Designern

Ich habe schon viele Designer diese Fehler machen sehen. Einige davon habe ich selbst auch schon begangen. Keiner davon ist weltbewegend, aber sie alle bremsen das Team aus und schaden der Stimmung im Entwicklerteam.

Die Klassiker:

• Eine Entwickler-URL an einen Kunden senden. Die Entwicklung läuft auf dem Laptop eines Kollegen, der Kunde klickt auf den Link, erhält eine Fehlermeldung und fragt, ob überhaupt etwas veröffentlicht wird.

• Einen „Live-Bug“ aus einem veralteten CDN-Cache melden. Man sieht eine Version, die vor sechs Stunden zwischengespeichert wurde, und ein vollständiges Neuladen behebt das Problem.

Die nächste Fehlergruppe entsteht durch Verwirrung darüber, was wo live ist:

• Einen Bug für etwas melden, das bereits in der Staging-Umgebung behoben ist. Man schaut in die Produktionsumgebung, sieht die alte Version und meldet panisch Slack. Die Korrektur ist seit einer Woche in der Staging-Umgebung verfügbar.

• Keine Vorschau anfordern. Sie warten drei Tage, bis die Änderungen in der Staging-Umgebung verfügbar sind, obwohl der Entwickler Ihnen direkt nach dem Deployment eine Vorschau-URL hätte schicken können.

Die letzten beiden Punkte betreffen die Einhaltung der Grenze zwischen Staging- und Produktionsumgebung:

• Durch die Produktionsumgebung klicken, um etwas zu „testen“. Sie sind jetzt ein echter Benutzer mit echten Konsequenzen – also lassen Sie es.

• Fragen: „Ist das schon live?“, anstatt das Deployment-Log zu prüfen. Die meisten Teams haben einen Kanal namens „BRAND17“, in dem jedes Deployment veröffentlicht wird. Speichern Sie ihn am besten in Ihren Lesezeichen.

Jeder dieser Fehler lässt sich mit einem einzigen Satz beheben, sobald man die Lösung kennt. Nichts davon ist dumm. Es sind einfach Dinge, die Ihnen niemand gesagt hat.

IMG3

Wie Sie nach dem fragen, was Sie brauchen

Die Kehrseite der Medaille ist die richtige Etikette. In der Kommunikation zwischen Designern und Entwicklern über Umgebungen geht es vor allem darum, präzise zu sein. Vage Anfragen kosten Zeit, präzise Anfragen kosten nichts.

Schlecht: „Hey, könntest du das neue Kartendesign irgendwo hochladen, wo ich es mir ansehen kann?“

Gut: „Hey, könntest du deinen Branch für das Kartendesign hochladen und mir die Vorschau-URL schicken, sobald er fertig ist?“

Schlecht: „Ist das Homepage-Update schon live?“

Gut: „Ist PR 412 schon in der Produktion oder noch in der Staging-Umgebung?“

Schlecht: „Irgendetwas scheint auf der Live-Seite nicht zu funktionieren.“

Gut: „In der Produktion fehlt bei mir der unteren Rahmen der Preiskarte unter /pricing. Auch nach einem Hard-Refresh besteht der Fehler. Screenshot ist angehängt.“

Das Muster ist in jedem Beispiel dasselbe: Umgebung und Änderung benennen, Nachweis liefern. Entwickler setzen alles daran, Designern mit solchen Anfragen zu helfen. Diejenigen, die das nicht tun, werden ihnen insgeheim übelgenommen.

Feature Flags: Staging in der Produktion

Es gibt ein viertes Konzept, das das Dev/Staging/Prod-Modell auf sinnvolle Weise aufbricht: Feature Flags. Ein Feature-Flag ist ein Schalter im Code, der besagt: „Zeige diese neue Funktion Benutzer X, aber nicht Benutzer Y.“ Teams verwenden Feature-Flags, um Code in die Produktion zu bringen und die neue Funktion gleichzeitig nur einer kleinen Gruppe von Benutzern, oft internen Mitarbeitern, zugänglich zu machen.

Tools wie LaunchDarkly, Statsig, ConfigCat und die eigenen Flags von Vercel ermöglichen dies. Das neue Design ist technisch gesehen bereits in der Produktion verfügbar, aber nur die Benutzer mit dem internen Flag sehen es. Alle anderen sehen die alte Version.

Dies ist für Sie relevant, da die Antwort auf die Frage „Ist das live?“ dadurch unklarer wird. Der Code ist live, die Funktion jedoch möglicherweise noch nicht. Daher müssen Sie gegebenenfalls den Entwickler bitten, das Flag für Ihr Konto zu aktivieren. Oder er sagt: „Die Funktion ist bereits veröffentlicht, aber nur durch ein Flag geschützt. Wir schalten sie am Dienstag für alle frei.“

Feature-Flags ermöglichen es erfahrenen Teams, kontinuierlich Updates zu veröffentlichen, ohne Probleme für alle Benutzer zu verursachen. Sie ermöglichen außerdem, das Äquivalent einer Staging-Review mit echten Produktionsdaten und echten Benutzern bei geringem Risiko durchzuführen.

Was die einzelnen Umgebungen über das Team aussagen

Die Art und Weise, wie ein Team mit diesen drei Umgebungen umgeht, verrät fast alles über seine technische Reife. Nutzen Sie dies als Kurzübersicht für jeden neuen Kunden oder jede neue Rolle.

Ein Team ohne Staging-Umgebung arbeitet schnell und hofft auf Erfolg. Irgendwann wird es auf einen Fehler stoßen, der es einen Kunden kostet, und dann wird es eine Staging-Umgebung einrichten.

Ein Team mit Staging-Umgebung, aber ohne Preview-Deployments, befindet sich in der Mitte. Reviews sind langsam, der Zyklus von „Fertig“ bis „Designer kann es sich ansehen“ dauert Tage, und Sie werden viel Zeit mit Warten verbringen.

Ein Team mit Preview-Deployments, einer echten Staging-Umgebung, überwachter Produktion und Feature-Flags arbeitet auf dem gewünschten Niveau. Feedbackschleifen sind kurz, Fehler werden frühzeitig erkannt, und niemand gerät am Launch-Tag in Panik. Wenn Sie dort gearbeitet haben, wirken die anderen Stufen anstrengend.

Drei Umgebungen, drei Zielgruppen, drei Datensätze, ein Lebenszyklus, der sie verbindet. Das ist das gesamte Konzept. Alles andere ist zusätzliches Werkzeug.

Sie müssen weder Code bereitstellen noch ein Vercel-Konto verwalten. Sie müssen lediglich wissen, in welcher Umgebung Sie sich befinden, welche Berechtigungen Sie dort haben und wie Sie die richtige URL anfordern. Damit werden Sie zum Designer, mit dem Ihre Entwickler gerne zusammenarbeiten.

Speichern Sie das Bereitstellungsprotokoll, fordern Sie den Vorschaulink an und greifen Sie nicht mehr in die Produktionsumgebung ein.