| Typ | Konzept |
|---|---|
| Quellen | Quelle - Praxisbuch Usability und UX Quelle - Recherche - Usability und UX heute 2026 Quelle - Effektive Softwarearchitekturen |
| Erstellt | 2026-09-27 |
| Aktualisiert | 2026-09-27 |
| Tags | prototyping, scribble, wireframe, papierprototyp, mockup, fidelity |
Ideen schrittweise sichtbar und testbar machen, bevor programmiert wird: von der Handskizze (Scribble) über Wireframe und Papierprototyp bis zum Mockup und zum interaktiven High-Fidelity-Prototyp. Je früher im Projekt, desto grober und billiger.
Die Stufen im Überblick
| Stufe | Was | Werkzeug | Interaktiv? | Wofür |
|---|---|---|---|---|
| Scribble | handgezeichnete Skizze | Papier, Marker | nein | Ideen finden, Varianten |
| Wireframe | Seitenskizze mit Struktur, meist schwarzweiss | Axure, Balsamiq, OmniGraffle | kaum | Inhalt und Funktion ohne Designdiskussion |
| Papierprototyp | ausgeschnittene Papierscreens | Papier, Schere, Folie | ja, von Hand simuliert | frühe Nutzertests |
| Mockup | statischer Screen, sieht aus wie fertig | Photoshop, Sketch | nein | visuelles Design |
| Prototyp | Simulation der Anwendung | Axure, InVision, UXPin, HTML/CSS | ja | Tests, Freigabe |
Die Grenzen sind fliessend. Ein Klickdummy verbindet Wireframes oder Mockups zu klickbaren Abfolgen, etwa mit den Apps Marvel oder POP (Quelle - Praxisbuch Usability und UX, S. 140, 156).
Scribbles
- Englisch „Gekritzel“; jeder kann es. Zwei Vorteile: schnell, und jeder erkennt die Vorläufigkeit, also kommen Änderungsvorschläge leicht (S. 130).
- Bildplatzhalter als Kasten mit Kreuz, Text als parallele Linien, nur Überschriften ausschreiben.
- Grösse: zum Ideenfinden winzige Thumbnails (2 × 3 cm), zum Ausarbeiten etwa Bildschirmgrösse (Smartphone 5 × 9 cm, Website 20 × 15 cm). Mit hellen Farben beginnen, ein bis zwei Akzentfarben (S. 134–135).
- Jedes Scribble beschriften: Projekt, Titel/Nummer, Datum, Ersteller; Kommentare zu Funktionen. Einen Tag liegen lassen, dann überarbeiten.
- Im Team mit 4 bis 14 Personen: jeder für sich (viele Ideen) oder einer zeichnet, andere helfen (Detailarbeit) (S. 138–139).
Wireframes
- Englisch „Drahtgittermodell“. Mit Software, detaillierter als Scribbles, in Originalgrösse (S. 141).
- Hauptvorteil: Inhalte und Funktionen diskutieren, ohne über Farben und Schriften zu streiten (S. 142).
- Muss hinein: Logo, Header, Footer, Inhaltsbereich, Beispielelemente mit realistischer Blindtextmenge, geplante Werbebanner. Jedes Element braucht einen Grund für Grösse und Position. Dazu Anmerkungen (Callouts), Datum und Version (S. 147–148).
- Nicht hinein: echte Farben, Schriften, Fotos. Farbe höchstens für die Gewichtung. Low-, Medium- und High-Fidelity-Wireframes unterscheiden den Detailgrad.
- Manchmal hinein: Button-Zustände, Fehlermeldungen, Feldtypen, Gesten.
- Wie viele: je Seitentyp einer (Start, Übersicht, Trefferliste, Detail, Artikel, News); bei Apps je Screen einer. Responsiv oft in vier Breiten: 320, 768, 1024, 1200 px (S. 151).
- Mit echten Inhalten prüfen, sonst laufen Überschriften später über vier Zeilen. Den Spielraum für Grafik und Entwicklung klar sagen. Wireflows verbinden Wireframes mit Flussdiagrammen.
Papierprototypen
- Papiermodelle der Screens, die Interaktion von Hand simulieren: Haftnotizen für Dialoge, Transparentfolie für Eingaben, eine aufgeschlitzte Pappattrappe fürs Scrollen (S. 159–160).
- Mit der Smartphone-Variante beginnen; vorher mit Kollegen probeweise durchspielen.
- Test mit drei Rollen: Moderator, „menschlicher Computer“ (legt die passenden Papierteile hin, erklärt nichts) und Beobachter (S. 163–164).
- Nutzer kritisieren unfertig Aussehendes offener. Grenzen: kein Endlos-Scrollen, keine Kartenzoom-Interaktion.
Mockups und Prototypen
- Mockup (englisch „Attrappe“): statisch, täuschend echt, für Anmutung, Farben, Typografie (S. 165).
- Prototyp: interaktiv; spart Neuprogrammierung, wenn Nutzer ein Konzept nicht annehmen (S. 166).
- Fidelity (Ähnlichkeit zum Endprodukt) in drei Dimensionen: visuelle Gestaltung, Funktionsumfang, Inhalt (Lorem ipsum vs. echter Text). Low-Fi früh und kurzlebig, Medium-Fi zu Beginn der Designphase, High-Fi am Ende der Designphase und zur Freigabe (S. 167–169).
- Pareto-Prinzip: die 20 % Funktionen, die Nutzer 80 % der Zeit nutzen, gründlich statt vieles oberflächlich. Standardfunktionen wie ein Kontaktformular muss man nicht prototypen (S. 170).
- Rapid Prototyping: testen, noch am selben Tag anpassen, nächste Runde (S. 175).
- Bei Markenportalen genügen oft Mockups, bei Onlineshops unbedingt interaktive Prototypen testen.
Veraltet seit der Quelle
Die Werkzeuge sind Stand 2017. InVision hat seine Kollaborations- und Prototyping-Dienste am 31. Dezember 2024 eingestellt, vor allem wegen der Konkurrenz durch Figma, das heute der führende Standard für UI-Design ist; die Marktanteile schwanken je nach Erhebung stark (Quelle - Recherche - Usability und UX heute 2026).
Prototypen in der Softwarearchitektur
Auch Architekten nutzen Prototypen, nicht nur für Oberflächen (Quelle - Effektive Softwarearchitekturen):
- Ein funktionaler Prototyp kann eine unrealistische Anforderung widerlegen. Im Buchbeispiel zeigte er, dass schon die Mainframe-Zugriffe länger als die geforderte eine Sekunde brauchten (Softwarequalität, S. 95).
- Prototypen und Piloten sind eine Form von Trial and Error: ausprobieren, dann bewerten (S. 80, Entwurfsprinzip).
- Prototype Improvement ist eine Maxime von aim42: Eine Verbesserungsmassnahme zuerst im Kleinen ausprobieren und daraus lernen (S. 330).
Verwandt
- Nutzerzentrierte Entwicklung – Konzeptions- und Designphase
- Usability-Test – was man mit Prototypen macht
- Informationsarchitektur – Sitemap als Grundlage
- Produktentwicklung – Prototyp und Nullserie in der BWL
- Responsives Webdesign – Breakpoints und Raster
- aim42 – Verbesserungen erst im Kleinen erproben