Wer 2012 ein digitales Produkt bauen wollte, brauchte mindestens zwei getrennte Teams: Designer, die die Vision entwarfen, und Entwickler, die sie Wirklichkeit werden ließen. Die Übergabe dazwischen war eine Quelle ständiger Reibung, Missverständnisse und Verzögerungen.
Spulen wir vor ins Jahr 2026: Diese Trennung ist fast vollständig verschwunden. Eine einzelne Person mit den richtigen Tools kann heute Software in Produktionsqualität konzipieren, gestalten und ausliefern, in Tagen statt Monaten.
Dieser Artikel zeichnet diese Entwicklung über sieben Epochen nach. Er beleuchtet die Tools, Methoden und kulturellen Veränderungen, die die Grenze zwischen Design und Entwicklung nach und nach aufgelöst haben.
Diese Geschichte zu verstehen ist nicht bloß akademisch. Sie ist wichtiger Kontext für alle, die heute digitale Produkte bauen. Die Tools und Workflows jeder Epoche sind nicht verschwunden, sie haben sich übereinandergelegt. Die effektivsten Teams von heute bedienen sich bei allen.
2012: Die scharfe Trennung
2012 war der Workflow zwischen Design und Entwicklung schmerzhaft linear. Designer arbeiteten in Adobe Photoshop oder Illustrator und erstellten pixelgenaue Mockups jedes Screens. Das waren statische Bilder, ohne Interaktionen, ohne Zustände, ohne Responsivität.
Die „Übergabe“ war genau das, wonach sie klingt: Designer reichten den Entwicklern einen Ordner voller PSD-Dateien, ein PDF mit Spezifikationen und, wenn sie gründlich waren, einen Styleguide. Die Entwickler bauten dann alles von Grund auf in Code nach und maßen sich dabei Pixel für Pixel durch den Prozess.
Die Probleme dieses Workflows waren gut dokumentiert: Entwürfe, die in Photoshop perfekt aussahen, ließen sich angeblich „unmöglich“ umsetzen. Entwickler trafen Ermessensentscheidungen zu Interaktionen, die Designer nie spezifiziert hatten. Die Lücke zwischen Design und ausgeliefertem Produkt war oft peinlich groß.
Das Double-Diamond-Framework von IDEO (Discover, Define, Develop, Deliver) war die vorherrschende Methode. Design war ausdrücklich von der Entwicklung getrennt: Erst wurde das Problem erforscht und definiert, dann ging es zur Umsetzung.
Agile und Scrum setzten sich gerade als Entwicklungsmethoden durch, aber es waren eben Entwicklungsmethoden. Design sollte vor den Sprints stattfinden, in einem „Design Sprint Zero“, der Assets für die Entwickler lieferte.
Die Grundannahme war, dass Design kreative Arbeit ist und Entwicklung technische Arbeit, und dass dafür unterschiedliche Menschen mit unterschiedlichen Fähigkeiten nötig sind.
Ressourcen
- Design Council: The Double Diamond: Das ursprüngliche Framework, das den Designprozess ein Jahrzehnt lang prägte
2014-16: Die Brückenbauer
Der Frust über die Übergaben zwischen Design und Entwicklung brachte eine ganze Kategorie von „Brücken“-Tools hervor. InVision (2011), Zeplin (2015) und Marvel (2013) gingen alle dasselbe Problem an: Wie vermittelt man Designabsichten effektiver an Entwickler?
Sketch (2010, aber ab 2014 dominant) veränderte das Fundament. Anders als Photoshop wurde Sketch speziell für UI-Design gebaut. Es führte Symbole (wiederverwendbare Komponenten), Artboards (Screens) und ein Plugin-Ökosystem ein, das es mit allem verband.
Mit InVision konnten Designer ihre Sketch-Dateien hochladen und klickbare Prototypen erstellen. Zum ersten Mal konnten Stakeholder durch eine „echte“ App tippen, bevor eine Zeile Code geschrieben war. Entwickler konnten Designs inspizieren, CSS-Eigenschaften kopieren und Assets direkt herunterladen.
Zeplin ging weiter: Es generierte automatisch Code-Snippets, Abstandsmaße und Farbwerte. Der Traum war eine „pixelgenaue“ Übergabe ohne jede Unklarheit.
Aber diese Tools hatten eine grundlegende Grenze: Sie gingen weiterhin von einem linearen Prozess aus. Erst passierte Design. Dann die Übergabe. Dann die Entwicklung. Die Brücke war besser, aber sie verband immer noch zwei getrennte Welten.
Handoff-Tools verringerten die Reibung, beseitigten aber nicht die grundlegende Trennung. Die Grenze zwischen Design und Entwicklung blieb bestehen, sie hatte nur bessere Übergänge.
Ressourcen
- InVision: How we changed design: Der Rückblick von InVision auf die Prototyping-Revolution
- Inside Sketch: Die Geschichte hinter dem Tool, das eine Epoche prägte
2018: Die Smoke-Test-Ära
Während Handoff-Tools versuchten, die Brücke zu verbessern, stellte eine parallele Bewegung eine andere Frage: Was, wenn Designer ausliefern könnten, ohne die Brücke überhaupt zu überqueren?
Mit Webflow (2013, aber ab 2018 im Mainstream) konnten Designer produktive Websites visuell bauen. Keine Prototypen, sondern echte Websites mit richtigem Hosting, CMS und E-Commerce. Wer Webflow beherrschte, lieferte eine Marketing-Website in Tagen aus, ohne Code anzufassen.
Squarespace und Wix boten einfachere Varianten für kleinere Sites. Bubble nahm sich Web-Apps vor. Mit dem Theme-System von Shopify bauten Gründer Shops. Airtable machte aus Tabellen Datenbanken mit Oberfläche.
Das war die „Smoke-Test“-Ära, weil diese Tools perfekt für die Validierung waren: Du konntest etwas bauen, das echt genug war, um es zu verkaufen, es mit echten Kunden testen und die Nachfrage belegen, bevor du in Individualentwicklung investiert hast.
Die Grenze lag in der Skalierung. No-Code-Tools funktionierten hervorragend für Marketing-Websites, einfache Apps und MVPs. Aber sie stießen an Wände: Komplexe Interaktionen, individuelle Funktionen, Performance-Optimierung und Zusammenarbeit im großen Team erforderten „richtige“ Entwicklung.
Trotzdem war die psychologische Wirkung enorm. Designer entdeckten, dass sie ausliefern konnten. Die Hürde „Dafür brauchst du einen Entwickler“ bekam Risse.
No-Code-Tools bewiesen, dass Designer echte Produkte ausliefern können. Auch wenn sie Grenzen hatten, veränderten sie, was Designer sich zutrauten.
2020: Designer, die coden
Figma (2016, ab 2020 dominant) war nicht nur ein besseres Sketch, sondern eine Kollaborationsplattform, die nebenbei Design machte. Multiplayer-Bearbeitung in Echtzeit, Kommentare, Versionierung und Zugriff im Browser veränderten, wie Teams zusammenarbeiten.
Die eigentliche Innovation von Figma war aber konzeptionell: Es behandelte Designdateien als strukturierte Daten, nicht als flache Bilder. Das ermöglichte Auto Layout (wie Flexbox), Komponenten mit Varianten (wie React-Komponenten) und schließlich Design Tokens (wie CSS-Variablen).
Das Design-Tool lernte, wie Code zu denken.
Gleichzeitig lernte Code, wie Design zu denken. Das Komponentenmodell von React entsprach der Art, wie Designer ohnehin über Oberflächen nachdachten. Framer wechselte vom Prototyping zu einem React-basierten Site Builder. Das Widget-System von Flutter war ausdrücklich von Designmustern inspiriert.
Mit Storybook bauten Entwickler UI-Komponenten isoliert, mit visueller Vorschau. Tailwind CSS ließ Styling eher wie das Anwenden von Design Tokens wirken. Design Systems wurden zur gemeinsamen Sprache der Disziplinen.
Die Grenze verschwand nicht, sie wurde durchlässig. Dieselben mentalen Modelle funktionierten auf beiden Seiten.
Wenn Design-Tools Code-Konzepte übernehmen und Code-Frameworks Design-Konzepte, schrumpft die Lücke dazwischen ganz von selbst.
Ressourcen
- Atomic Design: Brad Frosts Framework, das Design- und Code-Denken vereinte
2024: Vibe Coding
Der Start von ChatGPT Ende 2022 löste eine Kettenreaktion aus. 2024 half AI nicht mehr nur beim Code, sie schrieb ganze Anwendungen aus Beschreibungen in natürlicher Sprache.
Cursor nahm VS Code und machte AI zur primären Schnittstelle. Statt Code zu tippen, beschrieben Entwickler, was sie wollten. Die AI schrieb ihn. Der Entwickler prüfte ihn. Die Feedbackschleife wurde dramatisch kürzer.
Claude (die AI von Anthropic) spezialisierte sich darauf, Kontext zu verstehen. Gib ihr eine Codebase, beschreibe ein Feature, und sie schrieb Code, der zu den bestehenden Mustern passte. Sie generierte nicht nur Code, sie verstand Systeme.
v0 (Vercel) und Lovable gingen noch weiter: Beschreibe eine UI und erhalte sofort React-Komponenten. Keine Mockups, sondern funktionierenden Code, bereit zum Deployment. Designer konnten sich per „Prompt“ zu funktionierenden Oberflächen vorarbeiten.
Das schuf eine völlig neue Arbeitsweise. Andrej Karpathy nannte sie „Vibe Coding“: Du beschreibst die Stimmung, die du willst, die AI interpretiert sie, und du iterierst am Ergebnis. Die Fähigkeit bestand nicht darin, Code zu schreiben, sondern Absichten zu vermitteln.
Die Folgen waren tiefgreifend: Der Engpass verlagerte sich von „Kannst du es bauen?“ zu „Kannst du es dir vorstellen und klar beschreiben?“
Wenn natürliche Sprache zur Programmierschnittstelle wird, verschieben sich die entscheidenden Fähigkeiten von technischer Umsetzung zu klarer Kommunikation der Absicht.
Ressourcen
- Andrej Karpathy: Vibe Coding: Der ursprüngliche Tweet, der das Phänomen benannte
- v0 by Vercel: UI mit natürlicher Sprache generieren
- Cursor: Der AI-first Code-Editor
2026: Die Singularity
Wir sind an einem Punkt angekommen, der 2012 wie Science-Fiction geklungen hätte. Eine einzelne erfahrene Fachkraft, nennen wir sie „Product Builder“, kann heute Software in Produktionsqualität konzipieren, gestalten und in Tagen ausliefern.
Das ist nicht hypothetisch. Unsere Design Sprints bei Bonanza Studios liefern regelmäßig funktionale MVPs in zwei Wochen. Teams aus 2-3 Personen liefern aus, wofür 2012 mehr als 10 nötig gewesen wären. Die Rollenunterschiede sind in die Bedeutungslosigkeit verschwommen.
Wie sieht diese Person aus? Sie fühlt sich in Figma wohl, prüft aber genauso selbstverständlich AI-generierten Code. Sie denkt in Systemen, kann aber in Stunden Prototypen bauen. Sie versteht Designmuster und Codemuster, weil es zunehmend dieselben Muster sind.
Das heißt nicht, dass Spezialisten überflüssig sind. Komplexe Systeme brauchen weiterhin tiefes Fachwissen. Aber das minimale funktionsfähige Team ist zusammengeschrumpft. Die Hürde, etwas Echtes in die Hände von Nutzern zu bekommen, war noch nie so niedrig.
Der Double Diamond ist nicht verschwunden, aber er ist komprimiert. Discover, Define, Develop, Deliver können in einem einzigen Sprint stattfinden, wenn die Grenze zwischen Design und Entwicklung dünn genug ist.
Die Zukunft gehört nicht Designern, die coden, oder Entwicklern, die designen, sondern Product Buildern, die beides tun, verstärkt durch AI, die die mechanische Arbeit übernimmt.
Was das für dich bedeutet
Wenn du Designer bist, ist die Botschaft klar: Die Tools, die deine Fähigkeiten verstärken, sind zunehmend code-bewusst. Code lesen, Komponenten verstehen und mit AI-Assistenten arbeiten zu können ist nicht optional, sondern der Weg, relevant zu bleiben.
Wenn du Entwickler bist, wird Design-Kompetenz wichtiger denn je. Wenn AI die Syntax übernimmt, liegt dein Wert darin zu verstehen, was gebaut werden soll und warum. Dafür braucht es Design Thinking.
Wenn du Produktverantwortlicher bist, ist die Konsequenz strategisch: Deine Teamstrukturen und Zeitpläne beruhen vielleicht auf Annahmen, die nicht mehr gelten. Was früher ein Quartal brauchte, dauert jetzt womöglich Wochen.
Die Chance ist riesig. Die Tools von 2026 lassen kleine Teams in einem Tempo arbeiten, bei dem Unternehmen 2012 beim Versuch mitzuhalten pleitegegangen wären. Aber um diese Chance zu nutzen, musst du dich anpassen, bei Fähigkeiten und Denkweise.
Diese Entwicklung ist nicht vorbei. Die Grenze wird weiter verschwimmen. Wer dabei erfolgreich ist, sieht dieses Verschwimmen als Chance, nicht als Bedrohung.
Wer in dieser neuen Landschaft erfolgreich ist, nimmt das Verschwimmen der Disziplinen an, statt traditionelle Grenzen zu verteidigen.
