Notes on prototyping

The majority of my working days for the past 5+ years have been filled with building front-end prototypes.

In this post, I’d like to extol the many virtues of prototypes and some observations on the process.

I’m not a fan of prescriptive advice on the web, but I’m going to stick my neck out here with the assertion that if you are working on a project of any real size, and not prototyping, you’re doing it wrong.

Prototype or proof of concept

There is an important distinction to make up-front. That is the distinction between a ‘prototype’ and a ‘proof of concept’.

The definition of ‘prototype’ on my system dictionary:

a first or preliminary version of a device or vehicle from which other forms are developed: the firm is testing a prototype of the weapon.

Compare this to the definition of ‘proof of concept’:

evidence, typically deriving from an experiment or pilot project, which demonstrates that a design concept, business proposal, etc. is feasible: the company was awarded the contract on the strength of evaluation, proof of concept, and budget | [as modifier] : proof of concept trials | [count noun] : as a proof of concept, he set up the system to monitor Twitter for specific hashtags.

From the front-end web development perspective, I would make the distinction thus.

A prototype is a visually and interactively correct implementation of a design idea made with the technologies it will ultimately be delivered in.

Whereas:

A proof of concept is evidence, in whatever technical form, to suggest the intended design goal may be feasible. However far-reaching a proof of concept, if not made in the technologies the design should ultimately be delivered in, it does not quality as a prototype.

Consider yourself designing a web-based weather application. In my terms, creating something to show going from a summary to detail view, created with a tool like Framer or Principle is a proof of concept.

Creating that same interactivity with HTML, CSS, SVG and JavaScript would be a prototype, regardless of whether or not the application is actually wired up to any real weather data.

Why prototype

I believe creating prototypes of intended functionality offers the greatest information to cost ratio when compared to any other deliverable, prior to sending the actual ‘thing’ into the wild.

If skipping a prototype, flat designs of intended functionality, however well-considered and aesthetically pleasing can ultimately be exposed as flawed when seen living and breathing in hand.

That’s not to say that by prototyping you can always skip design or proof of concept; sometimes they are essential pre-cursors to a prototype. However, nothing else can confirm categorically whether or not a new feature/product/amendment actually works.

Being able to get to the end of any potential product blind alleys quicker is a time and therefore cost saving to all. A prototype allows testing to complete satisfaction and fidelity the intended feature in advance.

If you end up prototyping 3 or 4 versions of a feature only to discover none of them are quite right, congratulate yourself and your co-workers. You have just saved countless hours of other developer work and a likely risible experience for your users. The comparative cost of one or two developers fully prototyping a feature is a pittance compared to mobilising whole departments and organisations into action creating a fundamentally flawed new feature.

A prototype is the design and development equivalent to a war game as opposed to risking lives in a real war.

Speed vs accuracy

The line to walk when prototyping features for your product is weighing up speed against accuracy.

When I talk to designers, they are often of the opinion that the fidelity of the prototype is very important in determining whether something is actually working or not. I typically agree.

Some problems reveal themselves very early, when fidelity is lower, others take longer and subsequently higher fidelity to expose.

When there are competing solutions to explore it is often essential to ‘get to the end’ of each as a fully realised and full-fidelity prototype before weighing each up against the other. I have lost count of the amount of times, elements of an abortive but fully realised prototype have been key ingredients in a new solution, often the hybrid of two or more separate previous approaches. Seeing those failed attempts in their full glory allowed the cherry-picking of their positive attributes.

Producing something of high fidelity, perfectly matching any flat designs, runs counter to the notion of creating something quickly. The challenge for the prototyper is therefore how to cut corners that don’t impact the fidelity of the prototype.

My go-to list:

Ignore the functionality of any unrelated UI

Working on a feature related to your main navigation? Perhaps it is a floating action button that makes a radial menu appear. This is the area you are testing. You probably don’t need to build in the functionality of what the other buttons of the nav do. Ignore them. This category of choices are also covered in the section on remit below.

Mock-up data

Whilst occasionally beneficial, hooking a prototype up to live APIs can be fraught and introduces another vector for failure. Unless you absolutely have to use real data, mock-up server responses and data using JSON or JavaScript objects.

Ignore contexts until you can’t ignore them

If the main audience for your intended feature is mobile, don’t concern yourself with how this version will work/look on large screens at the outset. Conversely, if you’re making a dashboard for a primarily desktop audience, confine your prototype to figuring out that problem before concerning yourself with small screens.
At some point, when a prototype has answered all other questions you can turn your attentions to the areas you ignored.

The remit of a prototype

The remit of a prototype can, and almost always does change in relation to how successful it is. It is however, very useful for the prototyper to get a solid steer from relevant parties on what the remit of the prototype is at each stage. This ensures no-one is surprised or disappointed.

This doesn’t need to be a big hullabaloo; just a simple agreement and list of things to hold on to. This isn’t just to safeguard the prototyper from scope-creep, it is just as useful to pull the prototyper out of the weeds when they find themselves 2 days into writing a touch controls library that they probably don’t need to be writing given the remit.

If you are the person to be building prototypes, know this. Things will change. This is the whole point of prototyping. The rubber will hit the road and then hit the road again in a different way — ad infinitum. This is the very nature of prototyping. Your job is to facilitate this as quickly and easily as possible.

Facilitating change

If you are not already intimately familiar with Git, it’s time to get familiar. You will often find yourself hitting philosophical forks in the road. Two or more possibilities that require exploration in a prototype. Be disciplined in stopping at that point and branching.

Truthfully, occasionally I still find myself heading down a fork before realising I should have forked. But the sooner you, dear reader, can prevent yourself doing so, the easier your prototyping life will be.

Tangentially related, another discipline to master is to ensure work on that branch only facilitates investigation of the subject the branch was created to explore. Start fixing aesthetic things common to more than one branch and things will end badly when you come to discard the current branch. Easier said than done, I know.

Ultimately, whatever work and procedures you can put in place that will facilitate you being able to simply and rapidly adapt to change will serve you well.

What a prototype should do and what it shouldn’t

Earlier I stated that I believed a prototype should be, “… a visually and interactively correct implementation of a design idea, made with the technologies it will ultimately be delivered in.”

With this in mind, it is for the prototyper to decide how to facilitate that. If meeting that objective is best served with a library such as Ember, Vue or React then fine. However, I would typically caution to introduce such complexity only if absolutely necessary. Can you achieve the same goal quicker and just as maintain-ably with vanilla HTML, CSS and JavaScript?

An eye on production; strong opinions, loosely held

Depending upon how involved the prototyper will be in the eventual development of the final solution will likely inform how they author the prototype code. If any of the prototype code can be written in such a way as to be transferable to production environments, so much the better. However, I would discourage being to prescriptive about intended implementations.

For example, I always write my CSS using ECSS as it is highly transferable and no greater effort to author than any other CSS methodology. However I make no attempt to make interactivity in JavaScript compatible with production as there are likely a billion considerations in that world that would stunt prototyping flexibility and speed.

My current stance is that if the feature, once complete and delivered to the world, looks and behaves exactly the final prototype — I couldn’t give a monkeys how it was coded! As a prototyper, i.e. someone not building the feature in production, it is probable you lack the context to fully understand all choices and considerations of that arena. Therefore, try not to be prescriptive about ‘how the sausage is made’.

Temper that with the fact that if the final result is lacking compared to the prototype, when it could equalled it had they followed your approach, the developer in responsible needs their head wobbling.

More on prototyping

Contractually I’m not able to disclose details ans specifics of the nature of the prototypes I work on day-to-day.

However, if you want any further evidence and background of prototyping and its importance in product development, I’d refer you to ‘Creative Selection’ by Ken Kocienda, which is an inside account of Apple’s creative process. It includes plenty of great anecdotes and evidence as to the efficacy of prototyping (demo’s in their parlance).

Summary

In web front-end, prototypes are the gold standard for proving the validity of a new feature.

• Prototypes should be made from the same technologies the eventual solution will be delivered in. Otherwise, they are merely a proof of concept.
• Time spent exploring feature ideas as prototypes pays for itself 10x.
• Prototypes avoid the expensive development time of fundamentally flawed features and implementations.
• Working on prototypes requires developers happy to be constantly making and throwing away code. Happy to change course as required and happy to create a development environment that facilitates that need.
• Introduce complexity to prototype environments only if needed
• A prototype shouldn’t be prescriptive about the production implementation, unless the production implementation stands to be inferior from the users perspective to the prototype.
• Prototypes often need following through to complete fidelity before they can be categorically dismissed.
• Keep fidelity high but scope low. Mock data, ignore unrelated UI and contexts.