Unfortunately, a lot of people in our industry underestimate the power of prototyping – if you want a good example let’s just take a quick look at the death star; brilliant in concept, but what about that thermal exhaust port – a classic interaction design flaw and probably based on a conversation along the lines of “Well, they’ll never spot that, especially if we don’t bring any attention to it, like popping lots of extra guns around it”.

Famous last words.

If only they had built a prototype and performed some basic x-wing fighter user testing beforehand, things might have turned out very differently for the old empire..

But in all seriousness, why on Alderaan do we bother to prototype? It costs money, takes valuable time away from project delivery and ultimately will just get trashed at the end.

To answer this question, let’s first take a look at a new system going into play without a prototype phase; we have our scamps, wireframes, designs, entity relationship diagrams, functional, non-functional and technical specifications, schemas, user flows and a whole load of other documentation, depending on which methodology we are using. Good golly, it’s a vast library of documentation, surely that has to be enough? And the answer, in many cases such as fairly static web propositions, would be a resounding yes.

Where this model falls down is on interaction, and any system that relies on human computer interaction to complete complex processes needs a human to test that interactive process.

Prototyping provides us with many insights for any project, by collating our thoughts and processes into a solution structure we suddenly experience clarity in the flow of the design as well as discovery of the flaws and points of pain in the various journeys that will be experienced by using it. We start to see where questions will arise and this allows us to address any stumbling blocks within the context of our flow.

One example of this was with a project I joined where they were building an e-commerce process flow and about to go into production and I asked the lead developer what would happen if a visitor experienced a momentary hesitation dilemma and hit the back button on their browser just prior to purchase. The answer should have been along the lines that the system would maintain state, bring the visitor into the CRM flow and try to address the reason for the hesitation with access to peer reviews and FAQ’s. The answer I actually received, after a swift huddle of technical brilliance, was that system would break and probably end up with a 500 error state due to the e-commerce implementation. My point here is that by never investing in actual human testing, they were blindly following a process chart without taking into account the core humanity of the end user.

We should never lose focus of the fact that the end solution of your project is not for your personal use, it’s not being driven by the business and their goals, even though they exist and must be followed. At the end of the day there will be a real human being whose tech saviness may vary from jedi master all the way down to a brand new clone asking us how to use the mouse (and yes, I have seen that one before in research. Several times) As a consequence, the sooner we put some real crash test dummies into the driving seat we will not be able to understand how the solution drives. (Or indeed if it will crash and burn)

As for the cost of doing this research – yes, of course you can hire specialist consultancies to do it all for you; develop the personas for you, let another agency recruit your victims, write the scripts, conduct the interviews and pay off the “volunteers”, usually at around 20K a pop for a really fancy report with lots of pretty graphs and videos.

This has been known to make more than the occasional stakeholder gulp and lose much of the blood supply to their head.

As a much simpler alternative, why not take your prototype down to your local Costa and buy a few free cappuccinos and go pure guerrilla UX, it’s not as fancy as doing it full on, but you will still end up with invaluable research findings.

Another solution is to create your own UX testing centre, it doesn’t cost an asteroid and all you really need is a room, a camera, someone vaguely empathic and good at interviewing and a few bits of software for aspects like screen capture, heat map etc.

Let’s look briefly at the flip-side for a moment and imagine the cost of taking a project through development without prototyping and then deployed. Suddenly, you realise that the model doesn’t work and is essentially unusable, your first indication of this will probably be the marketing department screaming down one end of the phone about conversion and retention numbers heading for the deepest darkest basement.

By this point in the game any realistic fix is probably months away, requiring a brand new code release as opposed to some simple fixes which you could achieve with some A/B testing.

This scenario is usually frightening enough that pointing out the reality of not going ahead with user testing on prototypes as a risk exercise can quite often provide the clarity and will needed to open up the purse strings a bit.

Finally, if you have been fortunate enough to be able to observe user research prototype testing first hand through one of those cool one way mirrors (yes, we do pull faces at them) then you will understand how powerful this method of research can be, provided you have enough of a sample and that your sample is representative of your target personas.

It’s quite an astonishing experience watching actual visitors stumbling over your brilliantly intuitive design and navigation, throwing their hands in the air when they come to a complete standstill in your fluid data flow and completely missing the emphatic calls to action you have placed with such loving care and diligence.

If you have an opportunity to do so, I would highly recommend visiting these sessions, in fact I would go one step further and recommend everyone in your team has a chance to go, PM’s, designers and techies.  Not only is it a complete education to see how people react to and use systems, it is incredibly insightful in helping you to design and build better interactive systems.

What technology should we use and what’s all this nonsense about hi-fi and lo-fi? This question seems to crop up almost daily in the various UX forums out there and the answer is whichever one works best for you, your budget and for the intended audience. In the past I have used a variety of prototyping technologies in different scenarios – low fidelity (low-fi) for basic scamps and annotated wireframes using tools like Balsamiq, Omnigraffle and Visio, to slightly more interactive wireframes with basic behaviours and clickthroughs with Axure and then going a step further with technology like flash and AIR to rapidly create higher fidelity (hi-fi) prototypes for multiple devices which range from simple clickthroughs to fully functional solutions that emulate HTML/javascript as well as backend functionality but at a 20th of the time cost.

The thing is, if you’re expecting your visitor to start using gestures or use multi touch on their devices, then a clickthrough is just not going to cut it. Equally, aspects like on-boarding and applying gamification to systems should be completed in high fidelity in order to judge real reactions.

For the business process and requirements gathering we will usually stay at a low-fi level to ensure that the basic data capture, journeys and delivery methods are in place and to ensure essential navigation is functional and intuitive. Paper prototyping can be very effective and cheap here, as long as it is FAST.

More advanced prototyping with software like Axure can be used to provide a more holistic low-fi system experience and can also then be used as an evolutionary stage toward design with basic capture of interaction and behaviours. One possible benefit of the Axure model is that you can add a lot more information into the model and even create an initial functional spec directly from the export – but that also assumes the person making the prototype has the skills to enter that information.

When it comes to testing a new product on the public though, experience has shown us that low-fi just doesn’t cut it. The impact of a design on functionality is a make it or break it game plan and there is just no way to predict which way it will go, hence low-fi prototyping will not provide the required insight without the impact of skinning a design on to the solution. At the end of the day a failure can be based on something as simple as the colour and placement of a call to action. Many UX bods out there will rave and rant about their preferred level of fidelity, the vast majority opting for a low-fi solution.

SO, what kind of effort will this nonsense take? The answer leads us back to that wonderful dimensionless piece of string and this in turn can be a real drawback to selling the idea of prototyping and, indeed, UX research in general. Your estimates need to be accurate in UX, the client doesn’t really want to pay for any of it, most likely, and so the worst possible outcome would be to go over budget on time or cost.

Time-boxing your efforts – This is a classic pitfall area in a lot of prototype development and really it comes down to what you are trying to achieve and for whom. Many UI developers will just not be able to “let it lie”, constantly tweaking and adding to the prototype and losing focus on the fact that it isn’t meant to be a final solution, instead, it’s meant to be a flawed representation and its power comes from the speed and hence low cost – and any functionality it does have is designed for testing.

In the cases where your audience attempts to stray from this allotted test path during research, a simple “These are not the processes you are looking for!” and a wave of the hand will usually work and allow you to shift their focus back.

As a general rule, I will have a very clear plan of what a prototype must demonstrate, usually from workshops developing scamps or wireframes, as well as the intended audience and how long I have to create it before touching any code at all. This will be driven by the business needs and the required interaction level.

Whilst developing the prototype, try to spiral in towards your solution, in classic rapid prototyping methodology we start at the outer edge of the spiral and head inwards. If our prototype was an oil painting, we would begin with enormous brush strokes to bring the canvas together, gradually bringing more and more detail to the picture.

Typically, this translates as overall page hierarchy and navigation, to page details and down to interaction levels of forms and widgets and then to final design considerations. If you are lucky enough to have access to a good designer you should be able to create a simple click-through prototype of pages within a few hours.

Another option could be to build an evolutionary prototype, which will be continuously enhanced until we get a final solution – this can work very well for mobile apps with small teams running in an agile environment, but falters somewhat for larger scale projects. The technology used for this will evolve into the final solution so more care is required and a lot more time needed to get this off the ground.

And prototyping doesn’t just stop with UX; not only is it a brilliant tool for client presentation and pitch work, it is also the best way to learn new technology and to get something working. I make sure I have at least an hour or two of playtime every week in order to look at new tech and trends in the development world and try out any wacky ideas I might have had in the framework of a solution. Again, by time-boxing my efforts, I can usually get a small example or a widget fully working within a small amount of time. Very often it is the many acts of failure that helps us to learn and understand new technology. Edison put it best when he said “I have not failed. I’ve just found 10,000 ways that won’t work”

And so at the end of the day our advice is this: don’t build a death star without testing it, prototype fast and furious within your budget and time frames and to the required audience. Most importantly, remember not to laugh/cheer/cry too loudly behind the one way mirrors during user research testing as they are never sound proofed as much as you would like them to be.