08. August 2026

•

Min Read

Produktdesignprozess im Vergleich zu Google Design Sprint

Vergleich zwischen dem Produktentwicklungsprozess und dem Google Design Sprint.

Nutzen Sie den Product Design Process, wenn das Problem noch nicht definiert ist und das Produkt von Grund auf neu entwickelt oder überdacht wird. Führen Sie einen Google Design Sprint durch, wenn das Problem bereits bekannt ist und Sie innerhalb einer Woche eine Entscheidung benötigen. Das ist die ganze Antwort; es ist der Unterschied zwischen dem Entwurf eines Hauses und der Renovierung eines Zimmers in einem bestehenden Gebäude. Beides ist Designarbeit. Nur eines davon zeigt Ihnen, wo die tragenden Wände sind.

Dieser Artikel vergleicht unseren Product Design Process, bei dem Nutzer- und Marktforschung vor jeder Umsetzung stehen, mit dem Google Design Sprint, einer Fünf-Tage-Methode zur Beschleunigung von Entscheidungsprozessen. Er richtet sich an CTOs, Product Owner oder Gründer, die vor Beginn der Designarbeit entscheiden müssen, welcher der beiden Ansätze finanziert werden soll.

Produktdesignprozess vs. Google Design Sprint im Überblick

	Produktdesignprozess (PDP)	Google Design Sprint (GDS)
Dauer	Wochen, verteilt auf vier Phasen und zwölf Designschritte	Vier bis fünf Tage, eine Phase pro Tag
Beteiligtes Team	Produktdesign-Team, mit den geschäftlichen und technischen Stakeholdern des Kunden an definierten Punkten	Das gesamte funktionsübergreifende Team in einem Raum, plus ein benannter Entscheider
Ausgangspunkt	Das Problem ist noch nicht definiert	Das Problem ist bekannt und das Team hat bereits damit gearbeitet
Ergebnis	Research, Wireframes, Styleguide, GUI-Design, Prototyp, High-Level-Architektur und Projektplan	Ein High-Fidelity-Prototyp, getestet mit Endnutzern
Optimal geeignet für	Ein von Grund auf neu entwickeltes Produkt oder ein bestehendes, das komplett neu gedacht wird	Ein bestehendes Produkt, das Funktion für Funktion verbessert wird
Hauptrisiko	Zeitaufwand für Research, bevor etwas sichtbar ist	Prototyping auf Basis von Annahmen, die nie validiert wurden
Kommerzielles Argument	Realistische Zeitpläne und weniger spätere Neugestaltungen	Eine Entscheidung innerhalb einer Woche statt eines Quartals

Der restliche Artikel erläutert beide Prozesse, arbeitet die Unterschiede heraus und zeigt auf, wann sich welcher Ansatz lohnt.

Die zwölf Schritte zum erfolgreichen digitalen Produkt

Woher dieser Vergleich stammt

Wir sind nicht theoretisch darauf gekommen. 2014 betrieben wir einen Service namens „The War Room“: Ein Product Owner, ein Designer und ein Entwicklungsteam arbeiteten drei Tage lang in einem Raum, um ein Minimum Viable Product zu liefern. Im Grunde war es ein Sprint. Die Ergebnisse waren durchwachsen. Wir haben einige Produkte auf den Markt gebracht, die beim ersten Kontakt mit dem Markt scheiterten. „The Lean Startup“ und der „Google Design Sprint“ standen zwar in jedem Bücherregal, aber für unsere Arbeit reichten sie allein nicht aus.

Die Lektion, die wir aus diesen Misserfolgen gelernt haben, war eindeutig: Ein digitales Produkt, das von Grund auf neu entwickelt wird, erfordert fundierte Recherche, bevor überhaupt Prototypen erstellt werden. Damals gab es keinen dokumentierten Prozess, der diese Recherche mit der Umsetzung verknüpfte. Also haben wir einen entwickelt. Das ist der Produktdesign-Prozess, und der Vergleich in diesem Artikel ist derjenige, den wir seitdem Projekt für Projekt anstellen. Wir arbeiten immer noch mit Sprint-Methoden. Wir wissen heute nur genau, für welches Problem sie jeweils geeignet sind.

Erfahren Sie mehr darüber, wie wir unseren Produktdesign-Prozess in unseren Projekten anwenden – besuchen Sie unser Portfolio!

Was ist Produktdesign?

Die Interaction Design Foundation definiert Produktdesign als den Prozess, bei dem Designer Nutzerbedürfnisse mit Geschäftszielen in Einklang bringen, damit Marken dauerhaft erfolgreiche Produkte entwickeln können.

Designgrafik, die Geschäftsziele mit UX-Prozessschritten wie Recherche und Prototyping vergleicht.

Nehmen wir Uber. Das Problem ist der Bedarf an bequemer, schneller Beförderung auf Abruf, und Uber löst dies mit einer App, bei der der Nutzer per Knopfdruck einen Fahrer anfordert. Diese Lösung wird dann mit Geschäftszielen kombiniert, wie etwa Preismodellen, die durch Angebot und Nachfrage nachhaltige Umsätze erzielen.

Ein Produktdesigner schlägt also die Brücke. Auf der einen Seite steht die Erfüllung der Nutzerbedürfnisse durch eine exzellente User Experience. Auf der anderen Seite stehen die wirtschaftlichen Ziele des Unternehmens.

Was es kostet, auf Produktdesign zu verzichten

Das Problem beim Verzicht auf Design ist: Die Designentscheidungen verschwinden nicht. Sie werden lediglich in die Entwicklungsphase verlagert, wo sie von der Person getroffen werden, die gerade an diesem Bildschirm arbeitet – ohne jegliche Recherche als Grundlage. Das hat drei Folgen, und alle drei kosten Geld.

Erstens: Nachbesserungen. Ein Bildschirm, der auf einer ungeprüften Annahme basiert, muss neu gebaut werden, sobald sich diese Annahme als falsch erweist – und bis dahin hängen bereits zahlreiche Abhängigkeiten daran.

Zweitens: Die Kalkulation. Ein Team, das vor der Schätzung nicht alle Bildschirme, Zustände und Integrationen gesehen hat, schätzt ein Produkt ein, das es gar nicht kennt. Deshalb geraten Zeitpläne aus Gründen ins Wanken, die vorher niemand benennen konnte.

Drittens: Die Kohärenz. Funktionen, die einzeln und in der Reihenfolge ihrer Anforderung entworfen werden, ergeben ein Produkt, das zwar funktioniert, aber nicht wie aus einem Guss wirkt. Jede spätere Erweiterung muss sich dann der Inkonsistenz anpassen, statt einem einheitlichen Muster zu folgen. Wie bei einem Haus: Zimmer, die nacheinander angebaut wurden, jedes nach einem anderen Plan.

Nichts davon wird als Designproblem wahrgenommen. Es erscheint als Lieferproblem, Budgetproblem oder als Anstieg der Support-Anfragen. Die Kosten sind nicht hypothetisch: Das Consortium for Information and Software Quality beziffert die Kosten durch mangelhafte Softwarequalität in den USA auf rund 2,41 Billionen Dollar pro Jahr, wobei sich die angehäuften technischen Schulden – also der Preis für die Überarbeitung suboptimaler Software – auf etwa 1,52 Billionen Dollar belaufen. Mehr zu diesen Zahlen später, denn das Muster dahinter ist das eigentliche Argument.

Was ist der Produktdesign-Prozess?

Wie wir in unserem Beitrag über die zwölf Schritte zur Entwicklung eines erfolgreichen Produktsbeschreiben, ist der Produktdesign-Prozess (PDP) ein multidisziplinärer, nutzerzentrierter Ansatz von Imaginary Cloud. Er verknüpft bewährte, über die Zeit in der Branche gereifte Techniken, um den Workflow des Designteams so effizient wie möglich zu gestalten.

Der PDP besteht aus vier Phasen – Recherche, Ideenfindung, Umsetzung und technische Bewertung –, die in zwölf Schritte unterteilt sind. Jeder Schritt liefert die Grundlage für den nächsten. Genau das macht ihn zu einem prozessbasierten statt meinungsbasierten Design: Die Reihenfolge ist keine bloße Präferenz, sondern eine Abhängigkeitskette.

Diagramm des Produktentwicklungsprozesses mit Forschungs-, Ideenfindungs-, Ausführungs- und technischen Bewertungsphasen.

Recherche. Das Ziel ist es, sicherzustellen, dass keine Entscheidung auf vagen Annahmen beruht, und den Kern des Geschäftsmodells sowie die Nutzerbedürfnisse zu identifizieren. Drei Schritte: das Briefing, eine vereinbarte Definition dessen, wofür das Produkt steht, wen es bedient und wie Erfolg aussieht; Nutzerforschung, Interviews und Daten zu den tatsächlichen Nutzern, aus denen sich die Anforderungen ergeben, die das Design erfüllen muss; sowie ein Design-Benchmark, eine Analyse vergleichbarer Produkte, um zu sehen, wie diese Probleme lösen und wo sie scheitern.

Ideenfindung. Das Ziel ist es, das Produktkonzept auf Basis der Nutzerbedürfnisse und des Geschäftsmodells zu formulieren. Vier Schritte: die User Journey, der durchgängige Pfad, den ein Nutzer durch das Produkt nimmt, noch bevor ein Bildschirm existiert; eine Entscheidungsmatrix, ein bewerteter Vergleich von Lösungsansätzen, der auf festgelegten Kriterien basiert statt auf der lautesten Meinung; Wireframes, Low-Fidelity-Layouts, die Struktur und Hierarchie festlegen, bevor visuelles Design stattfindet; und ein Moodboard, eine Referenzsammlung, die die visuelle Richtung festlegt, bevor ein Bildschirm gestaltet wird.

Umsetzung. Das Ziel ist es, eine konkrete Darstellung des bisher definierten Konzepts zu erstellen. Drei Schritte: der Styleguide, die Komponenten, Typografie, Farb- und Abstandsregeln, auf denen jeder Bildschirm aufbaut; das Graphic User Interface (GUI) Design, die fertigen Bildschirme, die gemäß dem Styleguide gezeichnet werden; und der Prototyp, die Bildschirme, die zu einem klickbaren Modell verknüpft werden, um es testen zu können.

Technische Bewertung. Das Ziel ist es, sicherzustellen, dass jede Anforderung und Idee realistisch umsetzbar ist. Zwei Schritte: die High-Level-Architektur, die Systeme, Dienste und Integrationen, die das Design erfordert und die vor der Schätzung abgebildet werden; und der Projektplan, die Abfolge, der Aufwand und die Abhängigkeiten für die Entwicklung, geschätzt auf Basis eines bereits existierenden Designs.

Flussdiagramm des Produktentwicklungsprozesses: Nutzerforschung, Drahtmodelle und Prototyping.

Lesen Sie auch: Design Research: Einfluss auf die menschliche Erfahrung, und falls Sie sich speziell für die erste marktreife Version interessieren: die verschiedenen Arten von MVPs.

Der Produktdesign-Prozess in der Praxis: FundSpace

Theorie ist leicht gesagt – hier ist der Prozess anhand eines echten Produkts. FundSpace ist eine Finanzierungsplattform, die Kapital für KMU erschließt. Wir wurden mit einer unklaren Aufgabenstellung konfrontiert: Entwickeln Sie ein Webportal, das die Performance von Fonds für zwei sehr unterschiedliche Zielgruppen transparent darstellt – für die Fondsmanager, die die Fonds auflegen, und für die Investoren, die die Berichte lesen.

Genau das ist der Fall für den vollständigen Prozess, nicht für einen Sprint. Die größte Herausforderung war nicht ein einzelner Bildschirm, sondern die Datenstruktur, die Fonds, Dachfonds und Dachfonds mit verschiedenen Anteilsklassen abbilden musste. Wir begannen mit einem technischen Prototyp, um die Machbarkeit eines solchen Datenspeichers zu belegen, und durchliefen anschließend die vier Phasen des PDP, um die Benutzeroberfläche auf die Marke und die beiden Zielgruppen abzustimmen. Die Entwicklung erfolgte mit Ruby on Rails, React und Node.js durch ein engagiertes Team aus produktorientierten Designern, Front-End-Entwicklern und einem Projektmanager.

Die entscheidende Zahl: Die neu gestaltete Benutzeroberfläche ermöglichte einen 10-mal schnelleren Entscheidungsprozess sowohl für Fondsmanager als auch für Investoren. Die Plattform erhielt eine Kundenbewertung von 5,0, das Produkt wurde für das 917Ventures Accelerator-Programm von 500 Global im Jahr 2023ausgewählt, und die Arbeit führte dazu, dass Imaginary Cloud von Techreviewer als Top Financial App Developer ausgezeichnet wurde. Ein Sprint hätte in einer Woche einen Bildschirm testen können. Er hätte jedoch nicht das Datenmodell gefunden, auf dem das gesamte Produkt basiert. Sie können sich die FundSpace-Fallstudie in voller Länge ansehen, zusammen mit vergleichbaren PDP-Entwicklungen für Pulsar Helium und NotaryCam.

E-Book-Angebot für UX/UI-Design-Tipps zur Website-Konvertierung mit Desktop-, Mobil- und Lupe-Symbolen.

Entwickeln Sie ansprechende und maßgeschneiderte Oberflächen mit unserem Produktdesign-Prozess

Was ist ein Design Sprint?

Der Design Sprint ist ein strukturierter Prozess, der innerhalb einer Woche von der Definition einer Herausforderung bis hin zu einem High-Fidelity-Prototypen oder einem testbaren Produkt führt. Produktteams nutzen ihn, um große Ideen schnell zu prüfen und monatelange Arbeit auf wenige Tage zu komprimieren.

5 Phasen des Design Sprints: Verstehen, Skizzieren, Entscheiden, Prototypen und Validieren.

In vier bis fünf Tagen hilft Ihnen der Design Sprint dabei, das Problem durch Mapping und die Wahl eines Fokusbereichs zu verstehen; durch das Skizzieren konkurrierender Lösungen Ideen zu entwickeln; durch die Umwandlung dieser Ideen in eine testbare Hypothese Entscheidungen zu treffen; durch den Bau eines realistischen Prototypen zu prototypisieren; und durch das Einholen von Feedback echter Nutzer zu validieren. Im Folgenden erläutern wir diese Schritte im Detail.

Innerhalb dieser Woche setzt der Sprint den Fokus auf Nutzerfeedback, damit ein funktionsfähiger Prototyp bereits zu Beginn der Produktentwicklung bei echten Anwendern landet und nicht erst nach dem Launch. Er beschleunigt Entscheidungsprozesse, indem das gesamte Team an einem Ort zusammenkommt und eine feste Entscheidungsperson bestimmt wird – genau das verhindert, dass aus einem einwöchigen Sprint eine monatelange Diskussion wird. Zudem verbessert er die Zusammenarbeit, indem schnelle Ideenfindung, Iteration und Entscheidungsfindung in den Vordergrund gestellt werden, damit die Arbeit nicht durch das Warten auf das nächste Meeting ins Stocken gerät. Diese Arbeitsweisen überdauern meist den Sprint selbst.

Was ist der Google Design Sprint?

Der Google Design Sprint (GDS) wurde bei GV entwickelt, dem ehemaligen Google Ventures, einer Beteiligungsgesellschaft, die Technologieunternehmen in der Seed-, Venture- und Wachstumsphase finanziert. Er vereint Geschäftsstrategie, Innovation, Verhaltenswissenschaft und Design Thinking in einem einzigen Ansatz, den ein Team innerhalb einer Woche umsetzen kann. Das maßgebliche Standardwerk dazu ist das Buch Sprintvon Jake Knapp mit John Zeratsky und Braden Kowitz, das nach wie vor die wichtigste Lektüre ist, bevor man selbst einen Sprint durchführt.

Der Prozess basiert auf Design Thinking – also dem Verstehen des Nutzers, dem Eingrenzen des Problems und dem Testen von Lösungen, bevor man sich festlegt – und gewinnt Erkenntnisse durch schnelle Lösungsansätze, Prototyping und Nutzertests. Er besteht aus fünf Phasen, die jeweils etwa ein bis acht Stunden dauern.

1. Verstehen. Das Ziel ist ein gemeinsames Wissensfundament, damit das Team das geschäftliche Problem zusammen identifizieren kann. Man holt alle Beteiligten an einen Tisch und trägt das vorhandene Wissen in sogenannten Lightning Talks zusammen – kurzen, zehn- bis fünfzehnminütigen Briefings zu Geschäftszielen, Erkenntnissen aus der Nutzerforschung, einem Wettbewerbsüberblick und technischen Möglichkeiten. Wichtig ist, was dieser Tag nicht ist: Er dient dazu, bereits vorhandenes Wissen im Team zu bündeln. Wenn dieses Wissen noch nicht existiert, wird ein Vormittag mit Lightning Talks es nicht aus dem Nichts erschaffen.

2. Skizzieren. Eine individuelle Aufgabe. Jeder entwickelt eine detaillierte Lösung, meist auf Papier, da dies schnell geht, keine Kosten bei Änderungen verursacht und es dem gesamten Team ermöglicht, sich zu beteiligen – auch denjenigen, die noch nie ein Wireframing-Tool bedient haben. Bei großen, komplexen Problemen kann es helfen, das Problem in Teilbereiche zu zerlegen und jedem eine Aufgabe zuzuweisen. Das Ziel ist Masse: So viele Ideen wie möglich zu Papier bringen.

3. Entscheiden. Hier geht es darum, welche Idee in die Prototyping-Phase geht und wo Lösungen mit Ihren Zielen und Möglichkeiten kollidieren könnten. Listen Sie zunächst Ihre Annahmen zu Budget, Nutzern, technischer Kapazität und geschäftlichen Treibern auf. Prüfen Sie dann jede Idee auf mögliche Konflikte. Die nicht umsetzbaren Ideen werden aussortiert, sodass die besten übrig bleiben, um sie in ein Storyboard zu überführen, das jeden Interaktionsschritt darstellt. Dieses Storyboard dient als Spezifikation für Ihren Prototyp.

4. Prototyping. Ein Tag Zeit, um etwas zu bauen, das Ihre Nutzer testen können. Nutzen Sie, womit Sie sich wohlfühlen: Pappe, Kleber und Farben für physische Modelle oder digitale Skizzen.

5. Validieren. Laden Sie an Tag vier oder fünf eine Gruppe von Endnutzern ein, um den Prototyp zu testen. Achten Sie darauf, dass das gesamte Team beobachtet, wie die Nutzer damit interagieren – live oder per Aufzeichnung. Auch das Einbeziehen von Experten und Stakeholdern zur Begutachtung ist hilfreich. Der Sprint ist zwar linear aufgebaut, aber es ist ausdrücklich erwünscht, auf Basis der gewonnenen Erkenntnisse Anpassungen vorzunehmen und den Prozess erneut zu durchlaufen.

Produktdesignprozess vs. Google Design Sprint: Die wichtigsten Unterschiede

Ist das eine richtig und das andere falsch? Nein. Der PDP eignet sich für die Entwicklung eines Produkts von Grund auf oder die Neukonzeption eines bestehenden Produkts; der GDS eignet sich für ein bereits etabliertes Produkt.

Slack ist hierfür das beste Beispiel. Ein Sprint verbessert es schrittweise, Funktion für Funktion. Den vollständigen Produktdesignprozess auf Slack anzuwenden, würde einen völlig neuen Ansatz und eine neue Lösung bedeuten – was bei einem Produkt, dessen Bedienung Millionen von Menschen bereits kennen, nicht sinnvoll ist.

Der praktische Unterschied liegt darin, was an die Entwicklung übergeben wird. Ein Sprint liefert einen validierten Prototyp. Die zwölf Schritte liefern ein spezifiziertes Produkt: die Bildschirme, die Zustände, die durch das Design implizierte Architektur und einen Plan, der auf all diesen Punkten basiert. Ein vollständiger Prozess unterstützt einen Zeitplan. Ein Sprint unterstützt eine Entscheidung.

Ein Design Sprint ist also die beste Option, wenn das Problem bekannt ist, das Team bereits damit gearbeitet hat oder die Erfahrung bereits zeigt, worum es geht. Wenn es jedoch keine konkreten Handlungsoptionen gibt oder die Zielgruppe noch unbekannt ist, wird ein Sprint keine nützlichen Ergebnisse liefern. Es gibt nichts, was man in eine Woche komprimieren könnte, wenn das Team noch darüber rätselt, was eigentlich entschieden werden soll. Das Fundament muss zuerst gelegt werden, und genau hier zeigt der Produktdesignprozess seinen Wert.

Entscheidungsdiagramm zum Vergleich von Produktentwicklungsprozess und Google Design Sprint. — Die eine Frage, die darüber entscheidet, was finanziert wird. Diagramm von Imaginary Cloud.

Was ein CTO tatsächlich entscheidet

Die Kosten einer Fehlentscheidung liegen nicht im Designbudget, sondern in der darauf folgenden Umsetzung. Ein Sprint, der auf einem undefinierten Problem basiert, erzeugt einen Prototyp, an den das Team glaubt, liefert aber keinen Beweis dafür, dass das Problem überhaupt gelöst werden musste. Die Validierung findet also erst in der Entwicklung statt – zu Entwicklungskosten und nachdem die Roadmap bereits festgeschrieben wurde.

Die wirtschaftlichen Folgen einer späten Fehlererkennung sind gut dokumentiert und haben sich massiv verschärft. Die NIST-Studie aus dem Jahr 2002 The Economic Impacts of Inadequate Infrastructure for Software Testing bezifferte die jährlichen Kosten von Softwarefehlern für die US-Wirtschaft auf 59,5 Milliarden Dollar und führte etwa ein Drittel davon auf Mängel zurück, die früher hätten erkannt werden können. Zwei Jahrzehnte später beziffert der Bericht des Consortium for Information and Software Quality aus dem Jahr 2022 die Kosten mangelhafter Softwarequalität in den USA auf etwa 2,41 Billionen Dollar pro Jahr, bei einer angehäuften technischen Schuld von fast 1,52 Billionen Dollar. Diese Zahl ist mit der Reife der Software nicht geschrumpft, sondern um den Faktor vierzig gewachsen, da Software zum Fundament von allem geworden ist. Das Muster ist dasselbe, das Produktteams in ihrem eigenen Maßstab erleben: Je später eine falsche Annahme erkannt wird, desto mehr wurde bereits darauf aufgebaut.

Jedes Mal, wenn eine neue Idee auf Basis hinfälliger Anforderungen prototypisiert wird, muss ein Großteil der bereits geleisteten Arbeit neu gestaltet werden. Erzwingt man diese Nacharbeit, erhält man ein Produkt, das eher zusammengeflickt als aus einem Guss wirkt – wie Räume, die nacheinander angebaut wurden, jeder nach einem anderen Plan. Verglichen mit einem vier- bis fünftägigen Sprint sind die Wochen, die ein vollständiger Designprozess in Anspruch nimmt, der günstigere Teil der Rechnung, da sie nur einmal bezahlt werden – vor der Kostenschätzung und nicht wiederholt im Rahmen der Codebasis.

Deshalb unterteilen wir bei Imaginary Cloud den Prozess in logische Phasen, die aufeinander aufbauen. Der PDP gleicht Designqualität mit Kosten und einer schnellen Markteinführung ab, sodass das Ergebnis nicht nur benutzerfreundlich ist, sondern auch im vereinbarten Zeitrahmen auf den Markt kommt.

Häufig gestellte Fragen

Wie lange dauert der Produktdesignprozess?

Er erstreckt sich über vier Phasen und zwölf Schritte und wird daher eher in Wochen als in Tagen gemessen. Die meiste Zeit entfällt auf Recherche und Ideenfindung, da die nachfolgenden Schritte von diesen abhängen.

Wie lange dauert ein Google Design Sprint?

Vier bis fünf Tage, eine Phase pro Tag, wobei jede Phase etwa eine bis acht Stunden in Anspruch nimmt.

Wann sollte man keinen Design Sprint durchführen?

Wenn das Problem nicht definiert oder die Zielgruppe unbekannt ist. Ein Sprint beschleunigt die Entscheidungsfindung, aber es gibt nichts zu beschleunigen, wenn das Team noch darüber rätselt, was eigentlich entschieden werden soll.

Kann man einen Design Sprint mit dem Produktdesignprozess kombinieren?

Ja, bei einem etablierten Produkt ist das sogar der Regelfall. Der Produktdesignprozess legt das Fundament, und Sprints verbessern anschließend einzelne Funktionen, sobald der Problembereich verstanden wurde.

Welcher Ansatz ist der richtige für ein bestehendes Produkt?

Der Google Design Sprint, wenn das Produkt schrittweise verbessert werden soll und das Problem bereits bekannt ist. Der Produktdesignprozess, wenn das Produkt komplett neu gedacht wird, da es sich in diesem Fall faktisch um ein neues Produkt handelt.

Was erhält man am Ende der jeweiligen Prozesse?

Ein Design Sprint endet mit einem High-Fidelity-Prototyp, der mit Nutzern getestet wurde. Der Produktdesignprozess endet mit Rechercheergebnissen, Wireframes, einem Styleguide, GUI-Design, einem Prototyp, einer übergeordneten Architektur und einem Projektplan.

Alles läuft auf eine einzige Frage hinaus: Wissen Sie, was das Problem ist? Wenn ja, machen Sie einen Sprint. Wenn nein, finden Sie es zuerst heraus, denn kein Prototyp wird Ihnen die Antwort darauf geben.

‍

Wenn Sie es lieber persönlich besprechen möchten, erzählen Sie uns von Ihrem Produkt und wir sagen Ihnen, welcher der beiden Ansätze am besten passt. Sie können sich auch unser vollständiges Portfolio an Projekten ansehen, um den Prozess in der Praxis zu erleben.

Stapel orangener Bücher mit dem Titel „Product Design Process“, ein Handbuch für digitales Produktdesign.

The word Amazon in white text on a solid blue background.

Anjali Ariscrisnã

Vielseitiger und datengesteuerter Wachstumsvermarkter mit fundierten Geschäftskenntnissen, der über die neuesten Entwicklungen in der digitalen Marketinglandschaft auf dem Laufenden gehalten wird.