Wireframes

Wireframes are for one thing: making layout arguments visible before anyone falls in love with a colour or a typeface. The four wireframes below are for a fictional freelance invoicing app called Ledger. Low fidelity, greyscale, no branding. If the argument does not survive at this fidelity, the polished version will not save it.

What wireframes are actually deciding

Every rectangle above answers a question about hierarchy and density. Is the sidebar a permanent fixture or a collapsible sheet? Does the invoice list default to newest first or overdue first? Is the "New invoice" button in the top right of every screen, or does it live on a floating action button on the list view? Answering these questions with greyscale rectangles keeps the conversation about behaviour instead of colour.

The four screens I usually draw first

Dashboard, list, detail, and create. Almost every SaaS product I have worked on reduces to those four. If the wireframes hold up here, the rest of the system tends to follow. Settings screens, empty states, and edge case flows come later. Starting with the four screens where the user spends the most time keeps the argument focused on the load-bearing decisions.

What the greys mean

Solid dark rectangles are primary actions or heavy text (headings). Medium grey is body text. Light grey is a container or a placeholder for a component that has not been decided yet. Empty stroke rectangles are secondary actions. Reviewers who ask about colour at this stage get told the answer sits three fidelities away. Reviewers who ask about behaviour get a productive conversation.

Notation on the side (not shown)

Every wireframe I share has a call-out column next to it with numbered notes. Note 1 explains what "primary action" means on this screen. Note 2 flags an open question ("does this list paginate or infinite scroll?"). Note 3 links to the corresponding node on the flow diagram. The wireframe carries the layout, the notes carry the reasoning.

Design decisions

• Greyscale only. One colour on a wireframe (an accidental blue button, a red error state) shifts the conversation to visual design too early.
• Same page chrome on every screen. Header, sidebar rail, and footer stay identical across the four wireframes so the layout system is visible at a glance.
• Real copy, not lorem ipsum. Placeholder text hides length problems. Real invoice numbers and client names show whether the table actually breathes.
• Numbered notes, not annotations on top of the frame. Notes live in a side column so the wireframe itself stays clean.

The stack

Tool

Figma with a wireframe component library (grey rectangles at defined weights).

Delivery

Static PDF with a numbered notes column for engineering review.

Next step

Once approved, screens move into the design file at full fidelity in the same Figma project.