Prototyping is the process

MVC-049X

If you google "design thinking process", you'll be presented with a series of diagrams or lists or steps which, in a linear fashion, purport to represent the way a good designer works.  They'll often look something like this:

  1. Understand
  2. Observe
  3. Ideate
  4. Prototype
  5. Test
  6. … and cycle back to Step 1

We're all familiar with cooking manuals, and this one feels not unlike a good recipe for chocolate chip cookies… first this, then that, and then do this.  Easy, safe, predictable, comfortable. 

Except, that's not the way designing really happens.  There is no six-step process to design nirvana.  It doesn't exist.  Over the years I've tolerated and communicated this linear portrayal of the design process because it's an easy way to explain the gist of things to folks not familiar with the art and science of bringing new stuff to life.  The secret is that, when you're designing, it feels like all of these at once.  So I used to draw this linear process up on a wall, and then wave my hands in the air and say something like "But really, it's a big furball… when you're really doing it, you're bouncing all over the place and the steps don't matter." 

I think we can do better than that.  And now I know how.

A wise colleague recently corrected me on all of this.  "Prototyping isn't a step in the process," he said.  "It is the process." 

Exactly.  Designers are always prototyping, whether it's moving things around in their imagination, building a reverse income statement in Excel, or hacking something out of wood using a sidewalk as sandpaper.  The notion that a designer waits until it's "prototyping time" to start messing around with stuff is just wrong.  Prototyping starts when the design process begins, and it never stops.  We build to understand.  We observe for generative insight but we also observe to gather data regarding the hack we just whipped up ten minutes ago.  We ideate with our gut and our hands as much as with our brains.

We prototype all the time.  We must prototype all the time.  Prototyping is the process.

6 thoughts on “Prototyping is the process

  1. This is absolutely right! Lately I read a story where sombody stated: I do not follow a process, I’m in a cloud of activities…
    Managers should trust people over processes, and create some space for creativity and failure. That was one of the reasons to start my blog: http://www.r2xp.wordpress.com
    Perry

  2. I couldn’t agree more with you Diego. Prototyping is a mix of art and science. If you are dealing with services and experiences, I’d argue it is more art than science, and as such, it can get a bit messy and fuzzy.
    I’ve been a Service Design consultant for 9 years now, and I still find it quite challenging to get clients to adopt this ‘prototyping mindset’.
    Funny enough, from a clients’ point of view, the idea of prototyping as a process can be quite paradoxical: on one hand it’s about reducing risks, on the other, however, it can make them feel that the process is quite risky – as it’s not often linear and structured.
    My take is that it requires a lot of expectation management and reassuring – which sometimes mean that we need to demonstrate we are using a structured process (as you argued in your post), but in the background you are playing with all these ideas. It’s like the duck swimming idea: calm on the surface, [organised] chaos beneath…
    Erick Mohr
    @erickmohr

  3. I disagree and I will tell you why. I’ve been trying to visualize a process similar to a cooking recipe for a long time, no success so far. But that doesn’t mean it cannot be done. And while I agree that there are many different activities and they are not always linear and certainly not always applied in the same order, there might be ‘multiple’ cooking recipes that describe the whole.
    For example, a redesign of an existing app calls for different set of methods as a proposal or a project with clearly defined requirements. In yet another case the exact same pre-conditions might have you attack the beast very differently based on team structure & capabilities, budget, goals, economy, etc.
    In summary, there are plenty of ways of doing it and to experts it becomes a furball. To non-experts it becomes non-understandable – and that’s why we try to generalize and explain in simple words.
    Cheers, Mike

  4. yes, i am totally agree with you as whenever we start working on a project or a problem we first try to understand what the project/problem truly says and while doing this we simultaneously start to ideate about the project /problem and building a virtual prototype in our mind. so, obviosly it is not a linear process.

Comments are closed.