How to Create Wireframes: A Step-by-Step Guide for 2026
Wireframe a real SaaS screen in two hours, step by step. Eight steps from blank paper to stakeholder-ready. Includes empty, loading, and error states most designers skip.
Published: 2026-05-10
This is the step-by-step companion to What is Wireframing. If you have read the concept piece and want the actual hands-on process, this article walks you through wireframing one real screen, end to end, in about two hours. The example is a SaaS billing page because it is dense enough to teach the process, simple enough to fit in one article, and a screen most readers have already used many times.
Eight steps from blank paper to "ready for stakeholder review." Pen-and-paper for steps 1 through 4, Figma or Excalidraw for steps 5 through 8. No tooling expertise required.
Before you start: five minutes of prep
Three things to lock down before you draw anything:
The screen goal in one sentence. "Let users review their plan, change billing details, and download invoices." Specific verbs, specific outcomes.
The user journey leading here. Where did the user just come from? Where do they expect to go after? Skipping this is how you wireframe a screen that breaks the flow.
A content list. Every element that has to appear: current plan, plan-change CTA, payment method, invoices, account-level toggles, support link. Bullet list, not prose.
For our example billing page:
Goal: let users see their current plan, change it, manage payment method, and access invoices.
Comes from: settings navigation.
Goes to: plan-change flow, invoice download, support.
Content: current plan card, change-plan button, payment method, invoices table, cancel-plan link.
Step 1: Sketch the layout grid (10 min, paper)
Take a blank sheet and draw three rectangles for desktop (1440 wide), tablet (768), mobile (375). Inside each, sketch a 12-column grid.
The grid is your scaffolding. It tells you where elements snap, how content reflows, and where you have rhythm vs randomness. Do not draw any UI yet. Just the grid.
Step 2: Block in primary content (15 min, paper)
For each viewport, sketch boxes for the major content regions:
Top: nav (full width).
Left: settings sidebar (3 columns on desktop).
Main: billing content (9 columns on desktop).
Footer: minimal.
In the main region, sketch the rough position of each content block from your list:
Current plan card (top).
Change-plan button (right of plan card).
Payment method (below).
Invoices table (below).
Cancel link (bottom, small).
Use boxes with labels. No real content yet. The point is layout, not labels.
Step 3: Add navigation patterns (10 min, paper)
Sketch how navigation behaves at each breakpoint:
Top nav: persistent across all pages.
Left settings sidebar: the user is on /settings/billing; mark that item active.
Mobile: where does the settings sidebar go? Drawer? Tabs? Replaced top nav?
Decide before you commit. The mobile pattern is where most SaaS settings pages fall apart. Be explicit.
For our billing page: desktop has a left sidebar with category items. Mobile collapses the sidebar into a back-button + breadcrumb at the top.
Step 4: Iterate on hierarchy (10 min, paper)
This is where the wireframe earns its keep. Look at your sketch and ask:
What is the primary action on this screen? Is it the most prominent thing?
What is the second priority? Is it differentiated from the first?
Anything competing for the user's eye that should not be?
For billing: the primary action is "change plan." Secondary is "view invoices." Cancel is intentionally last and small.
Adjust your sketch:
Make the change-plan button visually heavier.
Move invoices below the fold (they are not the primary goal of this visit).
Push cancel to the absolute bottom.
Redraw if needed. Most wireframes need two or three versions before hierarchy lands.
Step 5: Move to digital and annotate (20 min, Figma or Excalidraw)
Open your tool of choice. Recreate the desktop and mobile sketches as clean greyscale wireframes. Real labels, real spacing, real placeholder content.
Then add annotations. Numbered callouts pointing to each non-obvious decision:
1. "Change plan is the primary CTA: bold, filled button."
2. "Plan card shows price plus renewal date. Renewal date is critical because users cancel before it."
3. "Payment method shows last 4 digits. Edit opens an inline form, not a new screen."
4. "Invoices is paginated, 10 per page. Older than 1 year is collapsed."
5. "Cancel is a text link, low contrast. Confirmation is a 2-step modal."
The annotations are what stakeholders read. Without them, the wireframe is decoration.
For a fast no-tool first pass, the wireframe generator takes a text description and gives you a clean wireframe to start from.
Step 6: Add empty, loading, and error states (15 min)
The happy path is the easy part. Now wireframe:
Empty state. New user with no payment method yet. What does the page look like? (Probably a CTA: "Add a payment method.")
Loading state. The page is fetching plan data. What does the user see? (Skeleton, not a spinner. Always skeleton.)
Error state. Plan fetch failed. What does the user see? (A specific error message, not "Something went wrong." A retry button.)
Three additional wireframes, simpler than the main screen. These are the screens engineers will ask for, and if you do not provide them, will design themselves on the fly.
Step 7: Stakeholder review (30 min, often async)
Walk through the wireframe with your PM, eng lead, and at least one user-facing stakeholder (support, sales, a real customer). Format:
1. State the goal of the screen (one sentence, from your prep).
2. Walk through the desktop wireframe top to bottom, reading your annotations aloud.
3. Show the mobile version. Highlight the layout shift between viewports.
4. Show empty, loading, and error states.
5. Open it up for questions.
Capture every comment. Iterate. Two or three rounds is normal. Resist the urge to defend choices that were really just first instincts.
Step 8: Handoff to hi-fi or development (10 min)
Once the wireframe is locked, you have two options:
Mockup. Layer in visual design (color, typography, real images) on top of the wireframe in Figma. Hi-fi mockup is the next stage. Use the website mockup generator for clean device frames in case studies.
Direct to dev. For internal tools or low-design-investment products, hand the wireframe directly to engineering. Pair it with a Figma file and a short Loom walkthrough so the dev sees what the static frame is meant to do at runtime.
Either way, save the locked wireframe in a versioned file. You will refer back to it during implementation when an edge case surfaces.
Total time
About two hours for a single screen, end to end:
Prep: 5 min
Sketch (steps 1 to 4): 45 min
Digitize and annotate (step 5): 20 min
Empty / loading / error states (step 6): 15 min
Stakeholder review (step 7): 30 min, often async
Handoff (step 8): 10 min
Skipping any step costs you 10x more in rework downstream. The full process is genuinely faster than the alternative.
Common stuck points
"I don't know what to draw first." Start with the desktop nav and footer. The middle fills in once the boundaries are defined.
"My sketches look bad." That is the point. Low-fi wireframes are supposed to look bad. Polish at this stage is wasted.
"Stakeholders keep changing their mind." They are doing their job; you are doing yours. The wireframe stage exists exactly so changes happen here, not in mockup or in code.
"My PM wants to skip wireframes and go straight to mockup." Push back. The wireframe stage costs two hours per screen. The rework when a mockup decision goes wrong costs two days. Show them this article.
"I keep drawing the same layout." Force three different versions in step 1. If they all converge, the constraints are tight enough that you have your answer. If two diverge meaningfully, sit on it overnight.
Tools mentioned
Pen and paper. Steps 1 to 4. Free. Fastest. Zero tooling friction.
Figma. Step 5 onward. The 2026 default for design teams.
Excalidraw. Step 5 alternative if you want hand-drawn style on screen. Free, open-source.
Balsamiq. Step 5 alternative with built-in low-fi UI patterns.
Talos Tools wireframe generator. AI-generated first drafts that you then edit aggressively. Useful when you are stuck.
FAQ
Pen versus Figma to start?
Pen first, every time. Steps 1 to 4 of this guide are paper. Move to Figma at step 5 once your structure is sound. Skipping paper means more rework, not less.
How detailed should low-fi be?
Just enough to evaluate hierarchy and flow. No real text inside content blocks. No colors. Boxes and labels with rough placement.
AI tools: when do they help?
As a draft generator at step 5 if you are stuck or want a starting point. As a first draft for the empty, loading, and error states (step 6). Edit aggressively after.
How many iterations?
Plan for two or three stakeholder review rounds. More than five means the goal of the screen is unclear; go back to step 1 of prep.
Mobile-first wireframes?
Mobile and desktop in parallel from step 1. Mobile-first works for genuinely new screens; for existing products, doing both side by side surfaces the worst issues fastest.
Should I wireframe in color?
No. Color signals "finished." Stakeholders reviewing colored wireframes argue about colors instead of layout. Greyscale is the right surface for the structural review.
Where to go from here
The conceptual companion, What is Wireframing, covers fidelity levels, the tool landscape, and when to use which fidelity. After your wireframe is locked, the website mockup generator creates clean device frames for case studies, and the website UX/UI analyzer audits finished pages for hierarchy and clarity issues. The social media post generator covers case-study marketing visuals.
If you are coming at design from a product or research angle, the product manager roadmap covers wireframing as one piece of broader product discovery. The UI/UX portfolio guide covers how to present finished wireframes in case studies that win interviews.
Last updated: April 2026.
Last updated: 2026-05-10