How to Wireframe a Website: A Practical Guide with a Worked Example

A website wireframe is a rough plan of a page: what information appears, in what order, and what a visitor can do next. Rectangles, short labels, and a few arrows are enough. The useful part is deciding which content deserves space and which action the page should support.

This guide walks through a fictional bicycle repair shop's service page. By the end, you will have a repeatable way to plan your own page, a mobile version, and a list of questions to resolve before you spend time on polished design. Open the drawing board if you want to sketch along.

Write a one-sentence page brief

Before drawing a box, finish this sentence: This page helps [person] decide [question] so they can [action]. Keep it specific enough that you can judge whether each section helps.

For the bicycle shop: This page helps a local cyclist decide whether the shop can fix their bike so they can request a repair appointment. That sentence gives the page a clear job. A shop history, photo gallery, and newsletter might all be useful elsewhere, but they do not automatically belong at the top of this page.

• Visitor: a cyclist with a repair problem, possibly viewing the page on a phone.
• Questions: Do you handle my problem? What might it cost? Where are you? What happens after I request a visit?
• Primary action: request a repair appointment.
• Secondary action: call to ask about an unusual repair.
• Constraint: appointment requests need shop confirmation; submitting a form does not reserve a time.

List real content before arranging it

Write the smallest content inventory that answers the visitor's questions. Use working copy rather than filler text. A box labelled text hides whether you need one sentence or six paragraphs; a box labelled Repairs for everyday bikes and e-bikes exposes a meaningful content decision.

In our fictional example, the inventory is a service summary, repair categories, indicative prices with qualifications, expected timing, location, opening hours, an appointment request, and an explanation of the next step. Any price or timing claim would need confirmation from the shop before publication.

Mark missing information directly on the sketch: Confirm e-bike brands serviced or Need current turnaround estimate. An unresolved fact is easier to fix while the page is still a drawing.

Draw the page as a sequence of questions

Start with one tall rectangle for the page. Divide it into broad horizontal sections. Make each section answer a question, then write its purpose beside it. This gives you a reason for the order instead of copying a layout that happens to look familiar.

For the bicycle repair page, sketch this sequence from top to bottom. The example is a starting hypothesis to review, not a universal template.

1. Header: shop name, a short navigation, and a clearly labelled contact route. Can I tell whose page this is?
2. Opening section: Bicycle repairs in [neighborhood], a one-sentence service summary, and Request a repair. Am I in the right place?
3. Service list: punctures, brakes, gears, and other confirmed repair categories. Can you fix my problem?
4. Price and timing section: starting prices, what inspection changes, and how estimates are confirmed. What should I expect?
5. Visit details: address, hours, and any instructions for bringing a bike. Can I get there?
6. Request section: a short form and a sentence explaining confirmation. How do I start, and what happens next?
7. Footer: contact details and essential policy links. Where can I find supporting information?

Make the first screen earn its space

Draw a horizontal line across the page frame to suggest the bottom of the first visible screen. Treat it as an approximation because screen sizes vary. Check whether the opening area identifies the service, the location, and the next action without requiring the visitor to interpret a large decorative image.

For our shop, a full-screen bicycle photo would postpone the repair information. Try a smaller image beside the headline on desktop, or leave it out of the first mobile draft. Label every image placeholder with its job, such as Shop entrance so visitors can recognize the location. If you cannot name its job, question whether it needs that space.

You do not need to fit the whole page above that line. You need enough information for a visitor to understand the page and decide whether to continue.

Use simple drawing conventions

Use rectangles for sections, smaller outlined rectangles for buttons, and text for headings and content notes. Reserve arrows for navigation or interactions; avoid arrows between every section of an ordinary scrolling page. Keep notes outside the page frame so readers can distinguish visible content from instructions to the person building it.

The graph paper view can help you align repeated blocks. Keep one dark color for page content and one accent for annotations. You can decide typography, brand colors, and image treatments after the content and sequence make sense.

• Use a few short horizontal lines to suggest body copy only after writing its actual subject.
• Label buttons with actions: Request a repair is more informative than Submit or Click here.
• Mark image placeholders with a rectangle and a description of the intended subject.
• Number interaction notes so a reviewer can refer to them precisely.
• Draw repeated items at the same size when they have the same role.

Sketch mobile as a separate decision

Draw a narrow frame beside the desktop version. Keep the same visitor goal, then decide the reading order again. Shrinking the desktop sketch would make labels tiny and preserve columns that no longer have enough space.

For the shop, place the headline, service summary, and request button first. Put the supporting image below them. Stack service categories into a single column. Keep prices beside their service labels so the visitor does not have to match information across distant sections.

Write down what happens to navigation. If you propose a menu button, list the links inside it and sketch the open state. If the navigation only has a few short links, try keeping them visible. The wireframe should make the choice explicit.

• Can the main action's label fit comfortably without being abbreviated?
• Does the page still make sense when sections stack in a single column?
• Are important instructions next to the field or action they explain?
• Would a fixed header or bottom button cover any content? Mark the reserved space if you use one.

Include the states after the click

A wireframe of the default page leaves important behavior undecided. Beside the request form, draw small panels for a missing required field, a failed submission, and a successful request. State what the visitor sees and what they can do next.

For our example, the form might ask for a name, contact method, bike type, and a brief problem description. For each field, explain why the shop needs it at this stage. Delay details that can be collected in the follow-up conversation.

The success panel should say Request received, explain that the shop will confirm availability, and give a realistic response expectation once the shop has approved it. A failure panel should explain that the request was not sent and provide a retry or another contact route. Add a build note to preserve entered information when a request fails.

A sketch cannot verify keyboard access, focus behavior, or screen-reader output. It can record requirements for the build: visible field labels, clear errors tied to their fields, and a logical focus order.

Review with a task, then revise

Show the sketch to someone who has not helped arrange it. Give them a realistic prompt: Your rear brake is rubbing and you want to know whether this shop can help. Show me what you would look for and what you would do next. Let them point and explain before you describe your intended layout.

Record specific uncertainty: Could not find the address is actionable; Did not like it needs a follow-up question. If they expect instant booking but the shop only accepts requests, revise the button and confirmation copy. If they search for prices before reading the service list, consider bringing a concise price cue higher.

One review can reveal problems, but it does not establish that every visitor will succeed. Keep the changes tied to what you observed and review again when a major decision changes.

A 30-minute wireframing exercise

1. Minutes 1 to 4: write the visitor, their main question, and the primary action. Choose one page.
2. Minutes 5 to 8: list the content needed to answer that question. Flag missing facts.
3. Minutes 9 to 15: draw a desktop frame and arrange sections. Write a purpose beside each one.
4. Minutes 16 to 21: draw a mobile frame. Decide content order and navigation behavior.
5. Minutes 22 to 25: sketch the main interaction's success and failure states.
6. Minutes 26 to 29: walk through a visitor task, ideally with another person. Fix the clearest obstacle.
7. Minute 30: export a copy and record the next unresolved decision.

Use this checklist before handing it over

A useful handoff explains the decisions and the open questions. Add the page name, version date, and the goal beside the sketch. Export a PNG for a straightforward review image, or an SVG when the recipient needs a scalable file. Keep annotations within the drawing so they travel with the export.

Browser autosave helps you return to the drawing on the same browser and device; it is not a substitute for keeping an exported copy. Name the file for the page and revision, such as bike-repairs-wireframe-v1.png.

• The opening section identifies what the page offers and who it serves.
• The primary action has a specific label and an explicit destination or result.
• Every section answers a visitor question or supports the main task.
• The mobile sketch has a deliberate content order and navigation plan.
• Forms include required information, error behavior, and a confirmation state.
• Unconfirmed facts and missing content are labelled as open questions.
• The recipient can distinguish page content from implementation notes.

Frequently asked questions

What is the difference between a wireframe and a mockup?

A wireframe focuses on content, layout, and actions. A mockup adds visual decisions such as typography, colors, and imagery. Use the wireframe to review what belongs on the page before polishing its appearance.

Do I need drawing skills to create a website wireframe?

No. Rectangles, readable labels, and a few annotations are enough. The important skill is explaining why content appears in a particular order and what the visitor can do next.

Should I wireframe every page of a website?

Start with each distinct page type and important user task. Several service pages may share one layout, while a service page and a contact form need different decisions. Add extra wireframes when content or behavior differs substantially.

Can a sketchpad wireframe be clicked like a prototype?

This workflow produces a static drawing. Show interactions with arrows, annotations, and separate state panels. If you need to test working navigation or form behavior, build a prototype after reviewing the layout.