The question this lesson answers
How do I find out whether an idea works before I spend two months on it?
The gap between having an idea and having something real is where most projects die. This lesson is about crossing it fast and cheaply — and it contains the most uncomfortable instruction in the course.
The commonest mistake is to treat a prototype as a miniature of the final thing. It is not. A prototype is an object built to answer one specific question you cannot answer by thinking.
The discipline is to name the question first. Will people understand what this is within five seconds? Does the community recognise itself in this imagery? Does the variation read as meaningful? Each needs a completely different prototype, and building the wrong one wastes weeks.
Then build the least amount of thing that could answer it. If a paper sketch answers the question, do not build a website. The value of a prototype is information per hour spent, and that ratio is highest at the crude end.
There is a second, quieter benefit. A rough prototype invites criticism; a polished one suppresses it. Show someone a hand-drawn sketch and they tell you what is wrong. Show them a beautifully finished mock-up and they assume the decisions are settled and say "looks great." Roughness is a permission structure.
Level 1 — Words. A concept paragraph. A fake announcement for something that does not exist. Cost: thirty minutes. Answers: is this legible? Does it interest anyone?
Level 2 — Paper. Sketches, storyboards, cut-out cards on a table. Cost: an afternoon. Answers: does the sequence make sense? What is structurally missing?
Level 3 — Mock-up. Real-looking visuals with fake content — three sample pieces made properly while the rest stay imaginary. Cost: a few days. Answers: does it feel credible?
Level 4 — Working slice. A genuinely functional but tiny version. Cost: a week or two. Answers: does the mechanism work, and where does it break?
Move up a level only when the current one has answered its question. Most projects jump straight to level 4 because it feels like real progress — then discover a level-1 problem, that nobody understood the premise, after two months of building.
Try this — The paper prototype (45 minutes, on your own)
No software required. Take the concept you wrote in Lesson 4.
1.Cut six cards from paper. Each is one piece from an imagined collection.
2.On the front, sketch the artwork — badly is fine, this is not a drawing test.
3.On the back, write the piece's title, its three characteristics and what each one means, and one sentence of its story.
4.Make the six deliberately different: two common, three uncommon, one rare. Make the rarity mean something.
5.Lay all six on a table and look at them together. Do they read as one family? Is the system visible from the set alone?
Then hand them to someone — a friend, a relative, a colleague — without explaining anything, and watch which card they pick up first and what they say. That reaction is real data, and it cost you six pieces of paper.
Most feedback conversations are worthless because the questions are wrong. "Do you like it?" and "would you buy this?" both produce answers shaped by the desire not to hurt you.
And when they misunderstand something, resist the urge to explain. Write it down instead. The misunderstanding is the finding.
You will almost certainly use AI tools at some point. That is fine, and it needs to be deliberate rather than accidental.
Where AI genuinely helps. Generating twenty variations to react against. Getting past a blank page. Visualising a concept before committing effort. Drafting text you then rewrite. Explaining an unfamiliar tool. Letting someone who cannot draw contribute visual ideas.
Where it causes problems. It flattens toward the average of what it has seen — the opposite of what distinctive work needs. It reproduces the biases in its training data, which matters enormously when depicting a marginalised community. It can produce work resembling a specific artist's without anyone intending it. And it removes the struggle in which learning would have happened.
Four decisions worth making explicitly, and writing down:
One test to keep: can you explain how this came to exist? If not, you have produced something rather than made something.
Make it disposable. If you cannot throw it away, you will defend it — and defending is the opposite of learning.
Separate the maker from the made. When someone criticises a prototype, they are criticising an object on a table, not you. Easier to say than to feel, and worth practising deliberately — it is the same muscle Module 2 develops under the name resilience.
Ship the embarrassing version. Every experienced maker says the same thing: the version they were embarrassed to show taught them more than the one they polished for another three months. Embarrassment usually means something real is being exposed to reality, which is the entire point.
Looking ahead — in an Innovation Lab
This is where Lab teams most often struggle. Concepts meet execution, some members find they cannot make what they imagined, and motivation drops. Teams that expected this handle it; teams that read it as failure fall apart.
The most useful thing you can be in that week is the person who shows their rough version first. Everyone is embarrassed at the same time, which is exactly what makes it safe — and whoever goes first gets days of useful input while everyone else is still polishing privately.
Make the six paper cards, show them to at least two people without explaining, and record exactly what they did and said. Then write your personal AI-use policy in four sentences.