At the Heart of Prototyping – The Experiment
Prototyping has been a hot topic for many years now. Unfortunately, its popularity has also created a lot of confusion. To some, it means something so specific they miss the beauty of its broadness, while to others, its vagueness is the cause of their problems. The mere definition can get in the way of the concept’s usefulness. But what if I told you prototyping was the same as designing and running an experiment? If that were the case how would you or your organization use it then?
How does it fit in?
Eric Ries, the author of “The Lean Startup”, defines prototyping as:
“The smallest amount of work necessary to start the process of learning – a time to first learning.”
He adds some context:
“Once you form a hypothesis about what’s going to happen in the world, the key idea is to put it to the test ASAP. To gain a validation if your hypothesis is correct or incorrect.”
Eric’s definition tells us that prototyping’s magic comes from forming thoughtful hypotheses and designing powerful experiments that test the hypotheses of interest, in the smallest amount of work possible. It is this process that allows experimenters to learn as fast as they can. Who wouldn’t want to adopt it?
And we see it everywhere. We see it when design researchers create interactive questionnaires to help them test their hypothesis of a user need. We see it when engineers create a “works-like” model to test their hypothesis of a system design. We see it when designers create preliminary foam models to test their hypothesis of a user interaction. And we see it when business designers create business models to test their hypothesis of a profitable business.
In these cases, the role of a prototype, the thing, is to help facilitate an experiment that is testing the assumption/question (the experimenter’s running hypothesis). These critical assumptions/questions are born out of what the experimenter is trying to learn. You can imagine how engineers working on a new technology have very different learning goals than a team of graphic designers working on a software interface.
In search for those that have done it well, I’ve found examples to come back to when you’ve found your team going through the motions –
Learning the value of a product/service concept
THE HYPOTHESIS: Consumers will buy shoes online
Before setting up distribution warehouses, inventory management and hiring a room full of people. Zappos felt that they had to answer one critical question – will people buy shoes online? One proof point was that consumers were buying more and more shoes from catalogs. But that wasn’t enough. The founder’s decided to set up an experiment. They bought a domain, went to a shoe store, took a picture of the shoes on the wall, posted the picture on their very rough website, put some labels on pricing and added a “click to buy” option. Every time someone bought a shoe, the founders went to the same shoe store where they took a picture, bought that shoe, packaged it and sent it off. Their rudimentary website was a cheap prototype built to test the core assumption on which their business would be built.
Learning about product tradeoffs
COMPANY: OSTER Cordless A6 clippers
THE HYPOTHESIS: Pet groomers are more sensitive to clipper battery life than clipper weight.
Oster sought to bring a new battery-powered pet grooming clipper to market The company was lucky, they knew who their user was and those users were accessible. The stakeholder’s assumption was that battery life was king – groomers wanted a clipper that could last the whole day. But battery life has a tradeoff: bigger batteries added weight. Our team at Altitude explored this tradeoff by running an experiment. We attached a variety of battery capacities to the clippers and had the groomers use them. After a few weeks of observation and interviews, we quickly figured out that comfort was king. A simple experiment disproved an assumption that would have led to a potentially poorer design decision.
Learning about interface design details
COMPANY: Thermo Fisher Scientific
THE HYPOTHESIS: First responders wearing hazmat suits would be able to read the screen.
Sometimes assumptions are so ingrained into a design process, you don’t even know you are making them. When designing a hand-held analyzer for use by first-responders, our team at Altitude felt that, in the vein of a good UI (or user interface), the best color layout was a white background with black lettering. But when we built paper-based prototypes and tested them in the user’s environment (including suiting up in hazmat suits on a 90 degree summer day), we quickly found out that the masks made the text unreadable. This discovery led us to conduct additional prototype-based experiments to hone in on the right UI design (white on black) contributing to a better user experience and a successful product.
I wonder if more effective use of prototyping could have helped companies avoid some big failures. Would Keurig Kold have been successful if they designed experiments to test the assumption that people would pay more for a home-made soda than for one they could get in a can? Would they have launched knowing this information?
Help me as I try my own experiment. Share with others that at the heart of prototyping is an experiment that tests a question you have about the world you’re in. Share with them that they may use a prototype, a thing, to help conduct it. Observe the results and let me know if framing it this way does or doesn’t help individuals or organizations use it more effectively.