Business 2.0, NGOs & Nonprofits

Prototyping vs. piloting

This is a cross-posting of a post originally published on the IDX Backstage Blog.

In conversations talking about iterative approaches to projects I often make the distinction between a “pilot” and a “prototype”.

I can’t recall where I heard this, but I remember someone once saying that a “prototype” is as much about working out what doesn’t work (failing informatively, to borrow Clay Shirky’s phrase) as it is about working out what does work.

A prototype should be “light”—the minimum investment necessary to test something. It should be, conceptually, something that you’re not afraid to throw away.

The term “pilot”, on the other hand, infers something where there are a number of knowns and you’re really testing what it takes to actually run something—to take it to scale. There is a high expectation of the thing actually working. There may be more significant investment, just not to full scale. Often this may be the trigger for a summative evaluation (i.e. a stop-go decision)—making the stakes higher.

I’ve had occasion to revisit this thinking in the past few days. Both as we consider the first early prototypes of a series of workshop/event activities, and also in support of one of our Innovation Lab participants.

In the latter case, our participant is trying to understand how best to prototype an iPad app that will be used in a workshop context. There are a lot of mechanics to the workshop, and an underlying program logic (or theory of change) that needs to be tested, in addition to the app itself. So we’ve been exploring how paper prototyping tools might service the testing of this wider area of concern, before jumping too far into the development of the app.

At the same time, the IDX team has been exploring how coding and robotics workshops with primary school aged children could be of value in achieving our mission objectives. We’re looking into whether building on existing tools and approaches (MIT Scratch and FIRST LEGO League, for example) might work in our context. How we might need to adapt them. What level of interest might exist around these particular activities.

As a team we’ve been back-and-forthing about what “prototype” means in this scenario. Even running an initial workshop requires a degree of investment in hardware (computers, educational LEGO kits) that isn’t insignificant. What is the minimum investment needed, so that we can reduce the feeling that it must succeed (i.e. maintain space for informative failures).

I mapped this out on the back of a napkin this morning:

A rough mapping of prototyping through to delivery

We end up with three broad objectives for each phase: LEARN, PRACTICE, and EVOLVE. Of course, prototyping (and learning) can occur across the process, but as a broad mapping I found this useful to get an understanding in my head.

What do you think? Is this a useful distinction? Are there other definitions of these phases that provide a better understanding of when they apply?

Design

Insights into co-design

Zumio co-conspirators Penny Hagan and Natalie Rowland have just published an excellent introduction to co-design methods over at Johnny Holland: Enabling Codesign.

While I could quote some excellent points from across the whole piece, I’ll start with this introduction:

Involvement of ‘users’ early in the research and ideation phases of the design process is often equated to “asking users what they want”. (A certain quote oft attributed to Ford comes to mind). Codesign however, goes well beyond this. The premise is that ‘users’ become partners. Rather than being viewed as a source of information to be input into the design process, those impacted by the design are invited to work actively with designers to shape the definition and direction of the project. Participation can include sharing personal experiences and perspectives, contributing to the generation of new design concepts, the evolution of those concepts, analysis, interpretation, decision making, evaluation and more.

When taking a codesign approach it is our role as designers to facilitate that participation. At the beginning of the design process we work with users to understand the design project in relation to their everyday lives including their habits, rituals, dreams, attitudes and experiences. These then become resources for inspiring design concepts and direction. In order for people to actively and effectively participate in the design process they must be able to imagine, access, and express their experiences and expectations. Simply asking people questions is not enough to facilitate this process. This is because people are not explicit sources of information. As humans we are limited in what we can express by our existing frames of reference, we can only talk in the language that we know.

This (perhaps unsurprisingly) reflects Zumio’s approach, and our process is strongly geared towards enabling this type of participation. Penny’s and Natalie’s article does a great job at providing some insight into the thinking behind some of the methods we employ to achieve this goal. Congrats (and thanks) to Penny and Natalie for producing yet another great resource for the UX/service design community…