Wireframes

A wireframe layout is a simple, quick plan of the pages or screens in a media product. It shows where each component will go and how the pages or screens are connected by links or actions. Think of it as a map of the structure and navigation rather than a finished design: the layout is shown roughly so it is easy to discuss and change.

Why it is made before production

Building real screens for a website or app takes a lot of time and money. If the navigation is wrong or a button is in the wrong place, fixing it after production is costly. A wireframe lets you plan the appearance and functionality first. For example, a wireframe for a youth club website might show a Join button on the Home page linking to a sign-up screen. The client and production team can spot that the link is missing or unclear before production begins.

When a wireframe is suitable

• Planning website pages and their links, including the mobile version of a website.
• Planning interactive kiosk screens, such as a touchscreen map in a shopping centre.
• Planning app screens, such as a fitness app with Home, Workout and Progress screens.

In each case, the wireframe gives an early view of the structure and navigation. That makes it a low-cost way to agree the plan with a client before expensive production begins. It is not detailed artwork: it is a planning tool.

A wireframe is a low-detail plan of a page or screen. It shows where each component sits and how screens connect, but not the finished appearance. Keeping it simple lets you sketch several layouts quickly and agree the structure before artwork begins.

Placeholders instead of real content

Text, images and video often change dynamically: a news page swaps its stories daily, and a canteen page swaps its menu weekly. A wireframe cannot predict that content, so it uses placeholders that stand in for whatever ends up there.

• Images are shown as a crossed box: a rectangle with an X drawn corner to corner inside it.
• Text is shown as straight or wavy lines, or as dummy text such as a repeated filler sentence.
• Buttons and text boxes are shown as squares or boxes, so the space they take up is clear.

Line thickness carries meaning too. In a weather app wireframe, a thick line for the city name and thin lines for the forecast suggest the city name will be set much larger, so the screen's hierarchy is obvious at a glance.

Layout, links and GUI objects

Every component needs a clear position: which corner holds the logo, whether a search bar runs across the top, and how much space the main content takes. If it is not drawn in place, whoever builds the screen has to guess.

Graphical user interface (GUI) objects must be made obvious rather than implied, because they are what the user clicks or taps. A menu bar, a set of buttons and breadcrumbs (the trail such as Home > Clubs > Chess Club) should each be drawn and labelled.

Links and actions between screens should be shown and labelled, for example an arrow from a login screen labelled "opens the dashboard when the details are correct". Without these labels the wireframe shows one screen but not how the user travels through the product.

In a museum visitor app wireframe, each exhibit photograph is a crossed box, with a box labelled "search exhibits" and a labelled arrow to that exhibit's audio guide screen. Colour and photography are undecided, yet the designer could build from it.

A wireframe is a planning document shared across a project team, not just used by the person who draws it. Several different people read the same wireframe, each for a slightly different reason, so the layout and the labelled links or actions between screens must be clear enough for all of them to follow.

These users fall into two groups. Designers, UX designers and app designers plan with the wireframe; developers and programmers build from it. Both groups depend on the same thing: the intended layout, and the links or actions that connect one screen to the next, understood before production begins. That is why a wireframe is deliberately plain rather than a finished visual design, as covered in Components and Conventions of a Wireframe.

An effective wireframe is a low-detail layout plan that a client can understand quickly and a production team can follow. It communicates one clear idea, and its content matches what the client actually needs rather than adding features nobody asked for. It is not finished artwork: it is a plan for structure and navigation.

Clear layout and conventions

Every component should have an obvious position, so spacing and alignment show exactly where each item sits on the screen. Use the conventions correctly: crossed boxes for images, lines or dummy text for text, and boxes for buttons and text boxes. For example, a wireframe for CourtSide, a community tennis club's court-booking app, could use crossed boxes where court photos will go and a box labelled Book court for the main action.

Links and actions between screens must be shown and labelled, such as an arrow marked opens booking form. GUI objects such as menus, buttons and breadcrumbs should be easy to identify, so anyone reading the wireframe can see how the user moves around.

Suited to the device

A phone screen is narrow, so a mobile wireframe cannot be the desktop layout simply shrunk down. Where a desktop version might spread six section names in a bar across the top, the phone version stacks the items in a single column or hides those choices behind a hamburger menu icon, the three stacked lines in a corner that open a menu when tapped. Touch targets are made larger so a thumb can hit them, and fewer items on screen at once keep the page easy to use.

Annotations explain the design

Short annotations beside the layout explain choices, such as court list sits above the map because members pick a time before a location or this link goes back to the home screen. They show the client why the content meets their needs and help developers build each screen correctly.

Improving a wireframe means changing your draft layout so the finished product is easier for its users, while still meeting the client's brief. You keep the same idea and make a handful of deliberate changes, showing each one on the wireframe itself. Imagine a visitor app for a city farm, where the client wants more people booking animal-feeding sessions.

Changes that help users

• Image placeholders where visuals help: put a crossed box beside each animal's name, so visitors recognise a goat or an alpaca at a glance instead of reading a description.
• Less text: swap three lines of dummy text per animal for one short line, so six animals fit on the screen instead of three. More content is visible without scrolling.
• Action buttons next to relevant items: a small box labelled Book beside every feeding session lets a visitor act immediately, rather than hunting through a menu for the booking page.
• Different line widths for hierarchy: a thick line for the screen title, a medium line for each animal name and a thin line for extra detail. The thickness stands for font size, so the eye lands on the most important text first.
• Expected positions: the logo in the top-left corner and the navigation icon in the top-right, because that is where users look for them.
• Headings that give instructions: a heading such as Choose an animal to visit tells a first-time visitor exactly what to do.
• Images for visual appeal: a wide placeholder across the top shows where an inviting photo of the farm will go, which suits a family day out.

Annotate every change

Write a short note beside each improvement explaining why the change is better for visitors and how it helps the client get what they asked for, for example: “Shorter descriptions – six animals on screen, so visitors find a favourite faster and are more likely to book.” An annotation turns a change into evidence that you thought about the user and the brief, not just about making the screen look nice.