Wireframe, Mockup, Prototyp: Was ist der Unterschied?

Montagmorgen, Projektbesprechung. Die Geschäftsführerin sagt: „Schick mir doch mal den Prototyp.“ Der Designer schickt ein PNG mit der fertig gestalteten Startseite. Sie klickt auf den Button „Jetzt buchen“, nichts passiert, und sie schreibt zurück: „Der Prototyp funktioniert nicht.“ Gleichzeitig wartet der Entwickler seit einer Woche auf „die Wireframes“ und bekommt am Ende dasselbe PNG, das er für ein Mockup hält.

Drei Menschen, drei Begriffe, drei unterschiedliche Erwartungen. Wireframe, Mockup und Prototyp gehören zu den Wörtern, die du im UX-Design am häufigsten hörst, und zu denen, die am häufigsten durcheinandergeraten. Das ist mehr als ein Streit um Vokabeln. Wer das falsche Ding zur falschen Zeit baut, diskutiert über Farben, obwohl die Navigation noch nicht steht, oder steckt Tage in einen klickbaren Entwurf, obwohl eine Skizze auf Papier die Frage in einer Stunde beantwortet hätte.

Kurze Definitionen der drei Begriffe findest du im Glossar. In diesem Artikel geht es um die Frage, die danach kommt: Wann brauchst du welchen Entwurf, wie gehen die drei ineinander über, und wem zeigst du was? Ein Beispielprojekt begleitet dich dabei von der ersten Skizze bis zum Test.

Drei Entwürfe, drei Fragen

Die einfachste Art, die drei Begriffe auseinanderzuhalten, ist die Frage, die jeder von ihnen beantwortet. Der Designsoftware-Hersteller Sketch fasst es ähnlich zusammen: Ein Wireframe zeigt die Struktur, ein Mockup das Aussehen und ein Prototyp die Funktion.

Wireframe: Was steht wo?

Ein Wireframe ist der Grundriss einer Seite oder eines App-Screens. Er zeigt, wo Navigation, Überschriften, Texte, Bilder und Buttons hinkommen, meist in Grautönen und mit Platzhaltern für Bilder. Farben, Schriften und Fotos fehlen absichtlich. Figma beschreibt Wireframes als einfache Blaupause mit geringer Detailtreue, die eine Idee in einem frühen Stadium festhält.

Der Wert eines Wireframes liegt genau in dieser Kargheit. Weil nichts hübsch ist, redet niemand über Hübsches. Die Diskussion bleibt bei den Fragen, die zuerst geklärt werden müssen: Was ist das Wichtigste auf dieser Seite? Was muss jemand als Nächstes tun können? Fehlt ein Inhalt?

Mockup: Wie sieht es aus?

Ein Mockup ist ein statischer, visuell ausgearbeiteter Entwurf. Farben, Schriften, Bilder, Abstände und Texte sind weitgehend so, wie sie später im Produkt erscheinen sollen. Bedienen lässt es sich aber nicht. Figma bringt es auf die Formel, dass Mockups sich auf die Form konzentrieren, nicht auf die Funktion.

Mit einem Mockup prüfst du, wie ein Produkt wirkt: Ist der wichtigste Button sofort zu sehen? Passt die Bildsprache zur Marke? Sind Texte gut lesbar? Es ist außerdem das Format, das Auftraggebende, Geschäftsführung oder Investoren am schnellsten verstehen, weil es aussieht wie das, was sie sich vorstellen.

Prototyp: Wie fühlt es sich an?

Ein Prototyp simuliert die Bedienung. Du kannst klicken, tippen, Formulare ausfüllen oder dich durch einen Ablauf bewegen, zumindest so weit, wie es für die jeweilige Frage nötig ist. Ein Prototyp beantwortet Fragen wie: Finden Menschen den Weg von A nach B? Verstehen sie, was nach einem Klick passiert? An welcher Stelle bleiben sie hängen?

Wichtig für Einsteigende: Ein Prototyp muss nicht schön sein. Ein Stapel Papierskizzen, bei dem eine Person die Rolle des Computers spielt und auf jeden „Klick“ die passende Skizze hinlegt, ist genauso ein Prototyp wie ein aufwendiger Entwurf in einem Design-Tool. Die Nielsen Norman Group (NN/g), ein bekanntes Beratungs- und Forschungsunternehmen für Usability, beschreibt einen Prototyp sinngemäß als Hypothese: einen Lösungsvorschlag, der erst noch geprüft werden muss.

Warum die Reihenfolge meist Sinn ergibt

In vielen Projekten kommen die drei Entwürfe in genau dieser Reihenfolge: erst Wireframe, dann Mockup, dann ein detaillierter Prototyp. Figma ordnet Wireframes der frühen Entdeckungsphase zu und Mockups der Gestaltungsphase, bevor es an detaillierte Prototypen und die Übergabe an die Entwicklung geht. Das ist keine Vorschrift, aber es gibt gute Gründe dafür.

Der wichtigste: Jede Entscheidung baut auf der vorherigen auf. Wenn sich im Mockup herausstellt, dass ein ganzer Bereich fehlt oder ein Ablauf umgestellt werden muss, sind alle bisherigen Gestaltungsdetails für diesen Bereich hinfällig. Im Wireframe kostet dieselbe Änderung ein paar Minuten, weil es nur Kästen sind.

Der zweite Grund ist das Feedback. Je fertiger ein Entwurf aussieht, desto eher reden Menschen über Oberflächliches. Die NN/g weist außerdem darauf hin, dass sich Designteams weniger an grobe Entwürfe gebunden fühlen und Testpersonen bei sichtbar unfertigen Entwürfen eher bereit sind, Kritik zu äußern. Ein grober Entwurf signalisiert allen Beteiligten: Hier ist noch alles offen.

Trotzdem ist die Reihenfolge kein Wasserfall, bei dem eine Phase sauber abgeschlossen sein muss, bevor die nächste beginnt. Oft springst du zurück, etwa wenn ein Test am Prototyp zeigt, dass die Struktur nicht trägt. Dann geht es zurück ins Wireframe, und das ist ein gutes Zeichen, kein Scheitern.

Ein Projekt, drei Entwürfe: die Kletterhalle

Wie das im Alltag aussieht, zeigt ein Beispiel. Eine Kletterhalle möchte, dass Gäste ihren Besuch online buchen können: Zeitfenster wählen, Anzahl der Personen angeben, Leihausrüstung dazubuchen, bezahlen. Bisher läuft alles über Telefon und eine Liste am Tresen. Das Team besteht aus einer Designerin, einem Entwickler und der Betriebsleitung der Halle.

Schritt 1: Skizzen und Wireframes

Die Designerin beginnt nicht am Rechner, sondern mit Stift und Papier. In einer halben Stunde entstehen drei grobe Varianten für die Buchungsseite. Variante A zeigt zuerst einen Kalender, Variante B eine Liste der nächsten freien Zeitfenster, Variante C fragt zuerst nach der Anzahl der Personen.

Mit der Betriebsleitung bespricht sie die Skizzen. Schnell wird klar: Die meisten Gäste kommen spontan am selben oder nächsten Tag. Ein Monatskalender ist für sie ein Umweg. Variante B gewinnt, ergänzt um einen kleinen Link „Anderes Datum wählen“. Außerdem fällt auf, dass ein wichtiger Inhalt fehlt: Wer zum ersten Mal klettert, muss eine Einweisung buchen. Das hatte niemand auf dem Zettel.

Danach überträgt die Designerin die Struktur in digitale Wireframes, in Grautönen, aber mit echten Texten statt Platzhaltertext. Erst mit echten Texten zeigt sich, dass „Leihausrüstung (Schuhe, Gurt, Sicherungsgerät)“ nicht in eine schmale Spalte passt.

Schritt 2: Der klickbare Wireframe

Bevor auch nur eine Farbe festgelegt wird, verknüpft die Designerin die Wireframes miteinander. Ein Klick auf ein Zeitfenster führt zur Personenauswahl, von dort zur Ausrüstung, dann zur Zusammenfassung. Das ist bereits ein Prototyp, zwar grau und schlicht, aber bedienbar.

Mit diesem Prototyp lässt das Team fünf Stammgäste am Tresen eine Buchung durchspielen. Das Ergebnis: Vier von fünf übersehen, dass sie die Einweisung für ihre Begleitung extra buchen müssen. Die Lösung, eine einfache Frage „Klettert jemand zum ersten Mal bei uns?“ direkt nach der Personenauswahl, ist im Wireframe in zehn Minuten eingebaut. Wie du einen solchen Test aufsetzt, beschreibt das Glossar unter Usability-Test.

Schritt 3: Mockups

Jetzt, wo Struktur und Ablauf stehen, gestaltet die Designerin die wichtigsten Screens als Mockups: mit den Farben der Halle, dem Logo, Fotos von der Kletterwand und der endgültigen Schrift. Die Betriebsleitung sieht zum ersten Mal, wie die Buchung „in echt“ aussehen wird, und bespricht nur noch Gestaltungsfragen: Ist das Orange zu laut? Sollen die Zeitfenster mit der aktuellen Auslastung angezeigt werden?

Weil die Struktur geprüft ist, verschiebt diese Runde keine Bereiche mehr. Sie schärft das Aussehen. Für die Einheitlichkeit über alle Screens legt die Designerin Farben, Schriftgrößen und Buttons als wiederverwendbare Bausteine an, eine kleine Vorstufe eines Design Systems.

Schritt 4: Der detaillierte Prototyp

Zum Schluss verbindet die Designerin die Mockups zu einem detaillierten Prototyp. Jetzt lassen sich Fragen prüfen, die ein grauer Entwurf nicht beantworten kann: Ist die Auslastungsanzeige verständlich? Ist der Hinweis auf die Einweisung auffällig genug, ohne zu nerven? Wirkt die Seite auf dem Smartphone zu voll?

Der Entwickler nutzt diesen Prototyp außerdem als Referenz für die Umsetzung. Er sieht, welcher Screen auf welchen folgt und wie sich Buttons verhalten. Fragen, die sonst erst während der Programmierung aufgetaucht wären, sind damit früh geklärt.

Wichtig an diesem Beispiel ist weniger die genaue Abfolge als das Prinzip: Jeder Entwurf beantwortet die Frage, die gerade dran ist, und zwar mit so wenig Aufwand wie möglich.

Detailtreue ist kein Schalter

In Gesprächen über Entwürfe fällt schnell der Begriff Fidelity. Gemeint ist die Detailtreue, also wie nah ein Entwurf am fertigen Produkt ist. „Low Fidelity“ steht für grob und skizzenhaft, „High Fidelity“ für nah am Original. Dazwischen liegt manchmal noch „Mid Fidelity“, etwa ein digitaler Wireframe mit echten Texten.

Die NN/g unterscheidet dabei drei Dimensionen, die unabhängig voneinander hoch oder niedrig sein können:

• Interaktivität: Wie viel lässt sich bedienen? Gar nichts, einzelne Klicks oder ganze Abläufe mit Eingaben?
• Visuelle Gestaltung: Wie nah sind Farben, Schriften, Bilder und Abstände am fertigen Produkt?
• Inhalt und Befehle: Stehen echte Texte, Preise und Beschriftungen drin oder Platzhalter?

Mit diesen drei Dimensionen wird klar, warum die Begriffe in der Praxis verschwimmen. Ein Wireframe hat geringe visuelle Detailtreue, kann aber hohe inhaltliche Detailtreue haben, wenn echte Texte drinstehen. Ein Mockup hat hohe visuelle Detailtreue, aber keine Interaktivität. Verknüpfst du die Screens eines Mockups, erhöhst du nur die Interaktivität, und aus dem Mockup wird ein Prototyp. Das ist auch der Grund, warum der klickbare Wireframe aus dem Beispiel schon als Prototyp zählt.

Die Forschenden Stephanie Houde und Charles Hill haben bereits 1997 in einem viel zitierten Beitrag vorgeschlagen, Prototypen nicht nach Werkzeug oder Optik zu sortieren, sondern danach, welche Frage sie beantworten. Sie unterscheiden drei Arten von Fragen: zur Rolle eines Produkts im Leben der Menschen, zu seinem Look and Feel, also dem konkreten Sinneseindruck bei der Benutzung, und zur Umsetzung, also wie es technisch funktioniert. Ein Prototyp ist für sie jede Darstellung einer Designidee, egal in welchem Medium. Für den Alltag heißt das: Bevor du einen Entwurf baust, entscheide, was du herausfinden willst. Daraus ergibt sich, in welcher Dimension er detailliert sein muss und wo grob genügt.

Was die Forschung über grobe Prototypen sagt

Eine häufige Sorge bei Einsteigenden lautet: Wenn ich mit Papier oder grauen Kästen teste, sind die Ergebnisse dann überhaupt aussagekräftig? Die Forschung dazu ist ermutigend. Jeff Sauro von MeasuringU hat 2017 eine Reihe von Studien zusammengefasst, die Prototypen unterschiedlicher Detailtreue verglichen haben.

Mehrere davon, etwa von Virzi, Sokolov und Karis (1996) sowie Walker, Takayama und Landay (2002), fanden keinen wesentlichen Unterschied in der Anzahl der entdeckten Usability-Probleme zwischen Papier- und Computerprototypen. Walker und Kollegen beobachteten allerdings, dass sich die Art der gefundenen Probleme unterschied. In einer Studie von Sefelin und Kollegen (2003) äußerten Testpersonen bei Papier- und Computerprototypen ähnlich viel Kritik, 92 % bevorzugten aber den Computerprototyp.

Sauros Fazit: Grobe Prototypen sind ein vernünftiger, wenn auch kein perfekter Ersatz, um Usability-Probleme zu finden. Weniger zuverlässig sind sie, wenn es um Bearbeitungszeiten oder um die Bewertung des Aussehens geht. Das deckt sich mit dem Prinzip von oben: Für Fragen zu Struktur und Ablauf reicht grob. Für Fragen zu Wirkung und Tempo brauchst du mehr Detail.

Wer bekommt was zu sehen?

Ein großer Teil der Verwirrung aus der Einleitung entsteht, weil verschiedene Menschen im Projekt Unterschiedliches brauchen. Ein paar Faustregeln helfen.

Das eigene Team profitiert am meisten von Wireframes und Skizzen. Hier wird über Struktur, Inhalte und Abläufe entschieden, und je schneller sich Varianten erzeugen und verwerfen lassen, desto besser.

Auftraggebende und Geschäftsführung verstehen Mockups und detaillierte Prototypen am leichtesten. Zeigst du ihnen Wireframes, sag vorher deutlich, worum es geht: „Das ist der Grundriss, Farben und Bilder kommen später. Heute geht es nur darum, ob alles Wichtige drauf ist.“ Sonst kommt garantiert die Frage, ob die Website wirklich grau wird.

Testpersonen bekommen immer einen Prototyp, denn nur mit etwas Bedienbarem lässt sich beobachten, wie Menschen sich verhalten. Wie detailliert er ist, hängt von der Testfrage ab.

Entwicklerinnen und Entwickler brauchen vor allem Klarheit: Welche Screens gibt es, wie hängen sie zusammen, wie sehen sie in verschiedenen Zuständen aus? Ein detaillierter Prototyp mit Mockups ist dafür eine gute Grundlage. Noch hilfreicher ist es, sie schon bei den Wireframes einzubinden. Dann fällt früh auf, wenn etwas technisch schwierig oder teuer wird.

Egal wem du etwas zeigst: Schreib dazu, was es ist und was nicht. Ein Satz wie „Mockup, nicht klickbar“ oder „Prototyp, nur der Buchungsweg funktioniert“ verhindert das Missverständnis vom Montagmorgen.

Typische Missverständnisse

„Ein Prototyp muss fast fertig aussehen“

Nein. Ein Prototyp ist durch die Bedienbarkeit definiert, nicht durch die Optik. Eine Papierskizze, bei der eine Person die Rolle des Computers übernimmt, ist ein vollwertiger Prototyp für frühe Fragen. Die NN/g nennt als Nachteil solcher statischen Prototypen allerdings, dass die Person, die den Computer spielt, auch Fehler machen kann. Etwas Übung vor dem Test lohnt sich also.

„Jedes Projekt braucht alle drei“

Auch nein. Bei einer kleinen Änderung an einem bestehenden Produkt mit fertigem Design System kann es sinnvoll sein, direkt im Mockup zu arbeiten, weil Farben und Bausteine ohnehin feststehen. Umgekehrt reicht für eine interne Verwaltungsoberfläche vielleicht ein klickbarer Wireframe, wenn das Aussehen kaum eine Rolle spielt. Entscheidend ist die Frage, die du klären willst, nicht eine feste Abfolge.

„Wenn der Prototyp steht, muss nur noch programmiert werden“

Ein Prototyp simuliert ein Produkt, er ist keins. Fehlerfälle, leere Zustände, Ladezeiten, echte Daten und Sonderfälle fehlen meist. Ein Prototyp ist auch kein Minimum Viable Product: Ein MVP ist eine erste echte Version, die Menschen tatsächlich nutzen. Ein Prototyp dient zum Lernen und darf danach weggeworfen werden.

„Der Name ist doch egal“

Fast. Welchen Begriff du verwendest, ist zweitrangig, solange alle im Team dasselbe darunter verstehen. Gerade deshalb lohnt es sich, die Begriffe zu Projektbeginn einmal kurz abzustimmen. Das kostet fünf Minuten und spart einige Missverständnisse.

So entscheidest du im Alltag

Wenn du vor einer neuen Aufgabe stehst und unsicher bist, womit du anfangen sollst, helfen drei Fragen.

Was will ich herausfinden? Geht es um Struktur und Inhalte, reicht ein Wireframe. Geht es um Wirkung und Gestaltung, brauchst du ein Mockup. Geht es darum, ob Menschen einen Ablauf schaffen, brauchst du einen Prototyp.

Wie sicher bin ich mir schon? Je mehr noch offen ist, desto gröber darf der Entwurf sein. Grobe Entwürfe laden zum Verwerfen ein, und das ist am Anfang genau richtig.

Wer muss es verstehen? Für das eigene Team reicht oft eine Skizze. Für Auftraggebende, Testpersonen oder die Entwicklung brauchst du mehr Detail, aber nur in der Dimension, auf die es gerade ankommt.

Ein Beispiel: Du sollst eine Filterfunktion für einen Onlineshop entwerfen. Ob die Filter links, oben oder in einem ausklappbaren Bereich sitzen, klärst du mit ein paar Wireframes. Ob Menschen verstehen, wie sich mehrere Filter kombinieren lassen, prüfst du mit einem klickbaren Prototyp, der ruhig grau bleiben darf. Ob die Filter-Chips gut lesbar und vom Rest der Seite unterscheidbar sind, zeigt erst ein Mockup.

Welches Werkzeug du dafür nutzt, ist zweitrangig. Viele Teams arbeiten heute alle drei Stufen in einem Tool wie Figma ab. Für die ersten Skizzen sind Papier und Stift trotzdem oft schneller als jede Software.

Fazit

Wireframe, Mockup und Prototyp sind keine Stufen, die du abhaken musst, sondern Werkzeuge für unterschiedliche Fragen. Der Wireframe klärt, was wo steht. Das Mockup zeigt, wie es aussieht. Der Prototyp lässt dich prüfen, ob es funktioniert. Die Grenzen sind fließend: Ein klickbarer Wireframe ist schon ein Prototyp, ein verknüpftes Mockup ebenfalls.

Die wichtigste Gewohnheit für den Einstieg ist deshalb nicht, die Definitionen auswendig zu kennen, sondern vor jedem Entwurf kurz innezuhalten: Was will ich herausfinden, und was ist der kleinste Entwurf, der mir das zeigt? Wer so arbeitet, streitet seltener über Farben, bevor die Struktur steht, und findet Probleme dann, wenn sie noch günstig zu beheben sind.

Checkliste

• Vor jedem Entwurf ist klar, welche Frage er beantworten soll.
• Struktur und Inhalte sind im Wireframe geklärt, bevor über Farben gesprochen wird.
• Wireframes enthalten früh echte Texte statt Platzhaltertext.
• Abläufe werden mit einem klickbaren Prototyp getestet, notfalls grau oder auf Papier.
• Die Detailtreue ist nur dort hoch, wo es für die Frage nötig ist.
• Jeder geteilte Entwurf ist beschriftet: Wireframe, Mockup oder Prototyp, und was davon funktioniert.
• Die Begriffe sind zu Projektbeginn mit dem Team und den Auftraggebenden abgestimmt.
• Die Entwicklung ist früh eingebunden, nicht erst beim fertigen Prototyp.

Quellen

• Kara Pernice: UX Prototypes: Low Fidelity vs. High Fidelity. Nielsen Norman Group, 2016
• Figma: Wireframe vs. mock-up: what’s the difference? Figma Resource Library
• Sketch: Wireframe vs mockup vs prototype: What’s the difference? Sketch Blog
• Stephanie Houde, Charles Hill: What Do Prototypes Prototype? In: Handbook of Human-Computer Interaction, 2. Auflage, Elsevier, 1997
• Jeff Sauro: Does the Fidelity of a Prototype Affect Results? MeasuringU, 2017
• Hoa Loranger: Paper Prototyping. Nielsen Norman Group, 2011