Sie betreten ein Musterhaus. Die Tür schwingt auf, das Licht geht an, der Parkettboden glänzt. Sie öffnen den Kühlschrank. Leer. Sie drehen am Wasserhahn. Nichts. Und trotzdem wissen Sie nach zehn Minuten, ob Sie hier wohnen wollen, ob die Wege stimmen, ob die Küche zu nah am Schlafzimmer liegt.

Niemand hat dafür ein echtes Haus gebaut.

Ein Clickdummy funktioniert nach genau diesem Prinzip. Er ist das Musterhaus Ihrer künftigen Website, App oder Software: begehbar, anklickbar, erlebbar. Nur eben ohne das Mauerwerk dahinter.

Ein Clickdummy macht Nutzerflüsse früh erlebbar und hilft, Fehlerzustände und Bedienprobleme vor der Entwicklung zu erkennen.

Was ist ein Clickdummy?

Ein Clickdummy (auch Klickdummy, klickbarer Prototyp oder englisch clickable prototype) ist ein interaktives, aber bewusst funktionsarmes Modell einer digitalen Oberfläche. Er simuliert Navigation, Zustandswechsel und die zentralen Bedienabläufe einer Website, Web-App oder Mobile-App, ohne dahinterliegende Programmlogik und ohne echte Daten.

Klicken Sie auf „Bestellen“, wechselt der Bildschirm. Bestellt wird nichts. Tippen Sie auf „Anmelden“, öffnet sich die nächste Ansicht. Aber niemand prüft Ihr Passwort. Die Fassade reagiert, das Gebäude steht noch nicht.

Genau darin liegt der Sinn: Sie erproben Strukturen, Nutzerflüsse und das Nutzungserleben, holen belastbares Feedback ein und bringen alle Beteiligten auf ein gemeinsames Bild. Lange bevor auch nur eine Zeile teurer Code geschrieben ist.

Ein Clickdummy macht eine Oberfläche begeh- und navigierbar, bevor sie vollständig entwickelt wird.

Warum klicken, bevor gebaut wird?

Stellen Sie sich die Alternative vor. Ein Team programmiert sechs Monate lang einen Checkout. Dann setzt man echte Menschen davor. Und merkt: Niemand findet den Bezahlknopf.

Sechs Monate. Für eine Erkenntnis, die ein Nachmittag mit einem Clickdummy geliefert hätte.

Die Nielsen Norman Group betont seit Jahren, dass Usability-Tests mit Prototypen der schnellste Weg sind, Schwachstellen aufzuspüren, Chancen zu erkennen und das Verhalten echter Menschen zu verstehen, bevor die Entwicklung beginnt. Ein Klickmodell kostet Stunden. Ein fertiges Produkt umzubauen kostet Wochen.

Was würde sich in Ihrem nächsten Projekt ändern, wenn Sie die teuersten Fehler vor der Entwicklung sehen könnten statt danach?

Einordnung im Human-Centered-Design (ISO 9241-210)

Im Human-Centered-Design (HCD) nach ISO 9241-210 entstehen gute Systeme nicht in einem Wurf, sondern in Schleifen: Kontext verstehen, Anforderungen ableiten, Lösungen entwerfen, durch Prototypen prüfen, Erkenntnisse zurückführen. Dann von vorn.

Der Clickdummy ist in dieser Schleife kein Beiwerk. Er ist ein Kernartefakt. Er macht frühe Evaluation überhaupt erst möglich, ohne dass jemand teuren Code anfasst. Die Fassung von 2019 nennt genau diese prototypische Evaluation als feste HCD-Aktivität.

Wireframe, Mockup, Clickdummy: drei Worte, drei Dinge

Diese Begriffe werden gern in einen Topf geworfen. Dabei beschreiben sie verschiedene Reifegrade:

• Wireframe. Das Strukturbild. Statisch, schematisch, oft grau in grau. Hier geht es um Informationsarchitektur und Anordnung, nicht um Schönheit. Der Grundriss, bevor die Wände stehen.
• Mockup. Die ausgestaltete Ansicht. Farben, Schrift, Bildsprache. Sieht fertig aus, lässt sich aber meist nicht bedienen. Das Foto vom eingerichteten Zimmer.
• Clickdummy / Prototyp. Das begehbare Modell. Interaktiv, mit Zuständen und Übergängen, von grob bis produktnah.

Mehrere Übersichten, von Miro über Justinmind bis GeeksforGeeks, bringen es auf denselben Nenner: Wireframes sind statisch und strukturorientiert, Prototypen interaktiv und erlebnisorientiert. Das Mockup liegt dazwischen.

Fidelity: Wie fertig darf es aussehen?

Fidelity beschreibt, wie nah der Clickdummy am späteren Produkt liegt, visuell, inhaltlich, im Verhalten. Beim Musterhaus ist das der Unterschied zwischen Rohbau und voll möblierter Wohnung.

• Low-Fidelity (Lo-Fi). Grob, schnell, oft einfarbig. Der Fokus liegt auf Kerngedanke und Informationsarchitektur. Der Rohbau mit Kreidestrichen an der Wand. Ideal für frühe Ideen- und Navigationsfragen.
• Mid-Fidelity. Erste visuelle Stile, realistischere Abläufe, einzelne Sonderfälle wie Fehler- oder Leerzustände.
• High-Fidelity (Hi-Fi). Produktnahe Interaktionen, feine Mikroanimationen, finale Optik. Sinnvoll kurz vor der Umsetzungsfreigabe oder für realitätsnahe Usability-Tests.

Und hier lauert eine Falle, die viele übersehen: Je fertiger ein Clickdummy aussieht, desto höflicher wird das Feedback. Wer ein hochglänzendes Modell vor sich hat, traut sich kaum noch zu sagen, dass der Weg zur Kasse Unsinn ist. Es wirkt ja schon beschlossen.

Das ist nicht Sorgfalt. Das ist Over-Fidelity.

Darum gilt: Bei konzeptionellen Fragen bewusst „rough“ starten. Ein paar Kreidestriche laden eher zum Widerspruch ein als eine fertig tapezierte Wand.

Wofür ein Clickdummy konkret taugt

Ein gutes Klickmodell beantwortet Fragen, die sonst erst der Live-Betrieb beantwortet. Etwa:

• Hypothesen prüfen. Versteht man den neuen Checkout, ohne dass jemand danebensteht?
• Nutzerflüsse schärfen. Wo verlaufen sich Menschen, wo brechen sie ab, wo gehen sie zurück?
• Stakeholder zusammenbringen. Sehen alle dieselbe Lösung vor sich, klickbar statt nur beschrieben?
• Aufwand abschätzen. Wie groß wird die Entwicklung, wenn man alle Zustände und Sonderfälle einmal sichtbar macht?

Das Stakeholder-Alignment ist dabei der unterschätzte Effekt. Zehn Menschen reden drei Meetings lang aneinander vorbei. Ein klickbarer Prototyp beendet die Debatte in zehn Minuten, weil endlich alle dasselbe sehen.

Was in einen guten Clickdummy gehört

Der Unterschied zwischen einem netten Klickmodell und einem belastbaren liegt selten im reibungslosen Hauptweg. Er liegt in den Momenten, in denen etwas schiefgeht.

• Zustände. Normal, Fokus, Fehler, Leer, Ladend, Erfolg. Genau diese Zwischenzustände erzeugen später die meiste Reibung. Und genau sie werden im Prototyp am häufigsten vergessen.
• Interaktionen. Klickflächen, Übergänge mit Timing und Easing, Overlays, Scrollbereiche. In Figma lassen sich mehrere Flows mit eigenen Startpunkten anlegen, sodass jede Journey sauber für sich steht.
• Flows. Einstiegspunkte, der gewünschte Weg, die Umwege, die Fehlerpfade. Inklusive Zurück-Navigation.
• Kommentare. Notizen für Reviewer und Entwicklung, etwa im Axure Prototype Player mit seinen Widget Notes.

Die Werkzeuge: womit gebaut wird

Die Toolwahl ist keine Glaubensfrage. Sie ist eine Frage der Aufgabe.

Figma ist heute die erste Wahl für die meisten Teams. Universell von Lo-Fi bis Hi-Fi, stark in der Zusammenarbeit verteilter Teams, mühelos zu teilen für Reviews und Freigaben. Wer schnell iterieren und gemeinsam an einer Datei arbeiten will, beginnt hier.

Axure RP spielt seine Stärke aus, sobald es kompliziert wird: konditionales Verhalten, verzweigte Abläufe, datennahe Simulationen über Events, Cases und Actions. Das Werkzeug für regelintensive Formulare und Prozesse mit vielen Edge-Cases.

ProtoPie wird interessant, wenn Sensorik, Gesten und feine Mikrointeraktionen auf Geräteniveau gefragt sind. Das Trigger/Response-Modell und die Interaction Recordings liefern eine Spezifikation, mit der die Entwicklung direkt weiterarbeiten kann.

Framer lohnt sich, wenn Animation und Web-Nähe im Vordergrund stehen, etwa bei stark bewegten Marketing- und Produktseiten.

Und Adobe XD? Lange war es ein Standardwerkzeug, es taucht in vielen älteren Anleitungen auf. Doch seit 2023 steckt es im Wartungsmodus: Adobe entwickelt es nicht mehr weiter und verkauft es nicht mehr an neue Kundschaft. Für neue Projekte ist es daher keine ehrliche Empfehlung mehr, auch wenn sich bestehende Dateien noch öffnen lassen. Wer heute startet, fährt mit Figma deutlich sicherer.

Die Faustregel bleibt nüchtern: Das richtige Werkzeug ist eine Funktion aus Anforderung und Team-Können, nicht aus Marketing.

Barrierefreiheit von Anfang an

Ein Gedanke, der gern bis nach der Entwicklung wartet. Und genau deshalb teuer wird.

Was im Prototyp als Barriere angelegt ist, wandert in den Code. Der W3C beschreibt mit den WCAG 2.2 die international maßgeblichen Richtlinien, getragen von den vier POUR-Prinzipien: Perceivable, Operable, Understandable, Robust. Also wahrnehmbar, bedienbar, verständlich, robust.

Für den Clickdummy heißt das ganz handfest:

• Tastaturwege mitdenken, nicht nur Maus und Touch.
• Eine sichtbare, sinnvolle Fokus-Reihenfolge.
• Zustände wie Fokus und Fehler klar unterscheidbar gestalten.

Praxisnahe Anleitungen liefern die WAI-Tutorials, die Best-Practice-Guides und Beiträge wie der von UXPin zum barrierefreien Prototyping.

Dass WCAG 2.2 im Oktober 2025 auch als ISO/IEC 40500:2025 anerkannt wurde, zeigt das Gewicht der Sache. Zugänglichkeit ist kein nachträglicher Anstrich. Sie gehört in den Grundriss.

Die häufigsten Fehler, und wie Sie sie umgehen

• Zu großer Scope. Wer alles prototypisieren will, lernt nichts schnell. Priorisieren Sie die entscheidenden Wege: Onboarding, Suche, Checkout.
• Zu viel Politur. Ein zu fertiges Modell erstickt ehrliches Feedback. Die Fidelity richtet sich nach der Frage, nicht nach dem Ehrgeiz.
• Fehlende Zustände. Fehler, Leerzustand, Ladevorgang werden vergessen. Und genau dort scheitert später der Betrieb.
• Kein Heuristik-Check. Offensichtliche Schwächen hätte ein kurzer Blick anhand der Nielsen-Heuristiken vorab gefunden.
• Accessibility erst zum Schluss. Was nicht im Prototyp mitgedacht wird, kostet im Code das Doppelte.

FAQ

Ist ein Clickdummy eine echte Website oder App?
Nein. Er simuliert Interaktion und Zustände, ohne Programmlogik und ohne echte Daten. Das ist kein Mangel, das ist der Sinn: früh testen, spät bauen, Risiko senken.

Welche Fidelity ist die richtige?
Die, die Ihre Frage beantwortet. Lo-Fi für Struktur und Navigation, Hi-Fi für Interaktionsdetails und Realismus. Behalten Sie den Over-Fidelity-Effekt im Blick.

Wie teste ich effizient?
Mit klaren Aufgaben, passenden Metriken und dem richtigen Testmodus, moderiert oder unmoderiert, vor Ort oder per Fernzugriff. Bewährte Größen: Task-Success-Rate (erfolgreich erledigte Aufgaben), Time-on-Task (Effizienz), Error-Rate und Path-Deviation (Abweichungen vom erwarteten Weg) sowie qualitative Signale wie Unsicherheit und Zögern.

Wie passt das zu Standards?
Clickdummys sind HCD-Bausteine nach ISO 9241-210. WCAG und die POUR-Prinzipien sollten früh mitgedacht werden, damit keine Barriere in den Code wandert.

Ein letzter Gedanke

Der teuerste Fehler ist der, den man erst im fertigen Gebäude entdeckt. Der billigste ist der, den man im Musterhaus bemerkt, bevor der Bagger anrückt.

Ein Clickdummy ist nichts anderes als die Erlaubnis, einen Raum zu betreten, der noch nicht existiert. Und sich umzudrehen, solange das Umbauen noch nichts kostet.

Welche Entscheidung in Ihrem nächsten Projekt würden Sie lieber im Musterhaus treffen als auf der Baustelle?