Wireframe

Übertragen auf Websites und Apps heißt das: Ein Wireframe zeigt, was ein Screen tut und wo etwas steht, nicht wie es am Ende aussieht.

Wireframes sind das Arbeitsmittel, mit dem Produktteams, Fachabteilungen und Entwicklung früh über dieselbe Sache sprechen. Eine Linie auf Papier oder ein graues Rechteck in einem Design-Tool lässt sich in Sekunden verschieben. Dieselbe Änderung kostet nach der Umsetzung im Code ein Vielfaches. Dieser Eintrag erklärt die Fidelity-Stufen, grenzt Wireframe, Mockup und Prototyp voneinander ab, beschreibt, was in ein gutes Wireframe gehört, und nennt die gängigen Werkzeuge.

Was ein Wireframe zeigt und was nicht

Die englischsprachige Wikipedia beschreibt das Website Wireframe als visuellen Leitfaden für das Grundgerüst einer Seite: Anordnung von Inhalten, Interface-Elementen und Navigation sowie deren Zusammenspiel. Im Mittelpunkt steht die Funktion. Ein Wireframe beantwortet Fragen wie: Welche Informationen braucht die Person auf diesem Screen? In welcher Reihenfolge? Welche Aktion ist die wichtigste, welche nachrangig?

Bewusst weggelassen werden in der Regel:

• Markenfarben und Bildwelt: Farbe lenkt die Diskussion schnell auf Geschmacksfragen. Graustufen halten den Fokus auf Hierarchie und Ablauf.
• Finale Typografie: Schriftgrößen werden höchstens relativ angedeutet (Überschrift, Fließtext, Hinweis), nicht pixelgenau festgelegt.
• Echte Interaktion: Ein klassisches Wireframe ist statisch. Übergänge, Animationen und Hover-Zustände lassen sich darin nur beschreiben, nicht erleben.

Genau diese Reduktion ist der Zweck. Wer im Wireframe schon über den richtigen Grünton diskutiert, hat die Frage nach dem richtigen Inhalt meist noch nicht beantwortet.

Low-, Mid- und High-Fidelity: die Detailstufen

„Fidelity" beschreibt, wie nah ein Entwurf am fertigen Produkt ist. Die Nielsen Norman Group unterscheidet in ihrem Artikel UX Prototypes: Low Fidelity vs. High Fidelity drei Dimensionen: Interaktivität, visuelle Ausarbeitung und Inhalt. Ein Entwurf kann in einer Dimension weit ausgearbeitet sein und in einer anderen grob bleiben. Für Wireframes hat sich eine Dreiteilung eingebürgert.

Low-Fidelity-Wireframe

Skizzen auf Papier, am Whiteboard oder mit einfachen Kästen im Tool. Bilder sind durchgestrichene Rechtecke, Texte oft nur Linien. Ein Low-Fidelity-Wireframe entsteht in Minuten, lädt zum Verwerfen ein und eignet sich für die frühe Phase, in der mehrere Varianten gegeneinander antreten. Weil er sichtbar unfertig ist, trauen sich Beteiligte eher, grundsätzliche Kritik zu äußern. Wer nach „Low-Fidelity-Prototyp" sucht, meint meist genau diese Stufe, ergänzt um einfache Verknüpfungen zwischen den Skizzen.

Mid-Fidelity-Wireframe

Digitale, sauber ausgerichtete Graustufen-Entwürfe mit realistischen Proportionen, einem Raster und ersten echten Texten. Komponenten wie Buttons, Eingabefelder und Listen sind erkennbar, aber noch nicht gestaltet. Diese Stufe ist in vielen Projekten die Arbeitsgrundlage für Abstimmungen mit Fachabteilung und Entwicklung, weil sie präzise genug für Aufwandsschätzungen ist und trotzdem schnell geändert werden kann.

High-Fidelity-Wireframe

Nahe am finalen Layout: echte Inhalte, definierte Abstände, konkrete Bildformate, teilweise schon die Typografie des Design-Systems. Die Grenze zum Mockup ist fließend. Sinnvoll ist diese Stufe, wenn Inhalte sehr dicht sind, etwa bei Formularstrecken, Tabellen in Fachanwendungen oder Produktdetailseiten mit vielen Varianten, und das Layout erst mit realen Daten beurteilbar wird.

Wireframe, Mockup, Prototyp und Klickdummy im Vergleich

Die Begriffe werden im Alltag oft vermischt. Für Angebote, Lastenhefte und Abnahmen lohnt sich eine klare Trennung, weil hinter jedem Artefakt ein anderer Aufwand und ein anderes Ziel steht.

Ein Klickdummy ist damit eine spezielle Form des Prototyps: Screens sind über Hotspots verbunden, Daten werden nicht verarbeitet. Aus verknüpften Wireframes entsteht so ein Low-Fidelity-Prototyp, aus verknüpften Mockups ein High-Fidelity-Prototyp. Wie diese Stufen in einem App-Projekt aufeinander aufbauen, zeigt der Beitrag App-Design-Prozess: Vom Wireframe zum klickbaren Prototyp.

Was in ein gutes Wireframe gehört

Ein Wireframe ist nur so gut wie die Fragen, die es beantwortet. Neben Layout und Navigation entscheiden vor allem zwei Punkte darüber, ob die spätere Umsetzung ohne Überraschungen verläuft: vollständige Zustände und realistische Inhalte.

Zustände statt nur des Idealfalls

Viele Entwürfe zeigen ausschließlich den „Happy Path": die Liste mit genau acht Einträgen, das Formular nach erfolgreicher Eingabe. In der Realität sieht jeder Screen mehrere Zustände. Für jeden relevanten Screen solltest Du mindestens diese durchspielen:

• Leerzustand: Was sieht jemand beim ersten Start, bevor Daten vorhanden sind? Ein guter Leerzustand erklärt den nächsten Schritt.
• Ladezustand: Platzhalter, Skeleton-Screens oder Fortschrittsanzeige, damit die Oberfläche nicht eingefroren wirkt.
• Fehlerzustand: Validierungsfehler im Formular, fehlgeschlagene Serverantwort, abgelaufene Sitzung. Wo steht die Meldung, und wie geht es weiter?
• Offline-Zustand: Gerade bei mobilen Apps entscheidend. Was ist ohne Netz verfügbar, was wird zwischengespeichert, wie wird die Synchronisierung angezeigt?
• Grenzfälle: sehr lange Namen, hundert statt acht Einträge, fehlende Bilder, Berechtigungen, die eine Aktion ausblenden.

Jeder Zustand, der im Wireframe fehlt, wird später in der Entwicklung entschieden, oft unter Zeitdruck und ohne Abstimmung mit der Fachseite.

Echte Inhalte statt Lorem ipsum

Blindtext ist bequem, verfälscht aber das Ergebnis. Eine Überschrift mit 20 Zeichen verhält sich anders als eine mit 80, eine Produktbezeichnung aus dem ERP anders als ein Fantasiename. Wo möglich, gehören echte oder realistisch lange Inhalte ins Wireframe: tatsächliche Menüpunkte, echte Fehlermeldungen, reale Datensätze in anonymisierter Form. Erst dann zeigt sich, ob Hierarchie und Platz tatsächlich funktionieren.

Auch Barrierefreiheit beginnt hier. Lesereihenfolge, Überschriftenstruktur und ausreichend große Bedienflächen lassen sich im Wireframe festlegen. Die WCAG 2.2 verlangen etwa im Erfolgskriterium 2.5.8 auf Stufe AA eine Zielgröße von mindestens 24 × 24 CSS-Pixeln für Bedienelemente, mit definierten Ausnahmen (W3C-Spezifikation).

Die Position im Projektablauf

Wireframes stehen zwischen Anforderungsklärung und visuellem Design. Ein typischer Ablauf in einem Software- oder App-Projekt sieht so aus:

1. Anforderungen und Ziele: Nutzergruppen, Aufgaben und fachliche Regeln sind erfasst, etwa in einem Lastenheft oder in User Stories.
2. Informationsarchitektur und User Flows: Welche Screens gibt es, wie hängen sie zusammen?
3. Wireframes: Erst Low-Fidelity für Varianten, dann Mid-Fidelity für die Abstimmung.
4. Test mit Nutzenden: Verknüpfte Wireframes werden in einem Usability-Test geprüft. Die Nielsen Norman Group betont, dass sich auch grobe Prototypen testen lassen und ein verworfener Entwurf deutlich günstiger ist als umgebauter Code.
5. Visuelles Design und Prototyp: Mockups auf Basis des Design-Systems, anschließend der klickbare Prototyp.
6. Umsetzung: Entwicklung auf Grundlage abgestimmter Screens und Zustände.

Für ein Minimum Viable Product verkürzt sich die Kette oft: Mid-Fidelity-Wireframes plus Design-System ersetzen dann aufwendige Einzel-Mockups. Den Wireframe-Schritt ganz zu überspringen, verlagert die Strukturfragen dagegen nur in die Entwicklung.

Werkzeuge für Wireframes

Für Wireframes braucht es kein spezielles Werkzeug, aber die Wahl beeinflusst, wie gut sich der Entwurf später weiterverwenden lässt.

• Papier und Whiteboard: Am schnellsten für die ersten Varianten und für Workshops mit Fachabteilungen. Ein Foto der Skizze reicht oft als Dokumentation.
• Balsamiq: Balsamiq Wireframes setzt bewusst auf einen skizzenhaften Look. Das signalisiert allen Beteiligten, dass es um Struktur geht, nicht um Optik. Für Low- und Mid-Fidelity geeignet.
• Figma: Der verbreitete Standard für UI-Design im Browser. Wireframes, Mockups und Prototypen entstehen in derselben Datei und können auf ein gemeinsames Komponenten-Set zugreifen, was den Übergang zwischen den Stufen erleichtert.
• Penpot: Open-Source-Alternative unter der Mozilla Public License 2.0, laut Projektseite auf GitHub ausdrücklich für Self-Hosting ausgelegt, etwa per Docker oder Kubernetes. Interessant für Organisationen, die Entwürfe mit internen Daten nicht bei einem US-Anbieter speichern wollen.
• Adobe XD: Für neue Projekte keine sinnvolle Wahl mehr. Adobe hat XD 2023 in den Wartungsmodus versetzt und Anfang 2024 erklärt, nicht weiter in das Produkt zu investieren (Bericht von The Register). Bestehende XD-Dateien sollten mittelfristig migriert werden.

Zunehmend erzeugen Design-Tools Wireframes auch per KI aus einer Textbeschreibung. Das beschleunigt den ersten Entwurf, ersetzt aber nicht die Arbeit an Zuständen, Inhalten und Abläufen, denn genau diese Details kennt das Werkzeug nicht.

Wireframes für Websites und für Apps

Die Grundidee ist gleich, die Schwerpunkte unterscheiden sich.

Web-Wireframes müssen mehrere Bildschirmbreiten abdecken. Üblich sind mindestens eine mobile und eine Desktop-Ansicht, oft zusätzlich ein Tablet-Breakpoint. Wichtig ist, wie sich Spalten umbrechen, welche Navigation bei schmalem Viewport greift und welche Inhalte mobil nach unten rutschen. Seiten sind häufig lang und scrollbar, Inhaltshierarchie und Einstiegspunkte für Suchmaschinen spielen eine größere Rolle.

App-Wireframes arbeiten mit festen Gerätegrößen, plattformtypischen Mustern und Gesten. Eine native App folgt den Konventionen von iOS und Android, etwa bei Tab-Leisten, Zurück-Navigation oder System-Dialogen. Apple empfiehlt in seinen Human Interface Guidelines Bedienflächen von mindestens 44 × 44 Punkt, Googles Material Design 48 × 48 dp. Die Nielsen Norman Group beschreibt im Artikel Wireflows, dass sich für Apps eine Mischform aus Wireframe und Flussdiagramm etabliert hat: Jeder Schritt ist ein vollständiger Screen, Pfeile markieren die antippbaren Elemente.

Bei einer Progressive Web App treffen beide Welten aufeinander: responsive Layouts wie im Web, dazu App-Themen wie Offline-Verhalten, Installation auf dem Homescreen und Push-Hinweise.

Typische Fehler beim Wireframing

• Zu früh zu schön: Wer gleich in High-Fidelity einsteigt, bekommt Feedback zu Farben statt zur Struktur und hängt emotional an Entwürfen, die eigentlich verworfen werden müssten.
• Nur der Idealfall: Fehlende Leer-, Lade-, Fehler- und Offline-Zustände sind die häufigste Quelle für Nachfragen in der Entwicklung.
• Lorem ipsum überall: Blindtext verschleiert Platzprobleme und unklare Hierarchien.
• Kein Bezug zu Daten und Rechten: Ein Screen, der für Admins und Gäste gleich aussieht, ist selten realistisch. Berechtigungen gehören in den Entwurf.
• Wireframe als Endprodukt: Ein abgenommenes Wireframe ist kein Design und keine Spezifikation der Geschäftslogik. Es braucht ergänzende Dokumentation zu Regeln, Validierungen und Schnittstellen.
• Kein Test: Ein Wireframe, das nie vor Nutzenden lag, bestätigt nur die Annahmen des Teams.

Häufige Fragen zu Wireframes

Was ist der Unterschied zwischen Wireframe und Mockup?

Ein Wireframe legt Struktur, Inhalte und Navigation in reduzierter Optik fest. Ein Mockup zeigt das visuelle Design mit Farben, Typografie und Bildern. Beide sind statisch. Das Wireframe kommt zuerst, das Mockup baut auf den abgestimmten Strukturen auf.

Wie viele Wireframes braucht eine App?

Eine pauschale Zahl gibt es nicht. Als Faustregel brauchst Du für jeden eigenständigen Screen ein Wireframe und für die wichtigen Screens zusätzlich die relevanten Zustände wie leer, ladend, fehlerhaft und offline. Kleinere Apps kommen so schnell auf ein Vielfaches der reinen Screen-Anzahl.

Welches kostenlose Tool eignet sich für Wireframes?

Papier kostet nichts und ist für erste Varianten oft am besten. Digital bieten Figma und Penpot kostenlose Einstiegsmöglichkeiten. Penpot ist Open Source und lässt sich zusätzlich selbst betreiben, was bei vertraulichen Projekten ein Argument sein kann.

Ist ein Wireframe schon ein Prototyp?

Ein einzelnes Wireframe nicht, da es statisch ist. Werden mehrere Wireframes über Klickflächen verknüpft, entsteht ein Low-Fidelity-Prototyp, mit dem sich Abläufe bereits in einem Usability-Test prüfen lassen.