Was ist der Unterschied zwischen Wireframe, Mockup und Prototyp?

Kurz gesagt

Alle drei sind Wege, einen Screen zu zeigen, bevor er programmiert wird. Der Unterschied ist, wie stark sie dem fertigen Produkt ähneln. Das nennt man Detailtiefe (fidelity).

Die einzelnen Begriffe stehen im Glossar: Wireframe und Prototyp. In diesem Ratgeber erkläre ich den Unterschied zwischen allen dreien und wann ich was nutze.

Was ist ein Mockup?

Ein Mockup ist ein Bild eines Screens, das dem fertigen Produkt ähnelt, aber nicht funktioniert. Wikipedia definiert das Mockup allgemein als maßstabsgetreues oder lebensgroßes Modell eines Designs oder Geräts. In Software ist der häufigste Einsatz, Endnutzern zu zeigen, wie die Software aussehen wird.

Laut demselben Artikel ähnelt ein Software-Mockup dem Original, tut aber nichts über das Sichtbare hinaus. Bietet es zumindest einen Teil der Funktion und erlaubt, das Design zu testen, gilt es als Prototyp. Diese Grenze nutze ich auch: Passiert beim Klick etwas, ist es ein Prototyp.

Im Team nutze ich diese Definition: Das Mockup ist der statische Zustand des Wireframe-Layouts, gekleidet in Farbe, Schrift, echten Text und Bilder. Diese Definition ist meine; in den Quellen werden die Grenzen des Wortes nicht so scharf gezogen.

Auch die Detailtiefe eines Mockups schwankt. In Laubheimers Umfrage steht das „pixel-perfect“ Mockup als eigener Punkt. Der Name beschreibt eine Zeichnung, die Pixel für Pixel dem fertigen Screen gleicht. In den meisten Projekten gehe ich nicht so weit; Details, die eine Entscheidung zu Farbe und Schrift ermöglichen, reichen.

Vergleichstabelle

Kara Pernice von NN/g sieht Detailtiefe nicht als ein einziges Maß. Laut ihr kann sie bei Interaktion, Optik und Inhalt jeweils hoch oder niedrig sein. Lesen Sie jede Zelle der Tabelle als Tendenz.

Kriterium	Wireframe	Mockup	Prototyp
Detailtiefe	Niedrig. Graue Kästen und ein paar Labels.	Visuell hoch, interaktiv keine.	Interaktiv. Kann Papier sein oder eine Datei, die dem fertigen Produkt sehr nahe kommt.
Zweck	Über Platz und Reihenfolge der Elemente sprechen.	Visuelle Entscheidungen wie Farbe und Schrift freigeben lassen.	Den Ablauf mit Nutzern ausprobieren.
Werkzeug	Papier und dicker Stift oder graue Kästen in einem Designwerkzeug.	Designwerkzeug, Komponenten des Designsystems, echte Bilder.	Screens im Designwerkzeug verbinden, Papierprototyp oder Code.
Für wen	Gespräche im Team und die Entwicklung.	Meist externe Kunden.	Testpersonen, Entwicklung und Kunden.
Dauer	Am kürzesten. Ist es falsch, löschen Sie und zeichnen neu.	Mittel. Jede visuelle Entscheidung kostet Zeit.	Am längsten. Auch das Verbinden der Screens ist Arbeit.

Die Zeile Dauer beruht auf meiner eigenen Erfahrung. Stunden nenne ich nicht, weil es stark von der Größe des Screens und der Vorbereitung des Teams abhängt. Auch Pernice schreibt, dass ein klickbarer Prototyp Zeit kosten kann.

Die Zeile „Für wen“ beruht auf einer Umfrage. In Page Laubheimers NN/g-Umfrage von 2015 unter 86 UX-Fachleuten war das statische Wireframe das am häufigsten erstellte Ergebnis. 71 % der Teilnehmenden sagten, sie erstellten es „oft“.

In derselben Umfrage galten pixelgenaue Mockups nur bei externen Kunden als wirksam. In der Kundenarbeit wählten 47 % der Teilnehmenden das Mockup, um Führungskräften Ideen zu vermitteln, nur 25 %. In der Kundenarbeit lag nur ein Ergebnis vor dem Mockup: der klickbare Prototyp mit 67 %.

Auch in der Arbeit mit der Entwicklung war der klickbare Prototyp das wirksamste Ergebnis. Das statische Wireframe kam in dieser Liste unter die ersten fünf.

Ein Screen, drei Detailstufen

Das Beispiel unten ist ein Screen zum Aufladen des Guthabens einer Mobilitätskarte. Das Layout ist in allen drei Zuständen gleich. Es ändert sich nur die Detailtiefe.

Ein Screen, drei Detailstufen

1. Wireframe

Betrag

102050

Aufladen

2. Mockup

←Kartenguthaben

Mobilitätskarte •••• 4821

Guthaben

12,50 €

Betrag zum Aufladen

10 €20 €50 €

20 € aufladen

Bild Die Buttons sind gezeichnet, beim Drücken passiert nichts.

3. Prototyp

Weil JavaScript ausgeschaltet ist, stehen beide Screens untereinander.

←Kartenguthaben1 / 2

Mobilitätskarte •••• 4821

Guthaben

12,50 €

Betrag zum Aufladen

10 € 20 € 50 €

20 € aufladen

Aufladung2 / 2

20 € aufgeladen

Neues Guthaben: 32,50 €

Der Beleg wurde an Ihre E-Mail-Adresse gesendet.

Zum Anfang

Karte, Beträge und Guthaben sind erfunden. Wechseln Sie mit der Auswahl oben zwischen drei Zuständen desselben Screens; das geht auch mit den Pfeiltasten. Wählen Sie im Prototyp einen Betrag und drücken Sie Aufladen, öffnet sich der zweite Screen. Ohne JavaScript stehen die drei Zustände untereinander.

In jeder Stufe stelle ich eine andere Frage. Im Wireframe: Steht die Auswahl des Betrags vor dem Button? Im Mockup: Ist das Guthaben auf der Karte bequem zu lesen?

Im Prototyp beobachte ich den Nutzer. Drückt er den Button, ohne den Betrag zu ändern, bemerkt er auf dem zweiten Screen, dass das Guthaben gestiegen ist? Die Antwort auf diese Fragen sieht man nur auf einem Screen, der sich klicken lässt.

Deshalb schreibe ich zuerst die Frage auf und wähle dann die Detailtiefe. Dreht man die Reihenfolge um, poliert das Team Dinge, deren Antwort es schon kennt.

Wann was

Wireframe: wenn die Struktur noch offen ist

Wird diskutiert, welches Element auf den Screen kommt und in welcher Reihenfolge, beginne ich mit dem Wireframe. Einen grauen Kasten zu löschen, ist billig, und niemand spricht über Farbe. Steht das Layout von Menü und Seiten, also die Informationsarchitektur, geht dieser Schritt schnell.

Kelley Gordon (NN/g) empfiehlt fürs Wireframe einen dicken Stift und ein Zeitlimit. Beides verhindert, dass man an kleinen visuellen Details hängen bleibt.

Mockup: wenn das Aussehen auf Freigabe wartet

Muss über Markenfarbe und Schrift entschieden werden, braucht es ein Mockup. Auch Kontrast und Lesbarkeit zeigen sich zum ersten Mal in dieser Stufe. Kommen Farben und Komponenten aus einem Designsystem, wird die Mockup-Stufe kürzer.

Prototyp: wenn Sie den Ablauf testen

Wollen Sie sehen, ob ein Nutzer eine Aufgabe von Anfang bis Ende erledigen kann, braucht es einen Prototyp. Ein Usability-Test wird mit diesem Material gemacht. Mit wie vielen Personen Sie testen sollten, beschreibe ich im Ratgeber Mit wie vielen Nutzern testen.

Laut Pernice ist es riskant, das fertige Produkt zu testen. Code herauszureißen ist teuer, einen Papierprototyp zu zerreißen nicht.

Ein Beispiel: die Warenkorbseite

Angenommen, Sie gestalten die Warenkorbseite eines Onlineshops neu. Die erste Frage betrifft die Struktur: Stehen die Versandkosten über oder unter der Produktliste? Darüber sprechen Sie im Wireframe, Sie zeichnen zwei oder drei Versionen nebeneinander und vergleichen.

Sitzt das Layout, gehen Sie zum Mockup. Fällt das Feld für den Gutscheincode zu sehr auf, ist die Gesamtsumme groß genug? Das sind Fragen zu Farbe und Schriftgröße.

Im letzten Schritt geben Sie dem Nutzer mit dem Prototyp eine Aufgabe: „Entfernen Sie das zweite Produkt aus dem Warenkorb und gehen Sie zur Kasse.“ Findet der Nutzer den Löschen-Button nicht, hätte Ihnen eine statische Zeichnung das nicht gezeigt. Den Bezahlschritt selbst beschreibe ich im Muster Checkout.

Fragen, die ich bei der Wahl der Detailtiefe stelle

Bevor ich an einem Screen arbeite, stelle ich mir einige Fragen. Die Antworten wählen die Detailtiefe oft von selbst.

1. Was muss ich diese Woche lernen? Wird über das Layout diskutiert, Wireframe; über das Aussehen, Mockup; über den Ablauf, Prototyp.
2. Wem zeige ich es? Wird im Team gesprochen, reicht eine grobe Zeichnung. Gibt ein externer Kunde frei, zählt auch das Aussehen.
3. Was werfe ich weg, wenn es falsch ist? Je teurer das ist, desto gröber beginne ich.
4. Sind die Komponenten fertig? Gibt es ein Designsystem, wird hohe Detailtiefe billig. Sonst wird jeder Screen neu gezeichnet, und das Mockup dauert länger.
5. Wo wird der Nutzer den Screen sehen? Einen Ablauf für das Handy am Desktop-Bildschirm zu testen, führt mich in die Irre. Ich öffne den Prototyp auf dem eigenen Handy des Nutzers.

Diese Liste wende ich nicht in jedem Projekt genau so an. Aber kann ich die ersten zwei Fragen nicht beantworten, zeichne ich noch gar nichts.

Ist diese Reihenfolge Pflicht?

Nein. Auch der Wikipedia-Artikel zum Mockup sagt, dass die drei Begriffe in Software- und Systementwicklung nicht klar getrennt werden. Das ergibt für mich Sinn, weil Detailtiefe nicht auf einer einzigen Linie wächst.

Zeigen Sie Wireframes, die Sie auf Papier gezeichnet haben, nacheinander, haben Sie einen Prototyp mit niedriger Detailtiefe. Verbinden Sie Mockups miteinander, bekommen Sie einen Prototyp mit hoher Detailtiefe. Beides sind Prototypen; sie unterscheiden sich auf der visuellen Achse.

Manchmal lasse ich das Mockup ganz weg. Hat das Produkt ein etabliertes Designsystem, sind die Komponenten schon farbig und fertig. Dann gehe ich vom Wireframe direkt zum klickbaren Prototyp oder in den Code.

Auch das Umgekehrte kommt vor. Bei einer neuen Marke ohne festgelegte visuelle Sprache ziehe ich das Mockup vor. Lösen Farben und Bilder im Team lange Diskussionen aus, hilft es mir, diese Diskussion von den Entscheidungen zum Layout zu trennen.

Häufige Fehler

• Zu frühes Mockup. Wird ein farbiger Screen gezeigt, bevor über das Layout gesprochen wurde, kippt das Meeting in die Farbe. Laut Pernice kritisieren Nutzer ein grobes Design leichter. Dasselbe sehe ich in Meetings mit Stakeholdern.
• Ablauftest mit dem Mockup. Bei einem statischen Bild fragen Sie den Nutzer: „Was passiert, wenn Sie hier drücken?“ Was Sie messen, ist seine Vermutung. Um den Ablauf zu sehen, verbinden Sie die Screens.
• Vor dem Test jeden Screen polieren. Pernice schreibt, dass Designer an Prototypen mit niedriger Detailtiefe weniger hängen. Läuft der Test schlecht, fällt es schwerer, sich von einem polierten Screen zu trennen.
• Der Entwicklung nur ein Mockup geben. Ein statisches Bild zeigt nicht, was beim Drücken passiert, und auch keinen Fehlerzustand. Die Entwicklung muss das raten. Zeichnen Sie auch Fehlermeldungen als Screen.

Meine Notiz

Die meisten Screens, die ich in Audits prüfe, sehen aus, als hätten sie die Wireframe-Stufe nie erlebt. Farben und Bilder sind sorgfältig, aber die Reihenfolge der Elemente passt nicht zur Aufgabe des Nutzers. Die Ursache ist meist der übersprungene erste Schritt.

Meine Standardreihenfolge: Wireframe auf Papier, klickbarer Prototyp mit dem Designsystem, ein kurzer Test, dann Code. Das Mockup mache ich nur als eigenen Schritt, wenn jemand das Aussehen freigeben muss. Auch Laubheimers Umfrage zeigt, dass das Mockup am meisten bei externen Kunden hilft.

Design und Code bei einer Person zu bündeln, verkürzt diese Reihenfolge. Der Design & Ship Sprint ist dafür da: in zwei Wochen vom Wireframe zum funktionierenden Screen in Ihrem Repository. Haben Sie schon ein Produkt live, ist es günstiger, mit dem UX Audit zuerst zu schauen, wo Nutzer hängen bleiben.