I love building prototypes. They allow me to explore and sketch ideas, test my assumptions, and try out things at an early stage to make better design decisions. Prototyping is the single best tool we have in our toolbox as designers and developers. And because anything can be a prototype, I use whatever gets the job done: Sometimes, I grab a pen and do a series of rough sketches. Sometimes, I use prototyping software like Adobe XD or ProtoPie to try out an idea for an interaction. And sometimes, I write code.
What I’ve experienced several times now, is that other team members will misunderstand this conscious decision to not write production code in a prototype. Some engineers will wonder why code prototypes were created when they can’t even reuse the code of those prototypes in production. To project managers, it sometimes feels like we are doing work twice and are wasting precious time and budget. Maybe the problem also lies in how differently designers and developers understand prototypes. Here’s Bill Buxton quoting a junior industrial designer:
Maybe that’s it: To me, a prototype is a means to an end, a rough sketch, a shitty first draft. It will probably even be thrown away once we’ve found what we were looking for. A code prototype is not a first step in the process of building the final thing, it is a tool that helps you decide whether and how you should build something in the first place.
A prototype lets us make better design decisions at any step of the process because we can see what works. And to see what works, we don’t need production-ready code. A shitty code prototype will do.