What I talk about when I talk about prototyping

We spend a lot of time sketching ideas at Made by Many. It's a powerful way to bring ideas to life quickly; to give them an identity and test with an objective audience.

To minimise our investment in any one idea, we use familiar, malleable tools - paper or Keynote usually win over - prototyping with the tools of production would come with too many engineering overheads, right?

We take an approach akin to scientific research to guide our product evolution: selecting an idea from a wall of post-it notes, prototyping and testing it, then discarding the prototype when the hypothesis is proven null.

It works, assuming we don't slide into inaction due to not being able to decide which idea to test, or are pushed there by Too Many Ideas during validation.

Action through identity

Allow, for a moment, the assertion* that prototyping with code - in an age which enjoys the fruits of our fore-fathers abstractions - allows us to go from hunch to testable object with as little investment as producing a throw-away, intrinsically less 'real', prototype using a different medium.

As Theseus's paradox explores the identity of objects which have had all of their component parts replaced (can the resulting object lay claim to the identity of the original?) could we, without ever throwing our prototypes away, scrapping the identity, losing momentum and succumbing to inaction due to indecision, instead start with a prototype after minimal validation of the axiom and rapidly evolve into something no one could have envisioned around the idea wall?

When a prototype is given its own identity, decoupled from any individual idea, will everyone feel they have played a part in its evolution?

Will it democratise the process while allowing us to test with a prototype which feels as real to a user as a the final product?

* Measure once, cut several times

To explore this, the fundamental question that needs to be answered is: how can we lower the barriers which make us reluctant to code our hunches? How much of the production code rule book do we throw away?

How do we create a code environment which is equally forgiving of shortcuts and sticking plaster, while maintaining it's adaptability?

As a start, here are a few things we've learned by experimenting this way:

Make more, but with less

Use standards-based development and favour libraries over rolling your own.

Be smart about being lazy.

Accept inefficiencies in the code

...in favour of efficiency in the speed which you can change it.

Bloat is fine, so long as it comes abstracted – hidden away in a library – and can be extricated quickly.

Cut out as much transactional overhead as possible.

Do as much work as you can in the code - sit down together with designers, copy writers and other members of the team to take their ideas straight to code.

Questions conventions

For example:

Avoid branding your prototype; continually seeking sign-off will kill momentum,

Avoid non-standard interactions unless vital to the experience you're testing; do you really need that AJAX'd modal window?

Support only a small set of modern browsers, set expectations accordingly - things may not be perfect for all users,

Avoid designed layout items that are not flexible and quick to replicate (i.e. use standard form elements),

Design for the device set you'll be testing on; there's no need to go out-all responsive,

Avoid tools that will need to be reverse engineered, or entirely rewritten at some point simply in order to save a few hours at the start (Oh hai, Bootstrap…).