What a wireframe is and why you need one before you code

A wireframe is a straightforward, stripped-down sketch of a web page that shows where things go and how they connect — without any color, images, or design details. It is the blueprint before the building starts. You draw boxes for the header, boxes for the navigation, boxes for content, boxes for the footer. Inside each box, you write what goes there: "logo here", "search bar", "three product cards", "contact form".

Wireframes exist to answer questions before you write a single line of code. Where does the menu live on mobile versus desktop? Does the sidebar appear on every page or just some? What happens when a user clicks this button — does it go somewhere or does something appear on the same page? If you skip the wireframe and start building, you will find yourself rebuilding when you realize halfway through that the layout does not work or the flow does not make sense.

The wireframe is also where you talk to other people — the designer, the client, the project manager — without getting bogged down in whether the button should be blue or red. Everyone can see the structure and agree on it before anyone spends time on the details.

Key Takeaways

  • A wireframe is a straightforward layout sketch that shows where content and interactive elements go on a page, without colors or images.
  • You can build a wireframe on paper with a pencil, in a free tool like Figma or Balsamiq, or in a shared document — the medium matters less than getting the structure right.
  • Start by listing what content and features each page needs, then sketch the layout for desktop and mobile separately because they often look very different.
  • Use rectangles for images, straightforward text labels for buttons and links, and arrows to show how pages connect to each other.
  • Share your wireframe with teammates or clients before you design or code, because changes at this stage take minutes instead of hours.

Start with a list of what each page needs

Before you draw anything, write down what has to appear on the page. For a product page, that might be: product image, product name, price, description, quantity selector, add-to-cart button, customer reviews, related products, footer with links. For a contact page: contact form with name, email, message fields, submit button, company address, phone number, map, footer.

This list is not the final design — it is the inventory. You are making sure you have not forgotten anything and that you understand what the page actually does. If you are building a site for someone else, this is the moment to ask them: "Does every product page show reviews, or only some? Does the footer change on different pages?" Get those answers now, not after you have already drawn the wireframe three times.

Group related items together mentally. The product image and name probably live near each other. The reviews probably come after the description. The footer probably appears on every page. These groupings will become sections in your wireframe.

Sketch the desktop layout first

Take a piece of paper or open a blank document. Draw a rectangle representing the full width of a desktop screen — roughly 16 units wide and 10 units tall is a good proportion. Inside, draw smaller rectangles for each section: a thin rectangle at the top for the header and navigation, a larger rectangle in the middle for the main content, maybe a narrower rectangle on the right for a sidebar, a thin rectangle at the bottom for the footer.

Label each rectangle with what goes inside it. Write "logo + nav menu" in the header box. Write "product image" in a box on the left, "product details + add to cart" in a box on the right. Write "customer reviews" in a box below. Do not worry about making it beautiful or to scale — the point is to see the structure and make sure it makes sense.

If a section has multiple items, draw smaller boxes inside it. If the product details section has a name, price, description, and quantity selector, draw four smaller rectangles and label each one. This helps you see whether everything fits or whether you need to rearrange.

Create a separate mobile layout

Mobile screens are narrow and tall, so the layout almost always changes. What sits side-by-side on desktop stacks vertically on mobile. A sidebar that appears on the right on desktop might disappear entirely on mobile, or move to a hamburger menu.

Draw a new rectangle, this time much narrower and taller — roughly 4 units wide and 12 units tall. Sketch the same page again, but with everything in a single column. The product image goes at the top, full width. Below it, the product name, price, description, quantity selector, and add-to-cart button, all stacked. Below that, the reviews. The navigation menu might collapse into a hamburger icon (three horizontal lines) in the header.

This is where you discover whether your desktop layout actually works on a phone. If you have a sidebar on desktop, where does it go on mobile? If you have a three-column layout, does it become one column or two? Drawing this out now means you will not have to rethink it while you are writing CSS.

Show how pages connect with arrows and labels

If your site has multiple pages, draw a straightforward diagram showing how they connect. Draw a box for each page: Home, Products, Product Detail, Cart, Checkout, Confirmation. Draw arrows between them showing the path a user takes. From Home, an arrow goes to Products. From Products, an arrow goes to Product Detail. From Product Detail, an arrow goes to Cart. From Cart, an arrow goes to Checkout. From Checkout, an arrow goes to Confirmation.

Label the arrows with what triggers the navigation. "Click product" on the arrow from Products to Product Detail. "Click add to cart" on the arrow from Product Detail to Cart. "Click checkout" on the arrow from Cart to Checkout. This diagram is called a user flow or sitemap, and it helps you see whether the path makes sense and whether you have missed any pages.

If certain pages should only appear under certain conditions — like a "confirmation" page that only appears after a successful purchase — note that on the diagram. If a user can go back from one page to another, draw a two-way arrow. This clarity prevents confusion later when you are building the navigation.

Use tools if you prefer digital wireframes

Paper and pencil work fine, but digital tools let you move things around without redrawing and share the wireframe with others more easily. Figma is free and widely used — you can draw rectangles, add text labels, and share a link with teammates. Balsamiq is designed specifically for wireframing and has templates for common page layouts. Adobe XD and Sketch are more powerful but cost money.

If you do not want to learn a new tool, a shared Google Doc or a straightforward image file works too. The tool is not important. What matters is that you have a clear picture of the layout and that other people can see it and give feedback.

If you choose a digital tool, use straightforward shapes and text. Do not add colors, images, or fonts yet — that comes later in the design phase. A wireframe that looks polished can trick people into thinking the design is final when it is not. Keep it rough and clearly labeled so everyone knows this is a structure sketch, not a finished design.

Get feedback before you move forward

Share your wireframe with the people who need to see it: the designer, the client, the project manager, other developers. Ask specific questions: "Does this layout make sense? Have we missed anything? On mobile, should the sidebar be hidden or should it move below the main content?" Write down the feedback and update the wireframe.

This is the cheapest time to make changes. Moving a box on a wireframe takes seconds. Rebuilding a page because the layout was wrong takes hours. If someone says "the reviews should come before the description, not after", you erase and redraw. If they say that after you have already coded the page, you have to rewrite the HTML and CSS.

Keep iterating until everyone agrees the structure is solid. Then you move to the design phase, where you add colors, images, and typography. Then you move to development, where you write the code. But the wireframe — the skeleton — stays the same.

Frequently Asked Questions

Do I need to wireframe every page or just the main ones?

Wireframe the pages that are different from each other. If you have a Home page, a Products page, a Product Detail page, and a Contact page, those four are all different layouts — wireframe them all. If you have ten product pages that all look identical, wireframe one and note that the others follow the same pattern. You are documenting the structure, not creating busywork.

Should I include interactive elements like dropdowns and modals in the wireframe?

Yes, if they change the layout or the user flow. If clicking a button opens a popup form on top of the page, draw a box for that popup and label it. If a dropdown menu appears when you hover over a navigation item, note that. If a sidebar slides in from the left on mobile, show that. The wireframe should show what the user sees and how the page changes when they interact with it.

What if the client wants me to skip the wireframe and start designing?

Explain that the wireframe saves time overall. It takes an hour to sketch the layout and get agreement. Skipping it means you might spend a day designing and coding something that needs to be rearranged. Show them a rough wireframe — even a photo of a pencil sketch — and ask for feedback. Most clients will see the value once they understand it is not about making the design pretty, it is about getting the structure right.

Can I use a wireframe template instead of starting from scratch?

Yes, if the template matches your site type. If you are building an e-commerce site, a template for a product page saves you from drawing the basic layout. But customize it for your specific needs — remove sections you do not need, add sections you do. A template is a starting point, not a finished wireframe.

Do I need to show exact spacing and measurements in the wireframe?

No. The wireframe shows relative sizes and positions, not exact pixel measurements. If the sidebar is narrower than the main content, draw it narrower. If the header is thin, draw it thin. But you do not need to measure or label dimensions — that comes later when you write the CSS. The wireframe is about structure and flow, not precision.