Design thinking in miniature
Apply in a new contextDesign thinking in miniature is a structure in which teams walk the whole design cycle in one lesson, on a small task, for a client from the next team. Each team sends one student to the neighbors as a client, asks the client who comes to them what the thing must do, writes requirements it can test, sketches, builds from cardboard and tape, lets the client test it, and then changes exactly one thing. It does not replace a design project: it trains the cycle as a whole, so a class has taken every step once before a real project spreads them over weeks. Built for technology and science, and useful in any class where students make something.
One cycle · ± 35 min
Put it on the boardOne screen: the task, the material and whether the roles take part. No task yet? The AI suggests five on your topic. Only you see it; the class sees it only when you press Start.
This exact screen goes on your board. The timer runs per step and you stay in control: pause, add time or move on to the next step. Type the task yourself, or with a free account the AI suggests five on your topic.
What the class sees on the board
8 steps · one cycle, ± 30 min
For you: Let every team choose its client before the clock starts. A solution is not a question yet.
Group size
teams of 4 (or 3) · the whole class
Duration
± 35 min
incl. briefing and look-back
Level
grades 4–12, built for middle school
Materials
a small kit per team: cardboard or paper, tape, scissors
Format
team → client at the next table → class
Purpose
walking the design cycle once
Check two things before the first run. Does your task name a client and leave the requirements open? "Make your client a cardboard stand that holds the phone upright" works; "make a stand 4 inches tall with a hole for the charger" hands every team the same requirements, and then there is nothing left to ask. And agree up front who goes to whom: team 1 to team 2, team 2 to team 3, and the last team to team 1.
The flow at a glance
± 35 min totalThe minutes above are the defaults, not a script: whoever prepares the structure sets the time per step, and a step set to 0 drops out. On the requirements, the test and the improvement the screen warns first, because without those three the cycle is no longer a cycle. On top of the 30 minutes come about four to form the teams and hand out the material, and the reflection at the end. By default the board moves on your click, because a team does not stop mid-build because a clock says so.
Step-by-step instructions
8 steps
Ask your client
2 minclient at the next tableOne student from each team goes to the next team as its client, all teams at once. The team asks its guest: what must it do, and what bothers you now? Then the client goes back to their own team.
Write the requirements
2 minin the teamThe team writes two or three requirements it can test later, in the client's words. "Nice" is not a requirement; "stays up when you tap the screen" is.
Come up with ideas
3 minalone first, then the teamFirst a silent minute: everyone draws one small idea alone. Then everyone shows their idea, and nobody judges it right away.
Choose and sketch
3 minin the teamThe team chooses one idea or combines two, and makes one sketch with the requirements beside it.
Build it
8 minin the teamThe team builds to the sketch. If they go off it, they say why and change the sketch.
Test with your client
3 minclient at the next tableThe client comes back. The team predicts first: does it meet every requirement? Then the client tests it, not the team. A missed requirement is the best outcome here: now the team knows what to improve.
One improvement
4 minin the teamThe team chooses the requirement that went worst, changes one thing and tests that one thing again.
Show it
5 minthe whole classEach team shows its design beside its requirements. Everyone says one sentence: what did we change after the test?
To have every student lead a step, switch the roles on in the preparation: Designer, Builder, Tester and Presenter, the STEM role cards from the starter set. One role leads each step; the work stays the whole team's.
Which learning strategy does the class train?
Apply in a new context
Students use what they know in a situation they have not met before. That is the level a test asks at, and the level students rarely practise on their own. Source: Hattie & Donoghue (2016), the transfer phase.
On the boardUse it somewhere new · You use what you know in a situation you haven’t seen before. That’s exactly how a test asks it.
Also trainable with this structure
- Plan first · First requirements you can test, only then sketching and building.(advisory)
- Predict · Before the test you say what the client will say; after it you change exactly one thing.(natural sciences)
Why does this work?
A class designing something for the first time mostly does one thing: build. The first idea becomes the design, the design gets taped together right away, and at the end someone asks whether it looks nice. The design cycle is made of exactly the steps that get skipped. This structure makes those steps small enough to take all of them in one lesson, and three things make sure they really get taken.
In 2012 David Crismond and Robin Adams brought together the research on beginning and informed designers. Beginners treat a design task as if it were already clear and jump straight to solving it; they pay little attention to the requirements the design has to meet. That is why the design cycle used in Dutch technology education (Marja van Graft and Pierre Kemmers, 2007) puts the list of requirements first, and calls a prototype good only when it meets them. Here the requirements come from a real user: the client from the next team. That makes the questions in step 1 genuine, and turns one task into seven different designs. A requirement only counts if you can test it: "nice" is not a requirement, "it stays up with the phone in it" is.
Beginners also tend to stick with their first idea, and in a team that is usually the first idea of the quickest student. So step 3 opens with a minute in which everyone comes up with an idea alone and draws it small. Only then does everyone show their idea, without defending it, and only in step 4 does the team choose. That way the idea of the student who needs longer to think is on the table too. A good sign as you walk around: more ideas on the table than people in the team.
Before the test, the team predicts whether the thing meets every requirement. Then the client tests it, not the team: whoever built it tests it gently. The Stanford d.school's process guide says the same thing: put the prototype in the user's hands, and do not reduce testing to asking whether they like it. A requirement that is not met is the best outcome of this step, and Engineering is Elementary treats failure as a necessary part of engineering, because it invites an improvement. That improvement changes one thing and tests that one thing again. A team that rebuilds everything can no longer see what the change did, and then the class has learned a second try, not a cycle.
The client from the next team: how the swap works
In step 1 every team picks one student to be its client, and all the clients walk to the next team at the same time. So every team loses one student and gains one guest. That guest is the client the team designs for: the team asks what the thing must do and what bothers them, and writes the answers down, with no ideas yet. On the board, one figure from each team walks to the next table during this step.
After two minutes you send the clients back. For the rest of the lesson they work in their own team, until step 6: then they return to the team that designed for them and test the thing against the requirements they named themselves. If the class does not divide evenly into teams, one team is a student short, and that team still sends a client and receives one.
Being the client means missing a few minutes of your own team, twice. That is the price of a real user, and it is small. Let the teams pick their client before the clock starts, and rotate who goes next time.
With or without roles?
By default the roles are off. The first time, the class learns the cycle, and it is enough that the whole team does every step. In the setup you switch the roles on with one choice; you then use the STEM role cards from the basic kit: Designer, Builder, Tester and Presenter.
With roles on, the board says at every step who leads it. The designer leads the requirements, the ideas and the sketch, the builder leads the build and the improvement, the tester leads the test with the client, and the presenter leads the show. Nobody leads the interview: everyone asks. In a team of three, the tester also leads the show.
A role says who leads a step, not who does it alone. The board says so every time: the others join in. That is how Elizabeth Cohen and Rachel Lotan use roles in groupwork: they organize how the group works, and the task stays everyone's. A tester who tests alone while the rest watch turns the role into an excuse to sit out.
When it fits, what to watch for
When it fits
- Before a first design project. The class takes every step once in one lesson, on something small. In the project that follows, they know where the requirements go and why there is a test.
- When teams in a project go straight to building. One lesson in between, with a task that has nothing to do with the project, shows which steps they skip. The closing question, which step they nearly skipped, goes back into the project with them.
- In technology, engineering and science classes. Every design course has a design cycle, and it usually lives on a poster. Here it is walked in one lesson, and afterwards the class can point to every step.
- When the class needs to learn to design for someone else. A client who really wants something different from the team is the fastest proof that a design is not about your own taste.
- When you want to see how teams work together. Eight short steps with a clear job show who talks, who builds and who watches. With the roles on, you can ask at every step who is leading it.
What to watch for
- With a task that already states the requirements: take them out. If the sizes and functions are already in the task, nobody needs to ask the client anything and every team makes the same thing. Name only the client and what the thing does for them.
- With lots of material: give a small, equal kit. A full box invites crafting and makes the test unfair. One sheet of cardboard, tape and scissors per team is enough, because the cycle is the lesson, not the thing.
- In a room without a fixed table order: set the route. Twice, all the clients walk at once. Put on the board or on the tables who goes to whom ahead of time, or the first minute of step 1 goes to searching.
- With a class that wants to make it look good: say what the product is. Say up front that the lesson is not about the stand but about the steps toward it. In the show, every team names what it changed after the test, and that is what counts.
- With a client who likes everything: test against the requirements. A friendly client says it is fine. Have them say for each requirement whether it was met, with the phone in it or the weight on it, and not whether they like it.
In miniature first, then a real project
A design project, or an engineering design unit, runs for weeks. Each phase gets a lesson or more, and that is exactly why a class does not see the whole: by week 3 nobody remembers which requirements were written in week 1. This structure fits the whole cycle into one lesson, on a task so small that the build fits in eight minutes. The steps are the cycle's steps, only shorter.
Use it as a stepping stone: once in miniature, then the project. The reflection questions at the end (which step was hardest, which did you nearly skip?) become the agreements for the project. If the project runs over several lessons, Daily Scrum gets each team coordinated at the start of class, and halfway through, a Gallery Walk gives the teams feedback on each other's work.
What this lesson does not give is depth: there is no time to investigate materials or build a second prototype. It does not need to. What the class takes away is the order of the steps, and the experience that a test that fails moves you forward.
Examples by context
- Make your client a cardboard stand that holds the phone upright.
- Build your client a paper bridge across a 20 cm gap.
- Design your client an organizer for the things on the desk.
Variations
By age
Common mistakes
Frequently asked questions
What exactly is the Design thinking in miniature structure?
A structure in which teams of three or four walk the whole design cycle in one lesson, on a small task, for a client from the next team. Eight steps: ask your client; write the requirements; come up with ideas, alone first; choose and sketch; build it; test with your client, after a prediction; one improvement, tested again on its own; show it, beside the requirements. The structure trains the logic of the cycle. It does not replace a full design project; it prepares for one.
How long does Design thinking in miniature take?
With the default settings the whole structure takes ± 35 minutes, briefing and look-back included.
Step by step with the defaults: two minutes to ask, two for the requirements, three for ideas, three to sketch, eight to build, three to test, four for the improvement and five to show. That is 30 minutes of steps; forming the teams, handing out the material and the reflection come on top. Whoever prepares the structure sets each step, and a step set to 0 is skipped. By default the board moves on your click.
Why a client from the next team, and not the teacher or the team itself?
Because then the team really has to ask. A team designing for itself already knows the requirements, or thinks it does. A teacher as the client hears the same questions thirty times and gives the same answer thirty times, and every team ends up making the same thing. A client from the next team has wishes of their own, comes back in step 6 to test, and cannot be skipped. Because every team sends and receives a client at the same moment, no team loses more than one student.
What makes a good requirement?
One you can test later, in the client's own words. "It stays up with the phone in it" is a good requirement: the client puts the phone in and looks. "Nice" or "strong" are not requirements, because nobody can say when they are met. Ask the team about each one: how will you test that? Two or three requirements is enough; a team cannot meet more in an eight-minute build, and then the client mostly tests what is missing.
Where do you find a good task?
A good task names a client and what the thing does for them, and leaves the rest open: "Make your client a cardboard stand that holds the phone upright." It is small enough to build in eight minutes from paper, cardboard and tape. With a free account, the built-in AI suggests five tasks for your topic and grade in the setup, and you pick one. Prefer your own assistant, such as Microsoft Copilot? The prompt is ready to copy on the same screen. Or leave the field empty and name the task yourself.
What do the roles do, and when do you switch them on?
With the roles on, each role from the basic kit leads a few steps: the designer the requirements, the ideas and the sketch, the builder the build and the improvement, the tester the test, the presenter the show. Leading is not doing it alone: the rest of the team joins in, and the board says so at every step. Switch them on the second time. The first time, the class is learning the cycle, and the roles are one more thing to keep in mind.
What if a team is not finished when the build time is up?
Then the client tests what is there. A half-built thing can still meet or miss each requirement, and that is exactly what the improvement is about. That is why the board moves on your click by default: you can give a team another minute, or set the build longer in the setup. If it happens to many teams, the task is too big for eight minutes.
Does this work outside technology class?
Yes, wherever students make something for someone. In science, a parachute for an egg; in math, a box whose net is the problem; in geography, a clay levee that keeps a house dry. The steps stay the same; the task and the material change.
What is design thinking, and how does this structure relate to it?
Design thinking is a way of designing that starts with the user. The Stanford d.school describes five modes: empathize, define, ideate, prototype and test, and then around again. In this structure, empathizing is interviewing the client, defining is writing the requirements, and the improvement is the second time around. The design cycle from Dutch technology education (Van Graft and Kemmers, 2007) has the same order, with the list of requirements first. What is "in miniature" here is the time, not the logic.
Where does this structure come from?
Design thinking in miniature is a LudensFlow structure built on the design cycle used in Dutch technology education (Van Graft and Kemmers, 2007), on the Engineering is Elementary design process from the Museum of Science, Boston (ask, imagine, plan, create, improve), and on the research by Crismond and Adams (2012) into what beginning designers skip. The client who walks to the next team is the same move as in 1 goes, 3 stay: every team sends one student, all teams at once.
Working on a product together: which structure fits?
| Structure | Purpose | Group | Duration | When it fits |
|---|---|---|---|---|
| Design thinking in miniature | walk the whole design cycle once | teams of 3–4 | ± 35 min | before a design project, on a small task |
| 1 goes, 3 stay | collect what the other teams found | teams of 4 | ± 20 min | each team has something the others lack |
| Gallery Walk | collect feedback on each other's work | 2–8 teams | ± 30 min | halfway through a project or design |
| Daily Scrum | coordinate briefly at the start of a work session | teams of 2–8 | ± 7 min | a project that runs over several lessons |
| Placemat | one carried answer within a four | 4 per sheet | ± 13 min | consensus with a visible trace per group |
| Snowball (1-2-4-All) | funnel ideas from individual to plenary | 8–32 | ± 18 min | a brainstorm that must end with an ordered map |
| The worst plan | see what you're doing to yourself | alone or in groups | ± 19 min | there's resistance or entrenched behaviour |
Sources
- Marja van Graft & Pierre Kemmers, Onderzoekend en ontwerpend leren bij natuur en techniek. Basisdocument over de didactiek voor onderzoekend en ontwerpend leren in het primair onderwijs, Stichting Platform Bèta Techniek / SLO (2007): the design cycle in seven steps, with the list of requirements first and the test against it.
- Christine M. Cunningham, Engineering Is Elementary, The Bridge 39(3) (2009), 11–17, National Academy of Engineering: the five-step design process (ask, imagine, plan, create, improve) and failure as part of engineering.
- David P. Crismond & Robin S. Adams, The informed design teaching and learning matrix, Journal of Engineering Education 101(4) (2012), 738–797: what beginning designers do differently from informed designers.
- Hasso Plattner Institute of Design at Stanford (d.school), An Introduction to Design Thinking: Process Guide (2010): the five modes, and testing with the prototype in the user's hands.
- Elizabeth G. Cohen & Rachel A. Lotan, Designing Groupwork: Strategies for the Heterogeneous Classroom, 3rd ed., Teachers College Press (2014): roles that organize how a group works while the task stays everyone's.
Compiled by Oksana Oliinyk · Last updated 23 October 2026
Was this page useful?
After your answer we ask three short questions. Half a minute, and it genuinely helps us.