Every so often another article appears somewhere advocating creating prototypes by coding. There are many drawbacks in doing that, not the least of which is simply wasted time–time spent dorking around with code that would be better spent evaluating, iterating, and synthesizing design ideas. In response to one such article, I penned “Yes, Ditch Traditional Wireframes, But Not for Code” that goes over the various drawbacks.
Prototyping is Hard
I suspect part of the reason people want to jump into code is potentially a misunderstanding about what a prototype needs to be. Many people, when you say “prototype” think something like a near full-on app simulation, they worry about whether or not it is responsive, or at least, there is some latent idea that it is time consuming and involved. This does not have to be the case, and in fact, I would suggest that it is not good if that is the case, for the most common prototyping needs–the ones that enable you to explore interaction designs and find the best.
Prototyping Tools Are Hard
Another part of the problem, related to the weighty idea, is that most prototyping tools are themselves time consuming to learn and use, even if you don’t want to build a particularly deep, complex prototype. That is a core problem we have tried to address with Indigo Studio; we focused on the idea of sketching prototypes, that is, to make creating a prototype as easy and simple as sketching out ideas on paper/whiteboard (and even faster than that).
You’re Just Biased
Now, some have said, “Ambrose, you only advocate code-free prototyping because you have a vested interest in hawking Indigo Studio.” Well, leaving aside that this would be an ad hominem fallacy, I will first point out that Indigo Studio v1 is totally free of charge, and that you can keep it forever–you never have to upgrade. Everything I advocate for is essentially contained in the free version, so I have little to gain. I am also not saying Indigo Studio is your only code-free option; I just happen to think it is the best. 
Second, I invite anyone to spend the amount of time it takes to become effectively familiar with any code-based prototyping framework. Then spend the same amount of time familiarizing yourself with Indigo Studio. I kid! You need spend nowhere near that much time to become effective with Indigo!
And once you are passingly capable with both tools, do a head-to-head challenge, starting from zero. I guarantee that in the time it takes you to just get a project environment set up with your favorite prototyping framework, you will already have created a working prototype in Indigo. It’s just that fast and easy.
Nope. It Really is More Efficient and Effective for Design Exploration
What I’m saying is that, essentially, by any objective measure, it will be faster to create prototypes that are good enough for evaluation in a tool like Indigo. Not only that, Indigo helps keep you from being unnecessarily distracted with unimportant details, while coding does the opposite. Indigo also helps you stay focused on users and their concerns, while coding does the opposite.
Now granted, there are exceptional circumstances, but I’m talking about a general rule here. If nothing else, one doesn’t need to invest a lot to sketch prototypes with Indigo, so you don’t lose much if you find that for whatever reason, Indigo is not sufficing for your evaluation/design exploration. The inverse is absolutely not true with coding frameworks.
It Feels Good to Know and Do Things
Given all this, I have been thinking about why people would still cling to the idea that jumping right into a coded prototype is the best way to go, as a rule, for designing. I think at least part of it, if not a large part of it, has to do with simply feeling more knowledgeable and competent.
There is a certain satisfaction that comes with knowing arcane knowledge (like how to code)–one joins the ranks of the elite designers who can code. There is also a certain sense of accomplishment in using that knowledge, struggling with code, and coming out on top in the end (assuming you do come out on top and don’t walk away defeated). It’s like He-Man–by the power of code school, I have the powerrrr!
As someone who first learned to code and worked for years as a professional developer, and then learned to design as a professional interaction designer, I can relate. (I can also, thereby, speak from experience and not ignorance that coding prototypes is as a rule a less effective starting point for design exploration.) The challenge for those who can code is to ensure that we are making choices for what is best for the design problem at hand, and not what is best to stimulate our own sense of empowerment and accomplishment.
It can be fun to code–especially when you are new to it. It’s similar to making cookies from scratch, the way grandmama use to make them, instead of just buying the pre-made dough you just break apart. That’s fine when it’s for our own entertainment and enrichment, but when we’re being paid as professionals to be as effective and efficient as possible to design the best thing we can, we probably should think twice about taking the slow prototyping approach because we enjoy it more.
There Is Satisfaction in a Job Well Done
And that’s not to say that there is no enjoyment in using code-free tools. It’s just a different kind of enjoyment and satisfaction, one that comes from feeling more efficient and effective in solving design problems rather than coding problems.
I am not saying definitively that one should never code a prototype–far from it. But in their enthusiasm for their skills, I am concerned about this trend in the software design community to advocate coding as somehow better, more superior, or more effective in doing design work. Most of the reasons given for doing so are missing the mark for design/human concerns, all the while ignoring the many hidden drawbacks.
The rule should be to avoid coding except when you are fairly sure it is the only or most effective way to prototype your design ideas.
Anyways, zooming in I was able to see the R and W letters by the wires, so I could plug that into the compatibility checker, and voila, they said it was good, and they even give you a wiring diagram up front to show how you’ll hook it up. Pretty snazzy!
Over the years I’ve observed and participated in several discussions about what is the medium of interaction design. Full disclosure: I am not formally educated in Design–I’ve just learned from my own studies, interactions with educated designers, and working with and under designers, so take this for what it’s worth. 
