We talk a lot about prototypes in innovation–rapid prototyping, experience prototyping, visual prototypes, and many others. But the more meaningful conversation revolves around how we actually use those prototypes as a learning tool to quickly get information.
We often create a ‘primitive form’ of something, just to get it out of our heads and actually “experience” it. Bringing an idea or sketch into the three dimensional world changes it. The key is to find out how it changes and to do so sooner rather than later.
You can prototype just about anything. In most cases, you can make a first attempt at a product using whatever you have laying around. At Bright Innovation, we have a giant trunk of LEGOs that has really come in handy when we’re working on ideas. Creating something you can tear down and recreate in seconds is powerful not to mention fun.
We conduct a workshop that requires attendees to prototype a flashlight for a randomly-chosen user. We have a kit of parts that are completely covered in Velcro. That way, the parts can be rapidly put together and pulled apart in infinite variations.
We never know what that thing will be before they create it. They pass it around. They move parts. They pull pieces from it and replace them. They create in real time.
A prototype doesn’t have to be a “thing.” It can also be a service or a process. You can mock up a McDonald’s drive-through, a doctor’s office–you can even have people fill the role of devices.
During a recent project, we were working with a company that was investigating wearable computing for nurses. We wanted to identify the tasks the nurses would feel comfortable letting this new device assist them with and the tasks they would prefer to keep for themselves.
Building a functional prototype would have been incredibly expensive and very time-consuming. We discussed some workarounds that involved walkie talkies and other technical solutions.
In the end, we made a person their ‘assistant’ and ran through a simulated, scripted shift. The assistant performed all of the functions that we expected the new wearable computer to perform. The assistant kept track of the same things the device would and performed the same tasks.
This prototype taught us a lot about how those functions lived within the nurses’ job. We learned they weren’t comfortable having an ‘assistant’ do some tasks for them. On the flip side, we also learned they were thrilled with shedding some of their other responsibilities.
Most importantly we learned a ton about the potential of the device without ever engaging a developer or engineer.
Instead of jumping straight to ‘How should we do this?’ we started first with ‘Should we do this?’ then moved to ‘How much of this should we do?’ and finally ‘How do we do it?’
By understanding the user and their context through simple prototypes, we kept the company from marshaling too many resources, too soon.