Wireframes: what they are, what to leave out, and where AI fits

The word comes from other fields that use a skeletal frame to show the shape of something three-dimensional. On the web, a wireframe is the skeleton of a page: where the content, the controls and the navigation sit, and how they work together.

What to leave out

Leave decorative detail out while deciding what information belongs on the page and how people will use it. Leaving them out keeps the conversation on structure; the moment a wireframe gets a brand colour, people start discussing the colour.

Low and high fidelity

• Low fidelity: boxes and labels, sketched or drawn quickly. Good for trying several layouts in an hour.
• High fidelity: real content and close-to-final layout, still without the visual design. Good for testing with users and handing to developers.

Where AI fits

AI tools can produce a first draft quickly, but plausibility alone does not establish that its structure suits the task. Relume generates a sitemap and wireframes from a description of the site; Uizard turns prompts and sketches into mockups; see the AI UI tools comparison. Treat the output as a draft to argue with, not a decision, and put the strongest version in front of real users in a usability test.

Wireframe, mockup, prototype and wireflow

These deliverables overlap, so name what yours demonstrates. A wireframe usually concentrates on information order, page structure and controls. A visual mockup shows more of the intended appearance, including typography, colour and imagery. A prototype lets someone experience a proposed interaction, either through working controls or a facilitator presenting the next state.

A wireflow joins page-level structure to the steps in a task. Nielsen Norman Group's wireflow explanation describes the combination of wireframes and a simplified flowchart. It is particularly useful when the same screen changes after an action: choosing a filter, opening a detail panel or submitting a form.

For an invented booking flow, three attractive screens labelled “search”, “results” and “confirmation” leave several questions unanswered. What happens when the search has no availability? Which result has been selected? Does confirmation mean a request was sent or a booking is guaranteed? A wireflow can connect those states to the controls that trigger them.

None of these deliverables proves that the final software behaves correctly. A clickable prototype can simulate a payment without processing one. A detailed mockup can show a table without specifying how its data is sorted. State the limits when sharing the work so an appearance does not become an accidental promise.

Start with a task and actual content

Before drawing boxes, write one sentence about what the person needs to accomplish. “Compare two delivery options and choose one before paying” is more useful than “design a checkout screen”. It identifies a decision, the information needed to make it and where it sits in the journey.

List the content that supports that decision: delivery dates, prices, eligibility limits, the selected address and any collection instructions. Identify what is required now and what can wait. A long company story may matter elsewhere, but it should not obscure the choice the page exists to support.

Use representative content early. Placeholder text that is half the length of the real explanation hides a space problem. A single short product name hides the wrapping caused by a long name. Include one ordinary case and at least one demanding case, such as a long address, a missing image or a delivery option with an eligibility condition.

Write the important control labels too. “Continue” may be acceptable in one step, while “Place order and pay $68” communicates a different commitment. Use a fictional amount when testing a hypothetical purchase, and label the project as a prototype so nobody mistakes it for an actual offer.

Worked example: a delivery-choice wireframe

This example is invented to show the reasoning, not copied from a customer project. A small online shop needs a delivery step for someone who has already selected an item and entered an address.

The first wireframe places a short heading at the top, the selected address below it, then a group of delivery options. Each option shows a name, an expected date and a charge. The order summary follows, including the item subtotal and selected delivery charge. The final control describes the next step, which in this example is reviewing payment rather than placing the order.

A first review finds an ambiguity: the date appears beside the group heading, so it could apply to every option. Move the date inside each option. Another question concerns the address. If it is wrong, the person needs a clear “Change address” action that preserves the basket rather than sending them back to the beginning.

The next version includes three states: no option selected, an option selected and an option no longer available. In the selected state, both the control and the order summary identify the choice. In the unavailable state, explain what changed and offer the remaining options. Do not silently substitute a more expensive service.

Add a note for the developer: delivery availability comes from the actual delivery calculation, and a failed calculation needs a distinct error message. The sketch cannot decide the integration contract, but it can expose the question before a polished page hides it.

A compact handoff table

A wireframe becomes easier to build when it includes a few behavioural notes. For the fictional delivery step, a companion table might look like this:

Element	Content or behaviour	Question to resolve
Address summary	Saved address with a change action	What is preserved after editing?
Delivery choices	One selectable option, price and date per row	How is availability refreshed?
Order summary	Recalculates after selection	How is a changed price announced?
Continue control	Moves to payment review	Is a selection required first?
Calculation error	Explains the failure and offers retry	Can the basket remain available?

These are requirements to discuss, not evidence that a system already implements them. Assign an owner to each unresolved question and update the notes when the team decides. Otherwise, the developer may interpret an empty area as permission to invent a rule that the designer thought was already agreed.

Choose fidelity by the decision

Use a rough wireframe when you are comparing content order, navigation or the steps in a journey. It is easier to move a large section before detailed styling and component behaviour depend on it. A rough version also makes it clear that the design is still being discussed.

Increase fidelity when the question requires it. Testing whether a person understands a subtle status indicator may need realistic wording, positioning and appearance. Testing a dense comparison table may need actual row lengths and a realistic viewport. A paper box labelled “table” cannot reveal whether the finished table will be readable.

Interaction and visual detail are separate choices. A plain clickable prototype can test a route through several steps. A polished static screen can test an initial interpretation but cannot demonstrate what happens after a click. NN/G's prototype guidance discusses the tradeoffs rather than treating high fidelity as an automatic improvement.

Avoid spending a week polishing a screen while its main task remains unresolved. Equally, do not insist on grey boxes when the research question depends on a colour-coded warning or the legibility of a real chart. The appropriate fidelity is the minimum that can answer the question credibly.

Show states beyond the happy path

A page normally needs more than one state. Consider the first visit, an empty account, data loading, a completed result, no matching result, a failed request and a person returning to unfinished work. Not every project needs every state, but every applicable state needs an intentional response.

For a search page, an empty query and a search with no matches are different situations. The first needs a useful starting point; the second needs a way to adjust the query without losing what the person entered. A generic blank area does not communicate either one.

For a form, show where errors appear, how the relevant field is identified and what remains after submission fails. An error that clears every answer creates a different experience from one that preserves valid answers and explains the correction. Write a plausible error message rather than the placeholder “error here”.

For destructive actions, define the consequence and the opportunity to recover. Deleting an account, removing one saved item and cancelling an unpaid draft are different operations. A single generic confirmation dialog may conceal these differences. The wireframe should make the intended action and affected item identifiable.

Phone layouts need their own decisions

A desktop wireframe squeezed into a narrow column can change the order in which information is encountered. A summary that sits beside a form may move below it, out of view when someone makes the decision. Decide which facts must remain beside the relevant control and which can move later.

Sketch the phone version with the longest realistic labels. Check whether the primary action is still identifiable after a label wraps, whether a row of options becomes a meaningful vertical list and whether a sticky control obscures an error message or the last line of content.

For a wide data table, consider the task before choosing a pattern. A person comparing all columns may need a scrollable table with clear headers. Someone reading one record at a time may benefit from a different presentation. Converting every row to a card can make cross-record comparison harder, so verify the decision with the actual content.

Show navigation at the narrow width too. A menu icon on a sketch is only a placeholder until its contents and open state are defined. Record the items, how to close the menu and where focus should move when it opens. This gives implementation and accessibility review something concrete to assess.

Accessibility questions to ask early

Wireframes cannot establish final contrast because colours may not exist yet. They can still reveal missing labels, ambiguous control names, an illogical reading order and instructions that depend only on a visual position such as “use the box on the right”.

Annotate the intended heading hierarchy and name form controls in the content. A visible label is usually easier to review than an unlabeled rectangle with an accessibility note attached. If a custom control is proposed, ask what a keyboard user does and what information a screen reader needs to announce.

Specify changes that need feedback. When selecting a delivery option changes a total, the visual design and implementation need a way to communicate the updated amount. A note such as “total updates after selection” raises the requirement; actual browser and assistive-technology testing later establishes whether the implementation meets it.

Use the colour contrast checker when real colour pairs are available. A passing ratio for one pair does not prove that the entire design is accessible. It also says nothing about whether the task sequence, error recovery or control labels are understandable.

Reviewing wireframes with a team

Share the purpose of the review before the screens. For example: “We need to decide whether delivery should be chosen before payment, and which information people need at that moment.” This helps reviewers assess the unresolved decision instead of debating an incidental shade of grey.

Walk through a concrete task from the starting point. Ask what the person knows at each step, what they must decide and how they can recover from an incorrect choice. Record contradictions between screens, such as one step promising an immediate booking while the next describes an unconfirmed request.

Keep a visible list of decisions and open questions. “Approved” is too vague if one reviewer approved the sequence and another assumed the labels were final. Record that the delivery-first sequence is agreed while pricing integration and error wording remain open, with named owners for those questions.

After revising, check the connected screens. Moving an address editor may affect a back link, the order summary and a confirmation message. A wireframe file with individually tidy screens can still describe an impossible journey if the transitions do not agree.

Testing a wireframe with users

A wireframe can support a useful usability session when it contains enough detail for the chosen task. Give the participant a realistic goal without naming the button you want them to press. Observe the first action, questions, misunderstandings and whether they can explain the outcome.

If the prototype is static, explain that some transitions will be simulated. When someone chooses an unsupported action, record it rather than pretending they chose incorrectly. Their choice may reveal missing information or an expected route that the design does not yet include.

Distinguish observation from interpretation. “The participant selected collection because they thought delivery cost extra on every plan” is stronger evidence than “the layout is confusing” when you can preserve the actual words and context. Avoid turning a small study into a percentage claim about all customers.

Use the findings to revise the relevant state or label, then test the changed path. The user-testing guide explains how to frame tasks and keep findings proportionate. Neither a stakeholder walkthrough nor an AI critique replaces evidence from suitable people trying the intended task.

Where AI-generated wireframes help

A generated draft can make a blank page easier to discuss. Give the tool the task, required content, important states, intended device and constraints. Ask it to preserve those requirements when it suggests a different arrangement. A visually tidy draft that omits a required step is incomplete.

For the fictional delivery flow, a useful prompt would request a phone-first delivery selector with an editable address, three delivery states, a price summary and a clear transition to payment review. Supply representative labels and mark invented prices as placeholders. Do not upload private customer details merely to make the draft look realistic.

Inspect what the tool actually produces. Some products generate static mockups; others generate editable components, code or hosted pages. Check how revisions are made, what can be exported, whether the output contains working interactions and which subscription is required. The AI UI design tools comparison separates these output types and links to current vendor information.

An AI system may invent a field, omit an empty state or present a confident explanation for a choice that has not been tested. Compare the draft with the original brief line by line. Keep useful suggestions, remove unsupported content and record unresolved decisions for a person to review.

From wireframe to a working interface

When the structure is agreed, connect it to the actual design system: components, spacing, type, states and content rules. Identify any element that needs a new component rather than quietly drawing an exception that the implementation cannot support.

Retain behavioural notes during visual design. The exact colours may change, but the requirement to preserve form answers after an error still matters. Update the prototype when a technical constraint changes a transition, and check the effect on the rest of the task.

Before release, verify the implementation in a real browser at the supported widths. Follow links, use the keyboard, enter valid and invalid values and inspect the final result. A rendered screenshot can show a missing section; it cannot prove that the form saves correctly or that a confirmation reflects the server's state.

The handoff is complete when the team can explain the task, implement the states, identify remaining questions and test the intended behaviour. Ideal User Interfaces' proposed AI reviewer remains in design; this guide is a practical method for people preparing and reviewing wireframes today.

Sources

1. Nielsen Norman Group, wireflows, checked 16 October 2026
2. Nielsen Norman Group, prototype fidelity, checked 16 October 2026
3. Relume pricing, read 3 October 2026

Verified against these sources on 16 October 2026. Notice an error? Read the about page.