Wireframing

The morning change window won the vote. Before anyone chooses a shade of orange, the team needs to agree on what the screen shows, in what order, and what happens on each tap. A wireframe settles those questions quickly, and it keeps the conversation away from fonts and colours while the structure is still moving.

The rule

Wireframes decide what goes where and why, not how it looks.

A wireframe is a simplified layout of a screen: grey boxes, plain lines, one neutral typeface, no brand colours and no real imagery. It fixes four things:

• Content: what information and controls the screen holds.
• Priority: what matters most, shown by size and position.
• Layout: where each piece sits.
• Behaviour: what each control does.

A few habits make wireframes useful:

• Function before polish. An early wireframe has to work as a flow, showing what happens next, not look impressive.
• Real content, not filler text. "Today · Paneer tikka, dal, 2 rotis · Change until 7:30 a.m." exposes long names and missing information that dummy text would hide.
• Annotations. Short notes beside a box explain behaviour: "Change is disabled after 7:30 a.m. and shows the lock time."
• Flows, not single screens. Home → Today card → change sheet → confirmation.

Fidelity can rise as confidence does: rough boxes to explore, then clean grey layouts to review with developers and stakeholders.

The shortcut

Rank before you draw. List everything the screen must show, number the items by how much they matter to the job, and let the ranking decide size and position.

The trap is the colour debate. If a review drifts into "should this be orange?", note it for the visual stage and bring the room back to structure and flow.

Drills

Answer fast — trust the rule.

Remember

• Wireframes decide what goes where and why, not how it looks.
• Shortcut: rank the content by the job, then let the rank set size and position.
• Trap: arguing about colour while the structure is still open.