Stop 08 · Systems & Technical UnderstandingTopics · 8/9

Basic Wireframing for Requirements

In short

Three paragraphs describing a screen can be read three different ways. A rough sketch with boxes and labels gets everyone picturing the same thing in seconds.

Sketching rough, low-fidelity layouts to communicate a requirement visually — a BA skill for thinking on paper and making an abstract requirement concrete, not a substitute for a designer's final mockup.

The purple blob draws chalk lines on a length of fabric on a table, with scissors and a measuring tape beside it.

Think of it like this

The tailor's chalk marks

Before cutting expensive fabric, the tailor draws chalk lines: collar here, pocket there, sleeves this long. You can check and change chalk in a minute. Cut cloth can't be uncut. A wireframe is chalk on your idea before design and code begin.

Watch it happen

A wireframe for a 'Raise refund' screen

Refund screen

Header

Form

Actions

Order summary

Reason dropdown

Photo upload

Submit button

1/5Start with the screen's one job: let a customer request a refund for one order.

The big ideas

What you need to know

Low fidelity on purpose

Grey boxes and labels, no colours or fonts. People comment on content and flow instead of styling.

Annotate the rules

Notes beside elements carry the logic: required fields, limits, what each button does.

Show the states

Sketch empty, error and success states too. These are where missing requirements hide.

Not the final design

Your wireframe explains the need. Designers decide the final look and may change the layout.

Save yourself the pain

Common mistakes

Oops

Spending hours making a wireframe look polished.

Do this instead

Keep it rough. Speed lets you try two or three layouts and throw away the weak ones.

Oops

Drawing only the happy path screen.

Do this instead

Add the error message, the empty list and the confirmation screen as well.

Your mission

Sketch three states

~20 min

Quick check

Why are early wireframes kept grey and rough?

Go deeper

1Sketch a wireframe for a feature requirement using pen and paper or a simple tool.
2Practice explaining a flow using only boxes and arrows, no visual design detail.
3Learn when a wireframe accelerates a requirements conversation versus when it's unnecessary.