Prototyp
Definition: Ein Prototyp (auch: Klick-Dummy, interaktiver Prototyp, Design-Prototyp) im UX/UI-Kontext ist eine simulierte, interaktive Darstellung eines Produkts, einer Funktion oder eines Nutzerflows die Interaktion ohne vollständige technische Implementierung ermöglicht – Prototypen dienen der frühzeitigen Testbarkeit von Designhypothesen, der Usability-Evaluation mit echten Nutzern und der Stakeholder-Kommunikation vor kostspieligem Entwicklungsaufwand. Prototyp-Fidelity-Spektrum: Lo-Fi-Prototyp (Low Fidelity; niedrige Detailtreue; Papierprototyp; Wireframe mit handgezeichneten Klickpfaden; schnell; günstig; geeignet für frühe Strukturtest-Fragen; verhindert dass Tester sich auf visuelle Details statt Struktur fokussieren); Mid-Fi-Prototyp (digitale Wireframes mit Klickpfaden; Figma-Wireframes mit einfachen Transitions; moderater Aufwand; für Navigations- und Flow-Tests); Hi-Fi-Prototyp (High Fidelity; finale Farben, Typografie, reale Inhalte; Figma Smart Animate; für Micro-Interaction-Tests und Stakeholder-Demos; aber: höherer Aufwand). Horizontaler Prototyp vs. vertikaler Prototyp: Horizontaler Prototyp: breite Abdeckung aller Hauptbereiche mit wenig Tiefe; zeigt die gesamte Navigation; jede Funktion nur oberflächlich; ideal für Navigation-Tests und Information-Architecture-Evaluation; Vertikaler Prototyp: ein spezifischer Flow in voller Tiefe (z.B. kompletter Checkout-Prozess); ideal für detaillierte Usability-Tests eines kritischen Workflows. Coded Prototype (Entwicklungs-Prototyp): in Code implementiert; echte Performance; reale Daten; höchste Fidelity; für finale Validierung vor Launch und Performance-Tests.
Erläuterung
Die Geschichte des Prototypings im Design entstammt dem industriellen Produktdesign wo physische Modelle («Mock-ups» aus dem englischen «to mock up» = nachahmen) vor der Serienproduktion gebaut wurden um Form, Funktion und Fertigungsprozesse zu validieren. Bill Buxton (Principal Researcher; Microsoft Research; Cambridge; England/Redmond; WA; «Sketching User Experiences: Getting the Design Right and the Right Design», Morgan Kaufmann Publishers, 2007) transformierte diese Denkweise für das Interface-Design: Buxton's Kernthese war dass Design-Teams zu früh zu detaillierte Designs erstellen («getting the design right») ohne sicherzustellen dass sie überhaupt die richtige Design-Richtung einschlagen («getting the right design»); Lo-Fi-Prototypen und Skizzen ermöglichen es mehr Designideen in kürzerer Zeit zu explorieren bevor man sich auf eine festlegt. Carolyn Snyder (User Interface Engineering; Burlington; MA; «Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces», Morgan Kaufmann, 2003) systematisierte Papierprototyping als Forschungsmethode: physische Schnittstellen-Simulationen aus Papier die von einem «menschlichen Computer» (Teamkollege der die System-Reaktionen simuliert) gesteuert werden; Snyders Studien zeigten dass Papierprototyp-Tests 80% der Usability-Probleme aufdecken die auch mit digitalen Prototypen gefunden würden bei einem Bruchteil des Aufwands. Jakob Nielsen (Nielsen Norman Group; Fremont; CA; «Usability Engineering», Morgan Kaufmann, 1993) etablierte Prototyping als zentrale Technik des Usability-Engineering: sein Iterativer-Design-Prozess (Design → Prototyp → Test → Überarbeiten → Prototyp → Test) ist die methodische Grundlage für nutzerzentriertes Design. IDEO (Design-Consultancy; Palo Alto; CA; gegründet von David Kelley 1991; «The Art of Innovation», David Kelley/Tom Kelly, Doubleday, 2001) formalisierte «Fail Early, Fail Often» als Prototyping-Philosophie: lieber zehn schnelle physische Modelle ausprobieren als ein perfektes entwickeln; diese Philosophie wurde zur Grundlage des Design-Thinking-Prozesses (Empathize → Define → Ideate → Prototype → Test). Jake Knapp (Google Ventures; San Francisco; CA; «Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days», Simon & Schuster, 2016; gemeinsam mit John Zeratsky und Braden Kowitz) formalisierte den «Design Sprint» als 5-tägigen Prozess der einen Prototyp am Donnerstag erzeugt der am Freitag mit 5 Nutzern getestet wird; Knapp's Prototyp-Ziel war dabei bewusst ein «Facade» – ein oberflächlich realistisch aussehendes Interface das echte Reaktionen provoziert ohne echte Funktionalität zu haben; Tools: Keynote, Figma oder Prototyp-Tools die schnelle Erstellung in 6–8 Stunden ermöglichen. Figma (Dylan Field und Evan Wallace; San Francisco; CA; erste öffentliche Version 2016) revolutionierte digitales Prototyping durch den direkten Prototyp-Flow innerhalb des Designtools: statt Designs in InVision zu importieren können Designer in Figma direkt Klickpfade zwischen Frames anlegen; Smart Animate (Figma, 2019) ermöglicht automatisch flüssige Transitions zwischen Frames die ähnliche Elemente enthalten; Overlay-Patterns für Modals und Drawers; auch Component Properties und Variables für zustandsbasierte Prototypen.
Prototyp-Typen, Tools und Fidelity-Entscheidungen
- Figma-Prototyping und Transition-Design: Figma Prototyping Grundlagen: Frames als Screens; Connections (Pfeile zwischen Frames) definieren Klickpfade; Hotspot: klickbare Bereiche im Frame; Trigger: On Click, On Hover, On Drag, On Key Press, After Delay, Mouse Enter/Leave; Animation: Instant (kein Übergang), Dissolve (fade), Smart Animate (analysiert ähnliche Layer-Namen und animiert zwischen Positionen/Größen/Farben), Slide In/Out (Richtung wählbar), Push (Screen schiebt neuen rein); Easing-Funktionen: Ease In/Out/In-Out für natürlichere Bewegung; Overlay-Pattern: für Modals, Dropdowns, Tooltips; erscheint über aktuellem Frame; Scroll-Prototype: Frame mit definierter Scroll-Höhe für lange Seiten; Horizontal Scroll für Karusselle; Prototype-Viewer: Share-Link für Testpersonen; Figma-Mirror-App für Mobile-Device-Preview; presentation.figma.com für Stakeholder; Component-Properties für Multi-State-Prototypen: Boolean-Properties für Hover/Focus-States; Variants für verschiedene Button-Zustände (Default/Hover/Active/Disabled); Interactive Components (Figma 2021): Komponenten die intern Interaktionen haben ohne externe Connections
- Weitere Prototyping-Tools nach Anwendungsfall: Axure RP (Axure Software Solutions; San Diego; CA; erste Version 2002): professionelles Prototyping-Tool für komplexe Logik; Conditional Logic (wenn X dann Y); Variablen und Daten-Binding; Repeater für Listen mit echten Daten; ideal für komplexe Enterprise-Anwendungen; steile Lernkurve; kein kollaboratives Editing; Framer (Koen Bok/Jorn van Dijk; Amsterdam; Niederlande; gegründet 2014; Web-basiert seit 2022): React-basiertes Prototyping; echtes Code-Prototyping mit Design-Interface; Spring-Physics-Animationen; ideal wenn Entwickler und Designer zusammenarbeiten und der Prototyp in Produktionscode überführt werden soll; Marvel App (London; England; 2013): einfaches Prototyping für schnelle Tests; Sketch-Import; Maze-Integration für unmoderierte Tests; InVision (Clark Valberg/Ben Nadel; New York; 2011–2024; Cloud eingestellt Dezember 2024): war Standard für Sketch-Mockup-zu-Prototyp-Workflow; durch Figma weitgehend obsolet; Principle (Mac-App; Mountain View; CA; 2015): spezialisiert für Animations-Prototypen; Timeline-basiert; Motion-Design-Tools: ProtoPie (Seoul; Südkorea; 2016): fortgeschrittene Interaktionen; Sensor-Input (Gyroscope, Accelerometer); Multi-Device-Linking für IoT-Prototypen; Lottie-Integration; für komplexe Micro-Interactions-Prototypen
- Wizard-of-Oz-Prototyp und spezielle Prototyp-Formen: Wizard-of-Oz-Prototyp: Test-Teilnehmer interagiert mit Interface das scheinbar funktioniert; im Hintergrund steuert ein Moderator (der «Wizard behind the curtain») manuell die System-Reaktionen; Ursprung: Jeff Kelley (Johns Hopkins University; Baltimore; MD; 1980 CHI-Konferenz); anwendbar für KI-Systeme (Voice Interface, Chatbot: Moderator antwortet manuell auf Sprachinput); ermöglicht Test von Interaktionen die technisch noch nicht realisierbar oder zu aufwendig zu implementieren sind; Diary-Study-Prototyp: Prototyp wird über mehrere Tage mit Tagebuch-Methode getestet; Nutzer notieren Erlebnisse im Alltag; Concierge-Prototype (Lean-Startup-Methode; Eric Ries; San Francisco; CA; «The Lean Startup», Crown Business, 2011): Service oder Feature wird manuell von Menschen erbracht (statt automatisiert) um das Konzept zu validieren bevor Technologie gebaut wird; Coded Prototype (Entwicklungs-Prototyp): in HTML/CSS/JavaScript, React, Swift oder Kotlin implementiert; höchste Fidelity; testet echte Performance und Accessibility; sinnvoll kurz vor Launch oder wenn Figma-Prototyp Interactions nicht korrekt simulieren kann; Throwaway-Code: Prototype-Code ist nicht für Produktion; Pitfall: «Prototype Hell» wenn zu viele Iterationen ohne Test; Empfehlung: nach 2–3 Iterations testen statt perfektionieren
Prototyp-Testing, Feedback-Integration und Design-Sprint
- Prototyp-Test-Vorbereitung und Hypothesen: Test-Hypothesen vorab formulieren: «Wir glauben dass Nutzer [Aufgabe] in weniger als [Zeit] mit weniger als [Fehler] abschließen können»; nach dem Test messbar bestätigt oder widerlegt; Test-Aufgaben-Design: realistische Szenarien statt Feature-Demonstrationen; «Stellen Sie sich vor Sie möchten X – bitte versuchen Sie das mit dieser App»; kein Hinweis auf welchen Button zu klicken; Think-Aloud-Protokoll (Klaus Kjeldskov; Universität Aalborg; Dänemark): Tester denkt laut während der Interaktion; Moderator notiert Aussagen und Verhalten; 5 Nutzer pro Segment als Mindestgröße (Nielsen-Regel); Testumgebung: Bildschirm-Aufzeichnung (Maze/Lookback/UserTesting); Audio-Aufzeichnung; optional: Kamera auf Gesicht für emotionale Reaktionen; Remote-Moderated vs. Unmoderated: Remote-Moderated (Zoom + Screenshare): Moderator kann nachhaken; unmoderated (Maze): skalierbar; ohne Moderator-Bias; aber weniger Tiefe; Pilot-Test: Prototyp immer zuerst intern mit einer Person testen bevor echte Nutzer; prüft technische Funktionsfähigkeit und Task-Formulierung
- Feedback-Integration und Prototyp-Iteration: Affinity Mapping nach Test (KJ-Methode): jede Beobachtung/Aussage auf Karte; Cluster bilden; Muster identifizieren; Prioritäts-Matrix für gefundene Probleme: Schweregrad (Critical/Major/Minor) × Häufigkeit (% der Testpersonen die Problem hatten); Critical+Häufig: sofort beheben; Minor+Selten: Backlog; Design-Debt-Tracking: Probleme die nicht sofort behoben werden in Backlog mit Test-Kontext; verhindert vergessen von validierten Problemen; Prototyp-Iterations-Schnelligkeit: Figma-Prototypen können nach Test innerhalb von Stunden überarbeitet werden; nächste Test-Runde 48–72 Stunden nach Auswertung; nicht unendlich iterieren ohne Test; «Prototyp, Test, Überarbeiten»-Zyklus: Ziel ist nicht perfekter Prototyp sondern validierte Design-Entscheidungen; Design-Sprint-Prototyp (Jake Knapp): Donnerstag: 6–8 Stunden intensives Prototyping im Team; Ziel: «Fassade» nicht vollständiges Produkt; Freitag: 5 Nutzer-Tests je 45–60 Minuten; Entscheidung am Ende des Sprints: weitermachen, pivoten oder verwerfen