KI-Prototyping direkt in der App: Warum Mozilla Usability-Tests aus Figma holt

Ein Klickprototyp in Figma zeigt nur die Pfade, die jemand vorher angelegt hat. Genau daran scheitern laut Mozilla viele Usability-Tests, weil die Testpersonen an die Grenzen des Prototyps stoßen und nicht an die des Designs. Das Firefox-Team baute seinen Testprototyp deshalb mit dem KI-Assistenten Claude direkt in die Android-App und prüft nun, ob echte Tests verlässlichere Ergebnisse liefern.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

KI-Prototyping verschiebt gerade, wo Design entsteht: nicht mehr allein auf der Figma-Leinwand, sondern direkt im Code der laufenden App. Für die Funktion „Report Broken Site“ wählte das Firefox-UX-Team genau diesen Weg und baute den Testprototyp mit Claude in Firefox für Android. Dahinter steckt eine unbequeme Frage: Prüft ein Usability-Labor das Design oder nur die Grenzen des Prototyps?

Das Wichtigste in Kürze

• Mozilla baut UX-Prototypen mit dem KI-Assistenten Claude direkt in Firefox für Android, statt sie in Figma zu klicken.
• Der Grund: Klickprototypen geben nur vorgedachte Pfade frei und verfälschen so den Usability-Test.
• Im echten App-Code funktionieren Texteingabe, Tastatur und dynamische Inhalte wie im fertigen Produkt.
• Der Ansatz verlangt Terminal- und Entwicklungskenntnisse und steckt bei Mozilla noch in der Erprobung.

Was steckt hinter Native Fidelity Prototyping?

Native Fidelity Prototyping heißt, den Prototyp nicht in einem Design-Werkzeug nachzustellen, sondern ihn mit KI-Hilfe in die echte Anwendung zu bauen. Mozilla setzte dafür Claude ein und ergänzte die Funktion „Report Broken Site“ unmittelbar im Quellcode von Firefox für Android, statt den Umweg über Figma zu nehmen.^[1] Der Prototyp erbt so die Umgebung des Geräts: Tastatur, Texteingabe, dynamische Inhalte und das Verhalten bei wechselnden Bildschirmgrößen.

Der Unterschied klingt technisch, entscheidet aber über die Aussagekraft jedes Tests. Ein klassischer Klickprototyp bildet nur ab, was das Team vorab an Bildschirmen und Verbindungen angelegt hat. Alles andere bleibt tote Fläche, und genau dort trennt sich gutes Webdesign von schnell generierten Oberflächen.

Warum verfälschen Figma-Prototypen den Usability-Test?

Klickprototypen lenken das Verhalten im Test, weil ihre Grenzen für die Nutzer sichtbar bleiben. Reagiert im Prototyp nur ein einziger Button, raten die Testpersonen den vorgesehenen Pfad, statt frei zu erkunden. Die Nielsen Norman Group beschreibt dieses Muster seit Jahren: Zu glatte oder zu langsame Prototypen ziehen die Aufmerksamkeit auf Optik und Details statt auf die eigentliche Bedienung.^[2]

Im echten App-Code fallen genau die Lücken auf, die ein Design-Werkzeug übertüncht. Fehlende Zustände, unklare Rückmeldungen und Sonderfälle bei der Eingabe zeigen sich schon beim Bauen, nicht erst im Nachhinein. Damit testet Mozilla am Ende das Produkt und nicht die Bühne davor.

Was heißt das für Agenturen und Teams im DACH-Raum?

Für DACH-Agenturen verschiebt der Ansatz die Anforderungen an ein UX-Team spürbar. Native Fidelity Prototyping verlangt Sicherheit im Terminal, in Build-Umgebungen und in einer Entwicklungsumgebung, was Mozilla selbst als hohe Einstiegshürde benennt.^[1] Kleinere Studios ohne Entwicklerin im Team stoßen hier schneller an eine Grenze als beim vertrauten Klickprototyp, den auch quelloffene Werkzeuge wie das selbst gehostete Penpot abbilden.

Zugleich zieht der Markt in dieselbe Richtung. Figma verbindet sein Werkzeug Figma Make inzwischen mit dem Code der Anwendung und erzeugt aus einem Prompt lauffähige, code-gestützte Prototypen statt bloßer Attrappen.^[3] Der Graben zwischen Entwurf und fertigem Produkt wird also von beiden Seiten kleiner, ähnlich wie beim Trend zu reinen Skizzen als Ausgangspunkt.

Den größten Hebel bietet der Ansatz bei der Barrierefreiheit. Seit dem 28. Juni 2025 verlangt das Barrierefreiheitsstärkungsgesetz von vielen digitalen Angeboten den Standard WCAG 2.1 AA, und echte Tastaturbedienung oder Screenreader-Verhalten lassen sich in einem Figma-Klick kaum prüfen. Ein Prototyp im echten Code erbt diese Eigenschaften vom Gerät und macht Barrieren früh sichtbar, lange bevor ein KI-Scanner am fertigen Produkt nachbessert.

Der Rat für Entscheider lautet nicht, Figma abzuschaffen. Sinnvoll ist ein zweistufiges Vorgehen: frühe Ideen weiter schnell in Design-Werkzeugen klären und die entscheidende Testrunde mit einem KI-gebauten Prototyp im echten Code absichern. So misst der Usability-Test das Design und verwechselt die Schwächen des Werkzeugs nicht länger mit denen des Entwurfs.

Quellen

[1] Mozilla Firefox UX: „Let your designs fail for the right reasons“

[2] Nielsen Norman Group: „UX Prototypes: Low Fidelity vs. High Fidelity“

[3] Figma: „4 New Ways to Go From Idea to Product With AI Tools“

Mehr Newshunger?

• Penpot: Die quelloffene Figma-Alternative, die europäische Teams selbst hosten
• Das letzte Design-Tool? Warum Designer nur noch skizzieren
• Barrierefreiheit per KI-Scanner: Was A11yEngine leistet und wo das BFSG mehr verlangt
• Die KI liest zuerst: Was gutes Webdesign von schnell generierten Oberflächen trennt
• State of AI in Design Systems: Wie sich 20 Design-Systeme für KI-Agenten öffnen
• KI macht das Design-Handwerk billig: Jetzt entscheidet die Haltung über den Wert