How to Create a Wireframe: Complete Step-by-Step Guide

Before drawing a single rectangle, write one sentence for each screen you are about to wireframe. That sentence must describe what the user is trying to accomplish on that screen — not what the business wants to show them, not a feature list, and not an aesthetic direction. A clear user goal acts as a decision filter for every layout choice that follows.

Here are examples that show the difference between a vague description and a clear user goal:

Notice that clear user goals are written from the user's perspective and contain a why (so they can decide, so they reach value, so they know what to do next). This framing changes your layout decisions. A product page optimized for helping someone decide will prioritize comparison features, reviews, and clear return policy — rather than hero imagery and brand storytelling that serves the business.

Write your user goals in a document or at the top of your first artboard. Refer back to them every time you are unsure whether to include a UI element. If an element does not directly serve the user goal, it should either be removed or de-emphasized.

This exercise often surfaces conflicts between what the business wants on a page and what serves the user. Document those conflicts openly — they become UX decisions for stakeholders to make, not silent design choices that surprise people at review.

A content inventory is exactly what it sounds like: a complete list of every piece of content and every UI component that belongs on a screen. Creating this list before opening your layout tool is one of the highest-leverage habits in wireframing. It takes 5 to 10 minutes per screen and eliminates the most common problem in first-draft wireframes: discovering mid-layout that you forgot a critical element.

For each screen, write down every content element, categorize it, assign a priority, and note any constraints. Here is a worked example for an e-commerce product detail page:

This table takes less than 10 minutes to create and gives you three things: a checklist to verify your wireframe is complete, a priority ranking that guides visual hierarchy decisions, and constraint notes that prevent layout decisions that will not work in production. Notice the notes column — "full width on mobile" and "collapsed toggle on mobile" are constraints that affect how you wireframe the mobile version. Without this step, these constraints would surface as surprises during developer handoff.

You do not need a spreadsheet for this. A text file, a notes app, or a simple list on paper works fine. The point is to think through content systematically before you start placing shapes on a canvas.

Pick up a pen. Open a notebook. Before opening Figma, Balsamiq, or any digital tool, spend 15 to 20 minutes sketching three to five radically different layout options on paper. This is the thumbnail technique — a practice borrowed from illustration and used widely in UX design to prevent premature convergence on the first layout idea that comes to mind.

The rules for thumbnail sketching are simple: keep each thumbnail small (roughly the size of a business card), draw quickly without worrying about neatness, and do not erase. You are not creating finished sketches — you are externalizing layout hypotheses so you can compare them side by side. Speed is the point. A thumbnail that takes five minutes has almost no sunk cost attached to it, which means you will genuinely consider alternatives rather than defending the first idea you spent time on.

After sketching three to five options, evaluate each against the user goal from Step 1 and the content inventory from Step 2. You are looking for the strongest structural argument — not the prettiest sketch.

• Mark the winner with a star — this becomes your digital starting point
• Keep the others — if the first digital version does not feel right, you have alternatives without starting from scratch
• Combine the best parts — if Option A has a stronger hero but Option B has a better reviews layout, sketch a quick hybrid before going digital

Open your digital wireframing tool and set up your working environment before placing any elements. This setup phase takes about five minutes but prevents significant rework later. If you skip it, you will likely build your wireframe at the wrong dimensions and with inconsistent spacing.

Create Your Artboards at Standard Viewport Sizes

In Figma: press F (Frame tool), then select a preset from the right panel, or type dimensions manually. The standard sizes to work with in 2026 are:

• Desktop: 1440 × 900px — the dominant desktop breakpoint for modern web design
• Laptop: 1280 × 800px — useful for checking that your layout works at this size too
• Tablet: 768 × 1024px — iPad portrait, a critical breakpoint often overlooked
• Mobile: 375 × 812px — iPhone SE / standard smartphone width
• Mobile (large): 430 × 932px — iPhone 14 Pro / Android XL class devices

For most projects, start with desktop (1440px) and mobile (375px). Add tablet only when the design has significantly different behavior at that size — for example, a responsive grid that goes from 3 columns to 2 columns.

Set Up a 12-Column Grid

In Figma: select your frame, click the + button next to "Layout Grid" in the right panel, select "Columns", set count to 12, gutter to 24px, margin to 80px (for 1440px desktop). For mobile (375px) use 4 columns, 16px gutter, 16px margin.

Why 12 columns? Because 12 is divisible by 1, 2, 3, 4, 6, and 12, giving you maximum layout flexibility with a single grid system. You can create full-width layouts (12/12), two-column splits (6+6), three-column grids (4+4+4), a content-sidebar split (8+4), and more — all snapping to the same grid.

In Balsamiq: the tool handles layout loosely by design, which is fine for lo-fi work. Focus on rough proportions rather than pixel-perfect column alignment.

Establish Your Spacing System

Define a base spacing unit before you start placing elements. The standard is 8px — meaning all spacing values should be multiples of 8 (8, 16, 24, 32, 48, 64, 80, 96). This creates visual rhythm and makes developer handoff straightforward because CSS typically works in multiples of 8. In Figma, set your nudge amount to 8px (Preferences > Nudge Amount) so that arrow key movements default to your spacing unit.

With your canvas set up, begin placing the major structural zones of your page from top to bottom. At this stage, use solid grey rectangles only — no text, no icons, no detailed UI components. You are building the skeletal frame, not the finished layout. This constraint is deliberate: it forces you to resolve layout and proportion decisions before getting distracted by detail.

The standard top-down order for a web page is: global navigation, hero / above-the-fold section, primary content section(s), secondary content sections, and global footer. For app screens the equivalent is: status bar / top navigation bar, hero or primary content zone, action area or tab bar.

At this stage you are making three types of decisions. First, proportional decisions: how tall should the hero be? How much vertical space does the feature row need? These decisions establish the visual weight of each zone relative to the others. Second, layout decisions: should the content section be full width, or should it sit inside an 8-column content area with a 4-column sidebar? Third, priority decisions: does the visual hierarchy of your structural blocks match the priority hierarchy from your content inventory? The most important zone should have the most prominent position and proportional weight.

Do not advance to Step 6 until every zone on your content inventory list has a corresponding structural block on the canvas. If something is missing, add it now. Moving to the detail phase with structural gaps is how wireframes end up missing critical UI elements at review.

Now that your structural zones are in place, fill each zone with the specific UI components that belong there. You are still working in greyscale — the only difference from Step 5 is that generic grey rectangles are replaced by recognizable UI patterns: navigation bars with links and CTAs, form fields with labels, image placeholders with the standard X-box convention, and text blocks represented by grey horizontal lines.

The Standard Placeholder Conventions

Wireframing has an informal but widely understood visual language. Using these conventions makes your wireframes instantly readable by anyone familiar with design:

• Image placeholder: A rectangle with an X drawn corner-to-corner, or a grey box with a mountain/image icon. Avoid using actual images in lo-fi or mid-fi wireframes — they pull attention toward aesthetics.
• Text placeholder: Horizontal grey lines (thicker lines for headings, thinner for body text, varying widths to simulate natural line breaks). In some tools these are called "Lorem ipsum" blocks. In Figma you can use the "Text > Placeholder" style.
• Button: A rounded rectangle with a short horizontal line inside (representing the button label). Use a darker fill for primary CTAs, an outline for secondary buttons.
• Form field: A rectangle with a label above and a single line inside (representing placeholder text). Group label + field as a unit.
• Video: Same as image placeholder but with a play icon circle in the center.
• Avatar / profile image: A circle with a smaller circle inside (head) and a half-circle at the bottom (shoulders). Or simply a grey circle.
• Icon: A small grey square or circle with a simple geometric mark inside. Avoid using specific icons — it pulls attention to the wrong level of detail.

As you place UI components, pay attention to three things: proximity (related elements should be grouped together with consistent spacing), alignment (elements should align to your grid columns, not placed arbitrarily), and hierarchy (primary CTAs should be visually distinct from secondary actions — use fill weight, not color, at the wireframe stage).

This is also the stage where you may discover that your structural blocks need to be resized. A hero section that seemed adequately tall in Step 5 may turn out to be too short to accommodate the headline, subheadline, and two CTAs you planned. When this happens, adjust the structural blocks — this is expected and normal.

A wireframe without annotations is an incomplete deliverable. Annotations are the notes attached to your wireframe that explain how the UI behaves, not just what it looks like. This step is frequently skipped by designers who are rushing to the visual design phase — and it is responsible for a majority of developer-designer miscommunications during build.

The Annotation Numbering System

Use a simple numbered annotation system: place numbered circles next to UI elements that require explanation, then list the corresponding notes in a legend beside the wireframe or in a separate annotations panel. Keep numbers sequential and consistent across screens. Example:

• 1. Navigation: Sticky on scroll. On mobile, collapses to hamburger menu (see screen M-02 for mobile nav state).
• 2. Hero headline: Dynamically populated from CMS. Max 60 characters. Falls back to default if CMS field is empty.
• 3. Primary CTA button: Links to /sign-up. On click, scrolls user to registration form on the same page if they are already on /pricing.
• 4. Feature cards: Three cards on desktop, horizontal scroll carousel on mobile (snaps per card). Cards are CMS-managed.
• 5. Email form: Submits to Mailchimp list via API. Shows inline success message after submission. Shows inline error message if email already registered.

Flow Arrows and Screen Connections

When wireframing a multi-screen flow, connect screens with arrows to show user navigation paths. In Figma, use the connector tool (Shift+C in prototype mode) to draw click-through flows. Label each arrow with the trigger: "User clicks Sign Up button" or "User submits form → success". This creates a navigable prototype that stakeholders can click through, which dramatically improves feedback quality.

Good annotations answer the questions a developer would ask when looking at your wireframe cold. Ask yourself: if someone who was not in any of the design conversations looked at this wireframe, what would they be confused by? Write an annotation for each of those points. When in doubt, over-annotate. A thorough annotation takes 30 minutes but saves multiple hours of back-and-forth during development.

When all seven steps are complete, you have a wireframe that is ready for stakeholder review. Share a Figma link in comment mode so reviewers can leave feedback directly on the wireframe rather than in a separate email thread. This keeps feedback contextual and makes it significantly easier to process.