The advent of design thinking is really shaking up the whole concept of prototyping solutions. I’m not going to go into too much detail on the ideology, there are hundreds of articles available on the subject, but just to set the scene, if I were to to sum up design thinking, I would say that it’s about chasing the best possible solution towards its full potential through a series of tangible iterations; ideating, building and testing with each step you take, inside a collaborative multi-skilled team. It’s about innovation through action and empathy with your users and stakeholders.

Now, on the surface, you may be forgiven for thinking that all of those words don’t sound too dissimilar from your old way of doing things, with just a little bit more marketing speak.

And, to be honest, it’s not a terribly new thing. Back in the 90’s we used to call the process rapid application development, building user-centric interactive products in brief iterative sprints, spiralling in from concept to prototype and then to product. Of course we didn’t really have the notion of visual design back then and we didn’t use words like empathy, even if we did employ them.

But let’s get back to this idea of design thinking. Previously, the design phase followed the strategic, business analysis and user experience discovery phases, in a well trodden linear project path. It was mostly just a case of managing a few client approval iterations on the visual interpretation of the experience design.

This new paradigm has snatched our entire group of rugged T-shaped individuals out of their safe little cubicles sitting in a line and sat them together at a round table as a single team (*1), working in one collaborative iterative design phase. The primary goal now is to create tangible assets to throw to the lions, sorry, customers, again and again, in order to ensure we have the right solutions to the right problems, before we move into full product development.

Now, before I start getting hate mail from irate designers, I should add that the above way of working is quite specific to a type of digital project. Your standard flat visual design project without any serious interaction can still work quite happily in the old way. The main reason to include prototyping is to test how real users interact with technology within the user journey.


Let’s start at the beginning and have a look at what exactly this thing called prototype really is? A simple explanation is that the prototype is a tangible asset which has been developed to a defined level of completeness to allow observation of stakeholders and customers interacting with it. In English, we build some toys so we can watch how the kids play with them.

Traditionally, the prototype has always fallen into two categories of fidelity or completeness, high and low. In reality, however, there have always been three different categories of fidelity; low, medium and high.

I know! Shocking stuff. Nobody ever mentioned any medium fidelity before. So why don’t we take a moment and examine all three.

Firstly, we have low fidelity prototypes: No big surprises here, we have the usual suspects; paper prototypes, lolly pop stick models, storyboards, flip charts, index card stories, image click through (slideshows). They come in many shapes and sizes and use technology like .. well, paper, but also simple digital technology, like a slideshow using frameworks such as Bootstrap and even Powerpoint. This level of fidelity is mostlyquick and cheap which is excellent for fast iterations.

Next, we have medium fidelity prototypes: This supposed new kid on the block is probably where you previously thought high fidelity was sitting. The simple truth is that it never was. Medium fidelity prototypes have only a limited interactivity model. They might have buttons, forms and fields, they might even click through simple journeys based on calls to action and simple user driven events, but they are not designed to mimic real solutions. The technology used here are some of the new prototyping toys on the block, software like Flinto or Axure – where you ‘fake’ code, using an abstracting graphical user interface, creating a series of event based actions to power the navigation of the user through simple journey screens and changeable asset incarnations. To prototype to this fidelity costs much more than the low version, it takes more time and will usually require specific and significant software pseudo-coding skills as well as licensing costs.

I have to admit, I’m not a huge fan of this level. Many attempt to create high fidelity prototypes using these tools. The resulting models include unrealistic transitions and interactions and they create false expectations of flow and performance. As these interfaces become more and more complex, so too does the pseudo-code behind them, and the model quickly becomes unwieldy and cannot be maintained. They can be useful, if kept simple, as a bridging mechanism between designers and stakeholders to promote a shared understanding, I’ve also seen some of these models used to create annotated wireframes to assist with the design to development transition.

Finally, we come to high fidelity prototypes – this level of prototyping reflects a state of realism that, when tested with a user, will provide an environment from which they will be able to make an honest and meaningful response to the product. Let’s re-read that sentence, it’s worth it. To create a responsive environment which is realistic enough to allow us to capture honest responses through interaction.

And when I say real – I am talking about realistic transitions, native mobile considerations, network lag and download/upload time, video play options, lack of connectivity, zooming, scrolling, gestures, heavy data computations. It’s no good creating a high fidelity experience if it’s not as close to real as possible, you might just as well stick to paper prototyping as your results will be just as unreliable as if you had created a low/medium fidelity prototype [Think Keanu Reeves practising Kung-Fu as a cartoon rabbit]

Just a very quick aside, when I mention the term responsive, commonly referred to as responsive web design, I am not describing what probably 99.94% of the rest of the digital world think I am. In truth, this deserves it’s own full article, but to summarise: Responsive design for me encompasses not only a visual response of fitting content to devices and their screen breakpoints, but more importantly it also means looking at the content, interaction and the journeys we provide for each digital touch point. Users will have different expectations and needs for a service depending on how, when and where they are experiencing it. Nuff said! Back to the prototypes.

In my experience true high fidelity prototyping is very rare in organisations, mainly because it implies a significant extra cost in time, skills and money, which, when compared to simply using design resources, makes a compelling budgetary argument against hifi. And let’s not forget you will also need to find, retain and have access to that skilled individual to do the building. Prototyping is a distinct skill (*2), it is not just any old developer who happens to have some free time.


Where were we? Ah yes. To reiterate, if you do NOT prototype to high fidelity, then user testing an interactive assets, e.g. a multi-touch control, cannot produce realistic user responses as it will rely on the users imagination to fill in the interaction experience blanks.

Let’s look at a couple of examples: Firstly, imagine a user testing scenario for a mobile app, where you have our lovely dial on the mobile touchscreen. Test users are instructed to interact with this dial. The expected result is that the app will react to their manipulation by providing different system options. Even if you are using pixel perfect visual design, if that dial does not spin and rotate, allowing users to multi-touch and maybe even produce click sounds, then you are asking the now rather disappointed users to bridge this journey concept gap with their imagination.

Was the drag experience too quick? Did the dial move too fast? Was the friction too high? Did the dial not connect to the options they wanted? Were the onscreen instructions not sufficiently detailed to help the users with the dial? Was the interaction and the resulting system actions intuitive and enjoyable?

Without high fidelity all of these questions can never be asked. More importantly, if there is an interaction which is considered critical to the user journey, then unless it is truly tested there is no way to determine if the users interaction might result in catastrophic failure.

Another example? OK. This time, let’s take our test subject and tell him he’s sitting in a fine dining establishment. Let’s give him a large glass sundae dish and a long silver spoon. Now place an unopened Tesco value choc ice into this glass, add squirty cream and top your creation off with a glacier cherry. Let’s start the script, describe for them the taste, aroma and texture of a slice of the richest black forest gateaux ever made; fresh juicy Morello cherries in a thick intoxicating kirsch sauce, rich deep chocolate flavours from the light-as-air sponge, still slightly warm from the oven, mixed with the crunch of wafer thin Belgian milk chocolate smothered in thick Cornish cream and a smooth chocolate fondant that can have only been made by angels. Describe how the flavours merge and then separate again and …. hang on, your test user has just left your imaginary shop in search of a slice of real cake. The choc-ice has melted and the squirty cream has drowned the cherry.

If you’re still reading this, and not out there hunting cake, let’s sum up high fidelity prototyping. It can be expensive, it requires a high level of development skill and it is not going to be the speediest of options. This level of complexity can also produce a risk of software failure, which would never occur in lower fidelity levels, possibly requiring a qualified testing resource. But …

What you will have to decide is if the cost of going into production without user testing to high fidelity is worth the risk of later needing a software update.

Wait! That sounded far too trivial. Let’s clarify, you have deployed a product and suddenly realise you have failed to achieve your business goals. You need to find out why and fix it. So you start to user test with the product (by definition this is high fidelity), you then redefine the application journeys, redesign, and then start another full development and deploy cycle, hopefully with the same team to prevent steep learning curves from hampering your dev cycle, but if not, at least you have all of that amazing documentation to help your new team out [ironic giggle]. Not only are your time to market timelines out by the time required for this new phase, but, if you think about it, they are also out by the time taken by the original development cycle. Even if you have been slightly sensible in deploying a pilot programme, you are still going to incur a significantly greater cost by having to restart the process.

So, no, not really all that trivial.

And let’s also not forget that if we are talking about apps here, then you typically only ever get one shot at acquisition/conversion for a customer, you will rarely get them to try you again.


It’s called evolutionary prototyping and it’s a planned project methodology that maintains the current product phase and level of completeness within the evolving prototype, almost like designing an MVP product road map. The benefits are that the development team can build this in a truly agile way. Another is that complex prototype code is (mostly) never wasted. User testing can also be incorporated into the agile project sprint model. The down side is that the full development team is usually too expensive to place into an iterative groundhog day loop. One area where this model works quite well is with small teams creating new concepts or startups, allowing products to be created, tested and brought to market fast. But you are going to need some serious no-jibber-jabber, A-team grade T-shaped people in your team.


Overall, I don’t personally believe there are any set in stone ways of deciding which fidelity to use or when and how to use them, but my personal preference would be to use a low fidelity approach for proofs of concept, low/medium level for internal feature brainstorming or for use as a communications bridge between design and development [annotated wireframes]. And then I would use high fidelity in product user testing as well as for the power sell – i.e. when you want to wow and amaze stakeholders, in order to push acceptance in product presentations, providing them with a functioning, tangible asset full of smooth transitions, micro-interactions and real people following real journeys generating real data.

I want to make this completely clear, I am not proposing that all prototypes should be built to high fidelity. Prototypes need to be developed to the fidelity required for their defined purpose within the agreed upon time and cost constraints for the project or presentation. There are a multitude of cases where low and medium fidelity are not only viable, but would be the preferred medium, especially within a fast moving, iterative design thinking phase where you want to be able to add, remove and amend options quickly.

As a final thought, I will make one firm prediction: The days of taking a faulty design into full product development are coming to an end.

Just a few asides from above:

*1: One of the biggest challenges for many organisations will be to get this team of strategy, UX, BA, IxD, visual and product design individuals to work together effectively as a collaborative unit. That’s a log of ego simmering in the same pot. The situation probably calls for a special new design scrum master type role to be created, let’s call him …. the groundhog !

*2: Prototyping is a distinct skill. It is not classic development, rather it is a marriage of concept design with extreme programming, requiring many years of experience across user interface (HTML/CSS/JS/AS3) as well as networking and server side coding (.NET/PHP), data manipulation (SQL/JS/PHP) and data storage (SQLite/MYSQL/XML/JSON), motion and game design is a definite plus (API’s / Frameworks). If we include native mobile prototypes into this mix then our prototype resource will also need to have skills with a hybrid mobile deployment framework, I use Adobe AIR, but there are many others. As for the coding required, it’s fast and it’s dirty and it will require a thick skin when it comes to the hack and slash of features, and that last alone will eliminate a vast majority of classic developers. I also predict that the prototyper role described above will be needed more and more in organisations as we move forwards.