Proto-what?

Have you ever wondered what "prototype" means?  I have.  Increasingly so.  It is one of those words that the Hub uses a lot, and, the more I hear it, the more interested I become to find out what it means to others and how our understandings differ.  I feel that some similar words—beta, pilot, mock-up, template, framework, sample, example—get used somewhat interchangeably.  These words swirl in and out of our Hub conversations, and I increasingly realize that I mix them all into one big cloud related to the idea of “prototyping”.

Having worked with people with very little design experience as well as those who are design veterans, I feel that people’s understandings of prototyping varies quite a bit.  It really depends on which similar word one quickly associates with "prototype".  On one end of the spectrum (let’s say the “mock-up” end), a prototype is not functional and is only a shell of the idea—as simple as an “app” drawn out on a piece of paper.  On the other end (the “beta” end), it is an “app” that we are already using with only minor adjustments occurring—like Google and Apple pretty much always have their software in the “beta” version.  Neither of these interpretations is wrong, but they are significantly different.  One is a lot of work away from being implementable, while the other is already functional with only small adjustments remaining—yet both could be easily classified as “prototypes”.          

Screen Shot 2016-03-22 at 10.27.28 AM.png

Varying interpretations are good, but I wonder how this affects our teams entering the prototyping step of the design thinking process.  Based on one’s interpretation, expectations for the prototype could vary widely.  In one case, one has to be “creative” enough to make a quick and easy version—knowing that it will get a lot of criticism and may not meaningfully deliver right away.  In another, one thinks the prototype needs to basically be a completed product.  Both scenarios can be quite intimidating.  So how does one approach it?

To give a long winded answer… As I have spent time in the Hub, I think that we use the word “prototype” to mean anything that represents our interpretation of a solution.  I think the key feature is that we are showing something to the end-user, as opposed to asking the end-user to share their general experiences with us.  We are bringing our idea to them.  Thus, in my mind, the first prototype should just be enough that I can get my idea across—it should take almost no time at all to create.  From there, continued iterations of the prototype will start to reflect the increasing depth of conversations with end-users.  The more things sound right, the further the prototype will naturally build from the rough mock-up, to the pilot, to the beta, etc.  So to answer the question above, the prototype should begin at that earliest of levels, just a representation of the idea.  In some cases, building it to beta will be quick and easy, but in others it will take longer.  Either way, start with that quick and easy version—it will save you a lot of effort.        

Screen Shot 2016-03-22 at 10.39.18 AM.png

Prototyping may be the hardest step of the design process.  Part of that may be attributed to a fear of the perceived scope of this step—again the blurred lines between a mock-up vs. a framework, an example vs. a pilot, a beta vs. a template, etc.  Another part could be attributed to the fear of putting ones own ideas out there instead of just being a listener.  I try (still working on it) to see it a third way. 

I try to view prototyping as the point where I can finally join the end-user in a conversation addressing their challenge, as opposed to simply listening.  Their role in the conversation is to continue to guide my ideas down the right path, while mine is to continue translating their guidance into potential solutions.  Whether they know it or not, the end-user lives with the challenge everyday, and prototyping is where we can finally sit down and say “let’s start to solve this together”.

IMG_2938.JPG

Andrew Yin

Please email SibleyHub@jhmi.edu to share your feedback, experiences, feelings, comments, or ideas.  Also, send an email if you want to join our feedback team and are willing to be interviewed for our future projects!