Wireframe

Transferred to websites and apps, this means: a wireframe shows what a screen does and where things are, not what it will look like in the end.

Wireframes are the working tool with which product teams, business departments and development talk about the same thing early on. A line on paper or a grey rectangle in a design tool can be moved in seconds. The same change costs many times more after implementation in code. This entry explains the fidelity levels, distinguishes wireframe, mock-up and prototype from each other, describes what belongs in a good wireframe and names the common tools.

What a wireframe shows and what it does not

English Wikipedia describes the website wireframe as a visual guide to the skeletal framework of a page: the arrangement of content, interface elements and navigation and how they work together. The focus is on function. A wireframe answers questions such as: what information does the person need on this screen? In what order? Which action is the most important, which secondary?

What is usually deliberately left out:

• Brand colours and imagery: colour quickly steers the discussion towards matters of taste. Greyscale keeps the focus on hierarchy and flow.
• Final typography: font sizes are at most indicated relatively (heading, body text, note), not defined to the pixel.
• Real interaction: a classic wireframe is static. Transitions, animations and hover states can only be described in it, not experienced.

This reduction is precisely the point. Anyone already discussing the right shade of green in the wireframe has usually not yet answered the question of the right content.

Low, mid and high fidelity: the levels of detail

"Fidelity" describes how close a draft is to the finished product. In its article UX Prototypes: Low Fidelity vs. High Fidelity, the Nielsen Norman Group distinguishes three dimensions: interactivity, visual refinement and content. A draft can be well developed in one dimension and remain rough in another. For wireframes, a three-way division has become established.

Low-fidelity wireframe

Sketches on paper, on the whiteboard or with simple boxes in a tool. Images are crossed-out rectangles, texts often just lines. A low-fidelity wireframe is created in minutes, invites you to discard it and is suitable for the early phase in which several variants compete against each other. Because it is visibly unfinished, those involved are more willing to voice fundamental criticism. Anyone searching for "low-fidelity prototype" usually means exactly this level, supplemented by simple links between the sketches.

Mid-fidelity wireframe

Digital, neatly aligned greyscale drafts with realistic proportions, a grid and the first real texts. Components such as buttons, input fields and lists are recognisable but not yet styled. In many projects, this level is the working basis for coordination with the business department and development, because it is precise enough for effort estimates and can still be changed quickly.

High-fidelity wireframe

Close to the final layout: real content, defined spacing, specific image formats, sometimes already the typography of the design system. The boundary with the mock-up is fluid. This level makes sense when content is very dense, for example with form sequences, tables in specialist applications or product detail pages with many variants, and the layout can only be assessed with real data.

Wireframe, mock-up, prototype and click dummy compared

The terms are often mixed up in everyday use. For quotes, requirements specifications and acceptance, a clear separation is worthwhile, because each artefact involves a different effort and a different goal.

A click dummy is thus a special form of prototype: screens are connected via hotspots, and no data is processed. Linked wireframes thus become a low-fidelity prototype, linked mock-ups a high-fidelity prototype. How these levels build on each other in an app project is shown in the article app design process: from wireframe to clickable prototype.

What belongs in a good wireframe

A wireframe is only as good as the questions it answers. Alongside layout and navigation, two points above all decide whether the later implementation runs without surprises: complete states and realistic content.

States instead of just the ideal case

Many drafts only show the "happy path": the list with exactly eight entries, the form after successful input. In reality, every screen has several states. For each relevant screen, you should play through at least these:

• Empty state: what does someone see on first launch, before any data exists? A good empty state explains the next step.
• Loading state: placeholders, skeleton screens or a progress indicator, so that the interface does not seem frozen.
• Error state: validation errors in the form, a failed server response, an expired session. Where does the message appear, and how does it continue?
• Offline state: crucial for mobile apps in particular. What is available without a network, what is cached, how is synchronisation shown?
• Edge cases: very long names, a hundred instead of eight entries, missing images, permissions that hide an action.

Every state missing from the wireframe will be decided later in development, often under time pressure and without consultation with the business side.

Real content instead of lorem ipsum

Dummy text is convenient but distorts the result. A heading with 20 characters behaves differently from one with 80, a product name from the ERP differently from an invented name. Where possible, real or realistically long content belongs in the wireframe: actual menu items, real error messages, real records in anonymised form. Only then does it become clear whether hierarchy and space really work.

Accessibility also starts here. Reading order, heading structure and sufficiently large touch targets can be defined in the wireframe. In success criterion 2.5.8 at level AA, for example, WCAG 2.2 requires a target size of at least 24 × 24 CSS pixels for controls, with defined exceptions (W3C specification).

Its position in the project

Wireframes sit between clarifying requirements and visual design. A typical sequence in a software or app project looks like this:

1. Requirements and goals: user groups, tasks and business rules have been captured, for example in a requirements specification or in user stories.
2. Information architecture and user flows: which screens are there, and how are they connected?
3. Wireframes: first low fidelity for variants, then mid fidelity for coordination.
4. Testing with users: linked wireframes are checked in a usability test. The Nielsen Norman Group stresses that even rough prototypes can be tested and that a discarded draft is considerably cheaper than rebuilt code.
5. Visual design and prototype: mock-ups based on the design system, followed by the clickable prototype.
6. Implementation: development on the basis of agreed screens and states.

For a minimum viable product, the chain is often shortened: mid-fidelity wireframes plus a design system then replace elaborate individual mock-ups. Skipping the wireframe step completely, on the other hand, only shifts the structural questions into development.

Tools for wireframes

Wireframes do not require a special tool, but the choice influences how well the draft can be reused later.

• Paper and whiteboard: the fastest for the first variants and for workshops with business departments. A photo of the sketch is often enough as documentation.
• Balsamiq: Balsamiq Wireframes deliberately relies on a sketchy look. This signals to everyone involved that the focus is on structure, not appearance. Suitable for low and mid fidelity.
• Figma: the widespread standard for UI design in the browser. Wireframes, mock-ups and prototypes are created in the same file and can access a shared component set, which eases the transition between levels.
• Penpot: an open-source alternative under the Mozilla Public License 2.0, explicitly designed for self-hosting according to the project page on GitHub, for example via Docker or Kubernetes. Interesting for organisations that do not want to store drafts containing internal data with a US provider.
• Adobe XD: no longer a sensible choice for new projects. Adobe put XD into maintenance mode in 2023 and declared at the beginning of 2024 that it would not invest further in the product (report by The Register). Existing XD files should be migrated in the medium term.

Increasingly, design tools also generate wireframes from a text description using AI. This speeds up the first draft but does not replace the work on states, content and flows, because these are exactly the details the tool does not know.

Wireframes for websites and for apps

The basic idea is the same, but the focus differs.

Web wireframes have to cover several screen widths. At least one mobile and one desktop view are usual, often with an additional tablet breakpoint. What matters is how columns wrap, which navigation applies with a narrow viewport and which content moves down on mobile. Pages are often long and scrollable, and content hierarchy and entry points for search engines play a greater role.

App wireframes work with fixed device sizes, platform-typical patterns and gestures. A native app follows the conventions of iOS and Android, for example for tab bars, back navigation or system dialogs. In its Human Interface Guidelines, Apple recommends touch targets of at least 44 × 44 points, Google's Material Design 48 × 48 dp. In the article Wireflows, the Nielsen Norman Group describes how a hybrid of wireframe and flowchart has become established for apps: each step is a complete screen, and arrows mark the tappable elements.

In a progressive web app, both worlds meet: responsive layouts as on the web, plus app topics such as offline behaviour, installation on the home screen and push notifications.

Typical mistakes in wireframing

• Too polished too early: anyone who starts straight away in high fidelity gets feedback on colours instead of structure and becomes emotionally attached to drafts that should actually be discarded.
• Only the ideal case: missing empty, loading, error and offline states are the most common source of queries in development.
• Lorem ipsum everywhere: dummy text conceals space problems and unclear hierarchies.
• No reference to data and permissions: a screen that looks the same for admins and guests is rarely realistic. Permissions belong in the draft.
• Wireframe as the end product: an approved wireframe is not a design and not a specification of the business logic. It needs supplementary documentation on rules, validations and interfaces.
• No testing: a wireframe that has never been put in front of users only confirms the team's assumptions.

Frequently asked questions about wireframes

What is the difference between a wireframe and a mock-up?

A wireframe defines structure, content and navigation with a pared-down appearance. A mock-up shows the visual design with colours, typography and images. Both are static. The wireframe comes first, and the mock-up builds on the agreed structures.

How many wireframes does an app need?

There is no blanket number. As a rule of thumb, you need one wireframe for each independent screen and, for the important screens, additionally the relevant states such as empty, loading, error and offline. Smaller apps thus quickly reach a multiple of the pure number of screens.

Which free tool is suitable for wireframes?

Paper costs nothing and is often best for first variants. Digitally, Figma and Penpot offer free entry options. Penpot is open source and can also be self-hosted, which can be an argument for confidential projects.

Is a wireframe already a prototype?

A single wireframe is not, as it is static. If several wireframes are linked via clickable areas, a low-fidelity prototype is created with which flows can already be checked in a usability test.