We do quite a bit of prototyping at Clearleft. There’s no better way to reduce risk than to get something in front of users as quickly as possible to test whether you’re on the right track or not.
As Benjamin said in the podcast episode on prototyping: It’s something to look at, something to prod. Ideally, you’re trying to work out what works and what doesn’t.
Sometimes the prototype is mocked up in Figma. Preferably it’s built-in code — HTML, CSS, and JavaScript. Having a prototype built in the materials of the medium helps establish a plausible suspension of disbelief during testing.
Also, as Trys said in that same podcast episode: Prototypical code isn’t production code. It’s quick and it’s often a little bit dirty and it’s not really fit for purpose in that final deliverable. But it’s also there to be inspiring and to gather a team and show that something is possible.
I can’t reiterate that enough: prototype code isn’t production code.
I’ve written about the two different mindsets before:
So these two kinds of work require very different attitudes. For production work, quality is key. For prototyping, making something quickly is what matters.
Addy recently wrote an excellent blog post on the topic of prototyping. The value of a prototype is in the insight it imparts, not the code.
It’s crucial to remember that in a prototype, the code serves merely as a medium — a way to facilitate understanding. It’s a means to an end, not the end itself. The code of a prototype is disposable and mutable. In contrast, the lessons learned from a prototype, and the insights gained from user interaction and feedback, are far more durable and impactful.
This!
It can be tempting to reuse code from a prototype. I get it. It seems like a waste to throw away code and build something from scratch. But trust me — and I speak from experience here — it will take more time to wrangle prototype code into something that’s production-ready.
The problem is that quality is often invisible. Think about semantics, performance, security, privacy, and accessibility. Those matter — for production code — but they’re under the surface. For someone who doesn’t understand the importance of those hidden qualities a prototype that looks like it works seems ready to ship. It’s understandable that they’d baulk at the idea of just throwing that code away and writing new code. Sometimes the suspension of disbelief that a prototype is aiming for works too well.
As is so often the case, this isn’t a technical problem. It’s a communication issue.
This was originally published on my own site — Jeremy Keith — Clearleft Cofounder.
