I've written before about making things rough before making them better: a paper sketch, a cardboard mock-up, a clickable prototype, a trial run for a week. All of that advice usually comes from software. But the same instinct applies just as much when the prototype has wires in it instead of pixels.
Lotto Machine and Drum Machine are both hardware projects. Neither one taught me anything new about design thinking. What they did was prove that the lesson doesn't care what it's built out of.
A prototype has exactly one job: answer a question you don't know the answer to yet. It doesn't need to look finished to do that. It needs to be cheap enough that you're not precious about it, and real enough that trying it actually teaches you something. Cardboard, a Figma frame, and a breadboard covered in jumper wires are the same tool wearing different materials.
Somewhere along the way, hardware got treated like the exception, as if it has to be finished before it counts, because it took a soldering iron instead of a design tool. It doesn't. A breadboard is a wireframe. Loose wires are duct tape holding a hypothesis together long enough to test it.
Lotto Machine could have been a much more complicated build. A real slot machine reads its own results: sensors, a microcontroller judging the match, a screen showing a winner. None of that got built, and none of it needed to. The actual question was whether a button press and a light-and-sound cue could turn a passing visitor into a real conversation with the people running the booth. Answering that question needed three people, three boxes, and a couple of ESP32s flashing lights on cue. It didn't need automated judging. A human calling the match, live, in front of the visitor, was not a shortcut. It was the whole point.
Building the sensor version first would have been solving a problem nobody asked about, before finding out if the actual idea, a shared moment between a stranger and a presenter, worked at all.
Drum Machine is where this gets less comfortable, because it's not done. It's a breadboard and a lot of loose wires sitting on a desk, and the honest label on it is “work in progress.” But the actual hard part already works, end to end: twelve pads, debounced and mapped to General MIDI, talking to GarageBand wirelessly over Bluetooth with no cable at all.
None of the enclosure, the mounted pads, or the thing that makes it look like a finished instrument instead of a science fair project was the risky part. The risky part was whether Bluetooth MIDI to GarageBand would actually work cleanly enough to play in real time. That part got proven first, on a breadboard, because that's the order that actually de-risks a project: solve the thing you're not sure about, then spend the enclosure-and-polish effort on something you already know works.
A rough web prototype is easy to keep private. It lives in a Figma file until you're ready. A rough hardware prototype sits on your desk, in the room, looking unfinished to anyone who walks by. That visibility makes it tempting to hide the messy version and only show people the polished one, once it exists. I think that instinct is backwards. The messy version is the interesting part. It's proof that the actual hard question got answered before a single hour went into the parts that just make something look nice.
The wires are not a sign the work isn't real yet. Most of the time, they're a sign you already tested the part that mattered. Fun, by design.
