Prototyping bedeutet, eine geplante Lösung früh in einer vereinfachten Form greifbar zu machen, um Annahmen zu Abläufen, Interaktionen, Anforderungen oder Machbarkeit zu prüfen, bevor hohe Umsetzungskosten entstehen. Je nach Fragestellung reicht der Prototyp von einer einfachen Papierskizze bis zu einem realitätsnahen interaktiven oder technischen Modell.

Der wirtschaftliche Kern ist eine einfache Beobachtung: Eine Änderung an einer Skizze kostet Minuten. Dieselbe Änderung nach der Programmierung kostet Entwicklungszeit, Tests und eine erneute Abstimmung. Nach der Einführung kommen Datenmigration und Umschulung hinzu.

Trotzdem wird der Schritt oft übersprungen, weil er wie zusätzlicher Aufwand wirkt. Tatsächlich verschiebt er Aufwand nur nach vorn – in eine Phase, in der Änderungen fast nichts kosten.

Dieser Artikel zeigt, welche Prototyping-Arten und Detailgrade es gibt, wann welcher Ansatz sinnvoll ist, wie ein Prototyping-Prozess abläuft und worin sich Wireframe, Mockup, Prototyp, Proof of Concept und MVP unterscheiden. In diesem Beitrag liegt der Schwerpunkt auf Prototyping für digitale Produkte und Softwarelösungen.

• Wozu Prototyping dient
• Prototyping-Arten und Detailgrade: Welcher Prototyp passt zu welcher Frage?
• Der Ablauf in sechs Schritten
• Prototypen mit Anwendern prüfen
• Wireframe, Mockup, Prototyp, PoC und MVP: Was ist der Unterschied?
• Vom Prototyp zur Entscheidung: weiterentwickeln, nachschärfen oder verwerfen?
• Fazit
• FAQ zum Prototyping

Ein Prototyp beantwortet Fragen, die sich am Schreibtisch nicht klären lassen:

• Verstehen die Anwender den vorgesehenen Ablauf?
• Fehlt eine Information an einer bestimmten Stelle?
• Passt die gedachte Reihenfolge zur tatsächlichen Arbeit?
• Meinen alle Beteiligten dasselbe, wenn sie über eine Funktion sprechen?

Aus Unternehmenssicht ist Prototyping damit nicht nur ein Designschritt, sondern ein Instrument zur Risikoreduktion und Entscheidungsfindung. Bevor Budget in Entwicklung, Integration und Einführung gebunden wird, lässt sich prüfen, welche Annahmen bereits tragen, wo noch Unklarheiten bestehen und welche Lösungsrichtung überhaupt weiterverfolgt werden sollte. Ein guter Prototyp kann deshalb ebenso wertvoll sein, wenn er eine Idee früh bestätigt wie wenn er zeigt, dass sie verworfen oder grundlegend verändert werden sollte.

Ein besonders wichtiger Nutzen liegt in der gemeinsamen Verständigung. Ein Prototyp kann unterschiedliche Vorstellungen zwischen Fachbereich, Projektleitung und Entwicklung sichtbar machen, bevor sie in die Umsetzung einfließen. Eine Formulierung wie „die Freigabe erfolgt durch die Abteilungsleitung“ lässt häufig Interpretationsspielraum. Wird der geplante Ablauf dagegen konkret dargestellt, werden unterschiedliche Annahmen wesentlich schneller erkennbar.

Was ein Prototyp leisten kann, hängt von seinem Zweck ab. Ein UX- oder Interaktionsprototyp überprüft vor allem Abläufe, Begriffe, Informationsbedarf und Bedienlogik. Soll dagegen geklärt werden, ob eine Technologie, Schnittstelle oder technische Architektur grundsätzlich funktioniert, ist ein technischer Prototyp beziehungsweise Proof of Concept (PoC) geeigneter. Ein Prototyp ersetzt deshalb weder sauberes Requirements Engineering noch eine gezielte technische Machbarkeitsprüfung – beide können im selben Vorhaben jedoch sinnvoll zusammenspielen.

Wie sich Anforderungen so fassen lassen, dass ein Prototyp sie überprüfbar macht, behandelt der Beitrag zum Requirements Engineering.

Nicht jeder Prototyp muss realistisch aussehen oder vollständig durchklickbar sein. Entscheidend ist, welche Frage damit beantwortet werden soll. Je früher sich ein Vorhaben befindet, desto einfacher darf der Prototyp in der Regel sein. Erst wenn grundlegende Abläufe und Anforderungen geklärt sind, lohnt sich ein höherer Detailgrad.

Dabei wird häufig zwischen Low-Fidelity-, Mid-Fidelity- und High-Fidelity-Prototypen unterschieden. Zusätzlich können technische Prototypen beziehungsweise ein Proof of Concept (PoC) eingesetzt werden, wenn nicht die Bedienung, sondern die technische Machbarkeit im Mittelpunkt steht.

Ein Low-Fidelity-Prototyp eignet sich beispielsweise, wenn zunächst geklärt werden soll, ob ein Vorgang grundsätzlich sinnvoll aufgebaut ist. Eine einfache Papierskizze reicht häufig aus, um zu erkennen, ob Schritte fehlen, Informationen an der falschen Stelle stehen oder Beteiligte unterschiedliche Vorstellungen vom Ablauf haben.

Soll dagegen geprüft werden, ob Anwender ohne zusätzliche Erklärung durch einen Vorgang finden, ist ein klickbarer Mid-Fidelity-Prototyp meist aussagekräftiger. Er bildet mehrere Ansichten und Übergänge ab, ohne bereits viel Aufwand in Farben, Details oder eine endgültige Gestaltung zu investieren.

Ein High-Fidelity-Prototyp ist vor allem dann sinnvoll, wenn die grundlegende Struktur bereits geklärt ist und realitätsnahes Feedback benötigt wird. Mit konkreten Daten, tatsächlichen Begriffen und einer ausgearbeiteten Interaktion lässt sich beispielsweise prüfen, ob Informationen vollständig sind und sich ein Ablauf auch unter realistischen Bedingungen verständlich anfühlt.

Geht es dagegen um die Frage, ob eine Schnittstelle funktioniert, eine Technologie grundsätzlich geeignet ist oder sich eine technische Annahme umsetzen lässt, reicht ein reiner Oberflächenprototyp nicht aus. Dafür ist ein technischer Prototyp beziehungsweise Proof of Concept die passendere Form.

Die wichtigste Faustregel lautet deshalb: so einfach wie möglich beginnen und nur so weit verfeinern, wie es die offene Frage erfordert. Zu viel Detail zu einem frühen Zeitpunkt bindet nicht nur unnötig Zeit. Ein bereits sehr ausgearbeiteter Entwurf lenkt Rückmeldungen außerdem schnell auf Farben, Abstände oder einzelne Gestaltungselemente, obwohl möglicherweise noch der gesamte Ablauf zur Diskussion steht.

Gerade einfache Papierskizzen haben deshalb einen praktischen Vorteil: Sie wirken sichtbar unfertig und signalisieren, dass grundlegende Änderungen ausdrücklich erwünscht sind. Der passende Detailgrad ist somit nicht der möglichst höchste, sondern derjenige, der mit möglichst wenig Aufwand die relevante Unsicherheit reduziert.

1. Frage festlegen – was genau soll der Prototyp klären?
2. Umfang begrenzen – ein Vorgang, nicht das ganze System
3. Entwerfen – im geringsten Detailgrad, der die Frage beantwortet
4. Prüfen – mit Personen, die den Vorgang später ausführen
5. Auswerten – Befunde festhalten, Entwurf anpassen
6. Entscheiden – weiterverfeinern, verwerfen oder umsetzen

Der erste Schritt bestimmt alles Weitere. Ein Prototyp ohne konkrete Frage wird beliebig – er zeigt irgendetwas, und die Rückmeldungen betreffen irgendetwas.

Gerade beim Umfang besteht in der Praxis die Gefahr, zu früh zu viel abzubilden. Der Versuch, das gesamte System abzubilden, führt zu wochenlangem Aufwand, bevor die erste Rückmeldung eintrifft. Ein einzelner, häufiger Vorgang von Anfang bis Ende kann deshalb mehr verwertbare Erkenntnisse liefern als zahlreiche nur teilweise ausgearbeitete Masken.

Planen Sie mehrere kurze Iterationen ein. Wie viele Durchläufe sinnvoll sind, hängt davon ab, welche Fragen nach einer Prüfung noch offenbleiben. Entscheidend ist nicht eine feste Anzahl, sondern dass neue Erkenntnisse in den nächsten Entwurf einfließen und anschließend erneut überprüft werden. Dass ein erster Entwurf noch nicht alle Anforderungen erfüllt, ist dabei kein Fehler, sondern Teil des Prototyping-Prozesses.

Bei Interaktionsprototypen entsteht ein wesentlicher Teil des Nutzens, wenn sie von Personen ausprobiert werden, die den Entwurf nicht selbst erstellt haben.
Der Ablauf entspricht dem eines regulären Tests: eine realistische Aufgabe stellen, beobachten, nicht eingreifen. Ausführlich beschreibt das der Beitrag zum Usability Test.

Zwei Besonderheiten gelten beim Prototyp:

• Erklären Sie vorab, was nicht funktioniert. Ein klickbarer Entwurf hat tote Enden. Ohne Hinweis suchen Teilnehmende den Fehler bei sich und werden vorsichtig.
• Fragen Sie nach Erwartungen, nicht nach Gefallen. „Was erwarten Sie hinter dieser Schaltfläche?" liefert verwertbare Antworten. „Wie gefällt Ihnen das?" liefert Höflichkeit.

Für frühe qualitative Tests reicht häufig eine kleine Gruppe gezielt ausgewählter Personen. Bei einer relativ homogenen Nutzergruppe können bereits wenige Teilnehmende zentrale Verständlichkeitsprobleme sichtbar machen. Gibt es dagegen mehrere deutlich unterschiedliche Nutzergruppen oder komplexere Fragestellungen, sollte entsprechend breiter getestet werden. Entscheidend ist weniger eine starre Teilnehmerzahl als die Frage, ob die relevanten Nutzungssituationen ausreichend abgedeckt sind.

Wie unterschiedlich Prototyping eingesetzt werden kann, zeigt ein Projekt aus der DIPS-Praxis.

Bei einem Industrie-4.0-Vorhaben sollte eine bestehende Kundenlösung vernetzt und damit ein Bestellablauf vereinfacht werden. Bevor die finale Lösung realisiert wurde, sollte zunächst geklärt werden, ob das Konzept technisch funktioniert und von den späteren Nutzern angenommen wird.

Nach einer gemeinsamen Konzepterstellung wurde ein geeigneter Prototyp umgesetzt und anschließend mit Endkunden evaluiert. Das Feedback floss direkt in die Weiterentwicklung ein. Dadurch konnten relevante Erkenntnisse gewonnen werden, bevor die endgültige Lösung realisiert und ein deutlich größeres Budget gebunden wurde.

Das Beispiel zeigt den eigentlichen wirtschaftlichen Nutzen: Prototyping schafft nicht nur Anschauungsmaterial, sondern kann technische, fachliche und nutzerbezogene Unsicherheiten früh sichtbar machen.

Die DIPS GmbH unterstützt Unternehmen dabei, offene Fragen früh greifbar zu machen und die passende Form der Validierung zu wählen. Je nach Vorhaben reicht die Begleitung von Nutzeranalyse und Prototyping über Requirements Engineering und Lösungsdesign bis zur strukturierten Vorbereitung und Unterstützung bei der Umsetzung. So werden Erkenntnisse aus frühen Entwürfen nicht isoliert betrachtet, sondern in belastbare Entscheidungen für das weitere Projekt überführt.

Wireframe, Mockup, Prototyp, Proof of Concept und MVP werden in Projekten häufig miteinander vermischt. Sie verfolgen jedoch unterschiedliche Ziele. Entscheidend ist deshalb nicht, welcher Begriff moderner klingt, sondern welche Unsicherheit im jeweiligen Projekt geklärt werden soll.

Wireframe: Ein Wireframe beantwortet vor allem die Frage, welche Informationen und Funktionen an welcher Stelle benötigt werden.

Mockup: Ein Mockup geht einen Schritt weiter und zeigt, wie eine Oberfläche visuell aussehen könnte. Beide müssen noch keine funktionierende Interaktion enthalten.

Prototyp: Ein Prototyp macht dagegen Abläufe greifbar. Mehrere Ansichten können miteinander verknüpft werden, sodass Anwender beispielsweise einen Freigabeprozess, eine Dateneingabe oder einen Bestellvorgang durchspielen können. Die dahinterliegende Software muss dafür noch nicht entwickelt sein.

Proof of Concept (PoC): Ein Proof of Concept verfolgt ein anderes Ziel. Hier steht nicht die Bedienung im Mittelpunkt, sondern die Frage, ob eine technisch kritische Annahme grundsätzlich funktioniert. Das kann beispielsweise eine neue Schnittstelle, eine bestimmte Datenverarbeitung oder die Integration einer Technologie betreffen.

Minimum Viable Product (MVP): Das MVP unterscheidet sich wiederum grundlegend vom Prototyp. Es ist bereits eine tatsächlich nutzbare Produktversion und wird unter realen Bedingungen eingesetzt. Während ein Prototyp nach der gewonnenen Erkenntnis verworfen werden kann, bildet ein MVP üblicherweise die Grundlage für die weitere Produktentwicklung.

Der entscheidende Unterschied liegt damit im Erkenntnisziel: Ein Wireframe klärt Struktur, ein Mockup die visuelle Gestaltung, ein Prototyp Abläufe und Interaktionen, ein PoC technische Machbarkeit und ein MVP die Nutzung einer echten Lösung im Betrieb.

Gerade deshalb sollte ein Prototyp nicht automatisch zur späteren Produktivlösung weiterentwickelt werden. Prototypen werden bewusst schnell und mit begrenztem Aufwand erstellt. Anforderungen an Wartbarkeit, Sicherheit, Skalierbarkeit und langfristige technische Qualität können dabei eine untergeordnete Rolle spielen. Wird ein solcher Entwurf ungeprüft produktiv eingesetzt, kann aus einer kurzfristigen Abkürzung langfristiger technischer Aufwand entstehen.

Vor der Erstellung sollte daher zuerst geklärt werden, welche Frage beantwortet werden muss – und erst danach, welches Artefakt dafür das richtige ist.

Für die Einordnung in den Projektablauf ist ergänzend der Beitrag zum agilen Projektmanagement hilfreich. Prototypen lassen sich besonders gut in iterative Vorgehensweisen integrieren, weil Zwischenergebnisse früh überprüft und Erkenntnisse in die weitere Umsetzung übernommen werden können.

Ein erfolgreicher Prototyp muss deshalb nicht zur Umsetzung führen. Wenn eine ungeeignete Idee früh verworfen wird, hat das Prototyping seinen Zweck ebenfalls erfüllt – bevor aus einer unsicheren Annahme ein teures Entwicklungsprojekt wird.

Prototyping verschiebt Aufwand von der teuren in die günstige Phase. Eine Änderung an einer Skizze kostet Minuten, dieselbe Änderung nach der Umsetzung ein Vielfaches.

Drei Regeln machen den Unterschied:

• So grob wie sinnvoll beginnen, weil ein unfertig wirkender Entwurf ehrlichere Rückmeldungen erzeugt.
• Den Umfang auf einen Vorgang begrenzen, statt das ganze System abzubilden.
• Mit Personen prüfen, die den Entwurf nicht gebaut haben.

Am wichtigsten bleibt die Haltung: Ein Prototyp ist ein Denkwerkzeug, kein Vorabbau. Sein Wert liegt darin, dass er ohne hohe Folgekosten verändert oder verworfen werden kann. Ein erster Entwurf muss deshalb noch nicht alle Fragen beantworten – entscheidend ist, dass er früh genug Erkenntnisse für den nächsten Schritt liefert.

Die DIPS GmbH unterstützt Unternehmen dabei, aus einer ersten Idee eine tragfähige Lösung zu entwickeln. Je nach Ausgangslage werden Anforderungen geklärt, Nutzer und Fachbereiche einbezogen, Lösungsvarianten geprüft und die weitere Umsetzung strukturiert vorbereitet. Prototyping kann dabei ein wichtiger Baustein sein, um kritische Annahmen zu überprüfen, bevor Zeit und Budget in die falsche Richtung fließen.

Prototyping ist das Erstellen eines vorläufigen Modells oder Entwurfs, um Annahmen zu Ablauf, Verständlichkeit, Anforderungen oder Machbarkeit zu überprüfen, bevor eine Lösung vollständig umgesetzt wird. Ein Prototyp dient dabei als Lern- und Entscheidungswerkzeug und kann nach der gewonnenen Erkenntnis angepasst oder verworfen werden.

Zu den häufig verwendeten Detailgraden gehören Low-Fidelity-, Mid-Fidelity- und High-Fidelity-Prototypen. Low-Fidelity-Prototypen eignen sich für frühe Fragen zu Struktur und Ablauf, Mid-Fidelity-Prototypen für Navigation und Interaktion und High-Fidelity-Prototypen für realitätsnahes Nutzerfeedback. Geht es um technische Machbarkeit, kann zusätzlich ein technischer Prototyp beziehungsweise Proof of Concept sinnvoll sein. Grundsätzlich sollte nur so viel Detail eingesetzt werden, wie zur Beantwortung der aktuellen Fragestellung notwendig ist.

Ein Wireframe zeigt vereinfacht die Struktur und Anordnung von Informationen und Funktionen auf einer Oberfläche. Ein Interaktionsprototyp geht darüber hinaus und macht Abläufe oder Übergänge zwischen mehreren Ansichten erlebbar. Technische Prototypen können dagegen bereits ausgewählte echte Funktionen enthalten. Entscheidend ist deshalb immer, welche Fragestellung mit dem jeweiligen Prototyp geprüft werden soll.

Nicht automatisch. Frühe oder bewusst schnell erstellte Prototypen erfüllen häufig noch nicht die Anforderungen produktiver Software an Wartbarkeit, Sicherheit, Skalierbarkeit und technische Qualität. Eine Weiterverwendung kann möglich sein, sollte aber bewusst technisch geprüft werden und nicht allein deshalb erfolgen, weil bereits ein Prototyp vorhanden ist.

Eine feste Zahl gibt es nicht. Sinnvoll sind mehrere kurze Iterationen, bis die für die aktuelle Projektphase entscheidenden Fragen ausreichend geklärt sind. Nach jedem Durchlauf sollte entschieden werden, ob der Prototyp angepasst, weiter verfeinert, technisch geprüft oder bewusst verworfen wird.

Für frühe qualitative Tests reicht häufig eine kleine Gruppe gezielt ausgewählter Personen. Bei einer relativ homogenen Nutzergruppe werden häufig etwa fünf Teilnehmende eingesetzt. Bei mehreren unterschiedlichen Nutzergruppen oder komplexeren Fragestellungen kann eine größere Gruppe erforderlich sein.

Hinweis:
Dieser Beitrag bietet allgemeine Informationen zum Einsatz von Prototypen in Softwarevorhaben. Welcher Detailgrad und welches Vorgehen im Einzelfall sinnvoll sind, hängt von Fragestellung, Projektphase, Beteiligten und Rahmenbedingungen ab.