By the end of the lesson, you understand why a low-fi wireframe is for examining structural questions. You can make a screen sketch from a user flow, mark the main task, the information, and the state on the screen, and tell a structural decision apart from later visual decoration.
Why don't we start with the visuals?
Someone designing for the first time tends to draw beautiful screens right away. This is understandable: it is what we see, and it is what we like best. The disadvantage is that the feedback is also directed at the visuals. If the participant says "this blue is nice", it tells nothing about whether they understand the interface. The wireframe avoids this misdirection: it is deliberately simple so that the conversation is about structure and operation.
Why do we start with low detail?
A low-fidelity (low-fi) design is a low-detail, quickly modifiable model. A wireframe is a low-detail screen sketch showing the structure and hierarchy of the interface. Low-fi can be paper, a whiteboard, a simple Figma file, or any tool that can be quickly modified. Adapt the level of detail to the question: if you are examining the order of the screens, a few boxes and labels may be enough; if you are testing whether people understand the language of an error message, realistic text may be more important.
The scale of detail (with the terms learned):
Level
What does it show?
When is it good?
Hand sketch
Boxes, lines, labels
Ideation, quick layout debate
Low-fi wireframe
Gray blocks, real labels, hierarchy
Testing structure and task sequence
Mid-fi
Precise layout, real content, little style
Examining content and trust
High-fi
Final colors, images, styles
Visual impact, presentation
In this chapter we work at the low-fi level.
From flow to screen
Do not start with an empty canvas. Take out the user flow, and for every important state ask:
What must the user know here?
What must they decide?
What can they do (from which actions can they choose)?
From what do they see the consequence?
A time-picker screen, for example, has to show more than a calendar. For the decision, the location, the duration, the price, the capacity, and the way of changing the earlier choice may also matter.
Next to the normal path, also draw the empty, loading, or error state. You do not have to work out every state fully, but at the critical points of the flow indicate what would happen. The goal of the sketch is that the team and the tester talk about the same system behavior.
The structure of a screen
A wireframe usually shows the following layers:
Title / context: where am I?
Main information: what is needed for the decision.
Primary action: the most important action supporting the main task of the screen.
Secondary options: alternatives of lower emphasis.
State: indicating loading, error, success, if relevant.
What to mark on a wireframe?
The primary action is the most important user action supporting the main task of the screen. An annotation is a short explanation attached to the sketch about a behavior or an assumption. It is useful if on a sketch the title of the screen, the main information, the primary action, the secondary options, and the state are clear. For a complex element, describe the assumption in a short annotation: for example "only free appointments can be selected", "the error message appears after submission", or "the earlier data is kept when going back". This prevents everyone from reading something different out of the look of the screen.
What not to put into a wireframe?
Do not use colors, photos, and illustrations that look final.
Do not choose a typeface for decoration; a neutral, readable one is enough.
Do not work with "Lorem ipsum" text in places where the text is part of the task (label, button, error message). There use real text.
Do not draw all the screens at once; make and try out the critical states of the main task.
Worked example: the first wireframe of Mai program
The Mai program team draws the main task: "choosing a program for tonight". The first sketch shows a detailed map and many filters right before the result list. In testing it turns out that participants first only want to see what is on today, how much it costs, and where to go. In the next low-fi version the list comes first, the map becomes a secondary view, and the key data (time, price, language, registration) appear on every card. The change follows not from visual taste but from the order of decisions.
The annotation at the card: "Price and registration requirement are always visible, without abbreviation; if the data is missing, 'Price unknown' appears."
Common misconceptions
Claim
Clarification
"A wireframe should be ugly."
The goal is not ugliness, but that details do not hide the structural question.
"You must draw all the screens first."
First make and try out the critical states of the main task.
"Low-fi cannot be tested."
For many navigation, content, and hierarchy questions low-fi is exactly the best tool.
"A wireframe is a sketch of the final screens, just without colors."
A wireframe is a structural model; the final look also makes other decisions.
In brief
A wireframe is deliberately simple so that feedback is about structure and operation.
A low-fi design can be modified quickly; adapt the level of detail to the examined question.
Every important state of the user flow should have a screen sketch, together with the critical exceptions.
The annotation records behavior and assumptions, so that everyone reads the same.
Review questions
Which user flow state is still missing a screen sketch?
What is the primary action on each of your sketches?
What assumption must you record in an annotation?
Which detail would now distract from the structural question?
Low-fi thinking and screen sketches
Objectives
By the end of the lesson, you understand why a low-fi wireframe is for examining structural questions. You can make a screen sketch from a user flow, mark the main task, the information, and the state on the screen, and tell a structural decision apart from later visual decoration.
Why don't we start with the visuals?
Someone designing for the first time tends to draw beautiful screens right away. This is understandable: it is what we see, and it is what we like best. The disadvantage is that the feedback is also directed at the visuals. If the participant says "this blue is nice", it tells nothing about whether they understand the interface. The wireframe avoids this misdirection: it is deliberately simple so that the conversation is about structure and operation.
Why do we start with low detail?
A low-fidelity (low-fi) design is a low-detail, quickly modifiable model. A wireframe is a low-detail screen sketch showing the structure and hierarchy of the interface. Low-fi can be paper, a whiteboard, a simple Figma file, or any tool that can be quickly modified. Adapt the level of detail to the question: if you are examining the order of the screens, a few boxes and labels may be enough; if you are testing whether people understand the language of an error message, realistic text may be more important.
The scale of detail (with the terms learned):
In this chapter we work at the low-fi level.
From flow to screen
Do not start with an empty canvas. Take out the user flow, and for every important state ask:
A time-picker screen, for example, has to show more than a calendar. For the decision, the location, the duration, the price, the capacity, and the way of changing the earlier choice may also matter.
Next to the normal path, also draw the empty, loading, or error state. You do not have to work out every state fully, but at the critical points of the flow indicate what would happen. The goal of the sketch is that the team and the tester talk about the same system behavior.
The structure of a screen
A wireframe usually shows the following layers:
What to mark on a wireframe?
The primary action is the most important user action supporting the main task of the screen. An annotation is a short explanation attached to the sketch about a behavior or an assumption. It is useful if on a sketch the title of the screen, the main information, the primary action, the secondary options, and the state are clear. For a complex element, describe the assumption in a short annotation: for example "only free appointments can be selected", "the error message appears after submission", or "the earlier data is kept when going back". This prevents everyone from reading something different out of the look of the screen.
What not to put into a wireframe?
Worked example: the first wireframe of Mai program
The Mai program team draws the main task: "choosing a program for tonight". The first sketch shows a detailed map and many filters right before the result list. In testing it turns out that participants first only want to see what is on today, how much it costs, and where to go. In the next low-fi version the list comes first, the map becomes a secondary view, and the key data (time, price, language, registration) appear on every card. The change follows not from visual taste but from the order of decisions.
The annotation at the card: "Price and registration requirement are always visible, without abbreviation; if the data is missing, 'Price unknown' appears."
Common misconceptions
In brief
Review questions