Design Concepts wins GOOD DESIGN Award for its work on Pelvalon's Eclipse System

The value of low fidelity rapid prototyping...

October 28, 2013

We’re teaching a class on innovation and product design at the University of Wisconsin this semester – it’s been a ball and it’s been an honor to follow up on the work of Dr. Frank Fronzak — a great professor who influenced so many students and retired earlier this year.

We’re at the point in the class where we’re talking about the value of rapid prototyping and today’s lecture was low-fidelity prototyping. The basic premise we’re trying to teach the students is that certain problems require deep analysis, planning and design – and others are best solved by rolling up your sleeves and starting the build stuff — even simple stuff that can demonstrate a point or explore an issue.

To demonstrate this, we tried a fun in-class experiment. We divided the class into teams each of which was given an identical set of tools –

Each team was also given three sheets of foam core, three sheets of poster board and a bag containing an identical hodge-podge of parts, rubber bands, paper clips, screws, etc.

The design challenge was simple — within the class period each team had to design and build a device that would hurl a ping-pong ball the greatest possible distance. Here was the catch.

One third of the teams were not allowed to do any sketching whatsoever and consequently begin prototyping immediately.

The second 1/3rd of the teams was given 30 minutes where they could only sketch and design. They were not allowed to open or touch their prototyping materials during this period of time. Once that 30 minutes expired, they were free to begin prototyping for the next 30 minutes.

The final group of teams was forced to only sketch and design for 45 minutes, leaving them only the final 15 minutes to build.

Certain problems require deep analysis, planning and design – and others are best solved by rolling up your sleeves and starting the build stuff.

I honestly wasn't sure how this was going to go. I really though the teams with the best shot at winning would be in the first group - the one that was allowed to use the entire time for prototyping. I was guessing that this was the type of problem that specifically lent itself to experimentation - more than planning and conceptualizing. Apparently I was wrong.

  The teams with the best performance came from the middle group — the one that was given half the time for sketching before being allowed to prototype. The teams that weren't allowed to   sketch actually finished last.

  Of course this test was utterly unscientific - there was a very   small sample size and the results could easily have been due to   random chance, group assignments or other aspects not   related to the constraints. Never the less I found them pretty   interesting.

   

Based on my observations while walking around and   eavesdropping - the groups that could begin brainstorming   immediately but could not sketch seemed a bit disorganized and lost. During the class we've really stressed sketching as a tool for brainstorming and it appears that once stripped of that tool the teams struggled to share ideas, build upon each other's   ideas and develop any momentum towards a clean design solution. What was particularly interesting was that there was   nothing to prevent them from trying to use simple discussions and verbal collaboration to do their design planning - but absent the ability to sketch the team's approaches to their design solutions appeared haphazard and somewhat scattered.

  In contrast, as you might expect the teams that were given only 15 minutes to build their prototype had the most organized design approach but simply didn't have enough time to refine or iterate on their solutions. I think if I had given them only 5 or 10 more minutes some of them would have dramatically improved their results with a few minor tweaks to their prototypes - but they just didn't have enough time to do even modest revisions.

Of course this is a pretty specific problem and it would be dangerous and faulty to try to extend these results more broadly but from an educational perspective they do make sort of a nice point. In general, my experience has been that most engineers wait far too long to begin prototyping — putting a premium on analytical work or design optimization — only to be tripped up by mistakes that could have been spotted with simple prototype. Conversely, a cut-and-try-only approach often fails to capitalize on the learning that a organized effort involving planning, analysis and collaboration can yield. In this example, as well as most innovation challenges, a balance between design and prototyping seems to yield the most powerful results.

I'd love to see some other people repeat this exercise and see if they get the same results. If you'd like here is a LINK to the class notes. If you try it on your own please let me know how it goes for you!