Part 2: Why is a Raven Like a Writing Desk? PrD and Rapid Prototyping

Published on

by Leo Frishberg.

Tenniel drawing of Alice with Hatter and Hare

In this and several other posts, we address a corollary to Lewis Carroll’s famous riddle. In our case: “Why isn’t Presumptive Design like                                  ?” In this post we tackle the comparison between Presumptive Design and Rapid Prototyping.

See these posts for other comparisons.

Rapid prototyping, paper prototyping and junk prototyping are all methods of quickly sketching the team’s ideas to get them out into the world. Bill Buxton’s excellent book, Sketching User Experiences, and more relevantly the accompanying workbook, illustrates the rationale behind quickly sketching our ideas. Carolyn Smith’s book, Paper Prototyping, as well as Jonathan Arnowitz, et. al.’s Effective Prototyping provide step-by-step recipes for capturing user feedback on a roughed-out design.

These, and numerous other excellent books on prototyping, all validate the practice of rapidly capturing our ideas to get them in front of our users. At first glance, it appears that PrD is merely another form of rapid prototyping, but that is not the case.

Why PrD is not like Rapid Prototyping

While it is true that PrD depends on rapidly sketching out an artifact, the similarities end there. Buxton, Smith and others all point to the creation of prototypes to:

  • Quickly capture the team’s ideas about the solution
  • Receive critique about the solution from end-users

In contrast, PrD creates artifacts to:

  • Quickly capture the team’s assumptions about the problem
  • Receive critique on those assumptions by the end-users

Artifacts differ from Prototypes in three distinct ways.

Artifacts are not Prototypes

In our experience, the word “prototyping” no longer means a single thing, but is used (often indiscriminately) to mean: an early stage concept, working code, a physical object and more. Proponents of Lean UX suggest there is only prototyping: as the project moves forward the prototype becomes the deliverable. Jared Spool suggests the word artifact be used instead of deliverables or prototypes. We agree. Introducing the term artifact into the process eliminates the confusion around the word prototype, allowing the team to explore a much broader set of offerings.

This is important because PrD focuses not on the end solution, but rather on the team’s belief and assumptions about an end solution. Often the artifact will be a representation of a possible solution, but it needn’t be. Using the term artifact instead of prototype gives the team permission to consider wildly different types of objects (or even non-objects).

Solution vs. Assumptions

When the team captures its beliefs and assumptions and expresses them as a physical thing they are engaged in a completely different process from crafting a prototype. For example, in a typical prototyping session, the team might discuss and design a screen layout, considering what elements should be available and where to put them. In PrD, the team will argue about the need for the screen at all, and once agreed, to capture only the essence of why it is necessary, with the barest indication of screen elements.

These differences (though they sound subtle) drive completely different conversations, both internally and with end users. In the case of the prototype, users will engage in a functional task by navigating through the interface to reach a goal. In the case of the artifact, however, users may be stumped by what the team is trying to communicate, and that confusion may be exactly what the team needs to understand.

Image of an ambiguous interface

Refinement vs. Context

Which leads to the third distinction between prototyping and PrD artifacts: the purpose of the conversation. By requiring the team to create an artifact that embodies its assumptions, PrD enables conversations with end users about the problem the team is trying to solve, not any specific solution.

Does this mean that a prototype can’t be used as a PrD artifact? Of course not! We have used existing prototypes to great effect to test the team’s assumptions. We’re very careful to keep the user focused on the underlying assumption, and not let the prototype’s elements distract us. The conversations in these cases don’t sound anything like those in which the prototype is used to test a solution. In PrD, when a user focuses on an element in the prototype, the facilitator may redirect the discussion to a broader, more fundamental question: why is that element of interest at all? Rather than refining the task (as testing a prototype may be designed to do), the method investigates what is important about the context.

Because PrD is focused on the broader questions of context (and the problem space), the team is free to craft a much rougher and less resolved object, hence our agreement with Spool. And as we have suggested throughout the book and these blog entries, the artifact may be completely unrelated to an imagined solution at all.

The one attribute common among prototyping methods is the speed with which the team creates its offering. But even on this dimension, PrD is different. PrD works best when the artifact is not highly resolved, but rather, remains ambiguous. As a result, teams create artifacts far more quickly than they would prototypes. Because the object is an artifact, and not a prototype of the solution, the team is liberated to offer all sorts of things (an object, a prototypical solution, or even an comedy sketch), as long as it enables the right sort of conversation with end users.

Contact us to learn learn more about crafting artifacts instead of prototypes to accelerate the process of defining your problem space, or buy the book!