Sunday 7 April 2013

Why Prototype

Tom Chi worked on the Google Glass project, he set the scene in the session at Mind the Product by talking about the pitfalls that befell the virtual reality headsets of the 90s. You simply could not wear the devices for any length of time, besides being bulky the weight was all distributed on the front of the face. Fifteen years on you could say, 'we can make them smaller and lighter today' but that betrays the discovery Tom and the team made with their prototype, which included the equivalent weight in components, electronics still have a finite weight which makes your nose ache! It was the rapid prototyping that taught the team to put the electronics behind the ear which mean that the ear could act like a fulcrum and lift the weight off the nose! If they had learnt that in the 90s, the larger components would not have been a problem.

Having come from a manufacturing engineering background myself, and spent many hours building prototypes out of all types of materials what he said about the benefits of prototyping resonated with me (how cool is 3D printing). You cannot justify tooling up a factory to build a product if you haven't prototyped it, proved it works and more importantly shown you can build it. The process of prototyping helps you uncover how it should be manufactured. In the world of software engineering prototyping is often frowned upon or simply overlooked because it is all bits and bytes which appear to be 'free'. You will hear teams say 'oh we'll just rewrite it', 'tweak it to work', 'it will take too much time to build, we may as well build the real thing', 'something for version x'. We'll explore why the time to build statement is flawed in the next blog post. But the costs of getting it wrong in software can be just as high; the launch fails, it does not do what they need, the product is too complicated, it is not performant, it lacks some core functionality or customers try and use it differently. Why wait until release day to find out what you have built the wrong thing, why spend more time building in complexity to handle ambiguity when a simpler product actually meets the needs of the customer.

The objective of prototyping is to learn what works and what doesn’t, for software this can be what types of interaction works, what questions you ask when interacting with the user, understanding how they use it, what short cuts they take and most importantly do they love it. The prototype can stop you going too far with an idea only to find out customers can’t or won’t use it. If you understand how people want to use the product it stops you projecting how you think it should be used on the customer and shows you what options and functionality are really important. The result you can build a far more elegant solution, with a far simpler data model at the back end. Why? The complexity that normally gets built in with the ‘what ifs’, ‘we may need this’, ‘but what if they want to do’ has eliminated. Simpler data models are more efficient, require less computation the result a faster leaner product that may even be brought to market sooner.

No comments:

Post a Comment