background image


Prototype Pondering

Posted by: Tristan Plank | Posted on: October 25th, 2012

Prototyping seems to be one of those words that evokes vastly different ideas and imagery in people’s heads depending on their industry and experience. Though the word has now become commonplace for me as a student in a Human Centered Design & Engineering program, the concept of prototyping hasn’t always been clear to me. Before wandering into the design and development realm, I can recall past instances in which the word elicited images of cars carved out of clay and secret iPhones that only Jony Ive has clearance to carry. Back then, a prototype was something that designers and engineers spent hundreds of hours on, and, if it was good enough, they tweaked a couple things and then they released it. And indeed, this still can be the very life cycle of some prototypes. But it was not until I started learning more about the process of designing interfaces and applications (especially while maintaining a human centered design process) that I came to understand the enormous variety of steps and actions that qualify as prototyping. I recall the first time I tried to wrap my head around the notion that a few lines on a piece of paper can be just as much a prototype as a disguised iPhone found in a bar.

Some things that used to pop into my head when I would hear the the word “prototyping”

All of this “prototype pondering” was sparked as I read an article comparing a prototyping tool called DEMAIS (Designing Multimedia Applications with Interactive Storyboards) with other prototyping methods. “Are Informal Tools Better? Comparing DEMAIS, Pencil and Paper, and Authorware for Early Multimedia Design” by Brian Bailey of the University of Illinois and Joseph Konstan of the University of Minnesota is a good read for anyone with an interest in debating the varying ways that low-fidelity prototypes are created and defined. The abstract is as follows:

DEMAIS is an informal design tool that we claim helps a multimedia designer explore and communicate temporal and interactive (behavioral) design ideas better than existing tools. This paper seeks to empirically validate our claim. We report on an evaluation comparing DEMAIS to pencil and paper and Authorware for the exploration and communication of behavior in early multimedia design. The main results are that (i) DEMAIS was better than Authorware for both exploring and communicating behavior, (ii) DEMAIS was better than pencil and paper for communicating behavior, and (iii) DEMAIS was able to capture most of a designer’s behavioral design ideas. Our results show that DEMAIS bridges the early investment/communication gap that exists among current multimedia design tools.

A few things really caught my eye and made me want to dig deeper as I read this abstract. While their first claim (“DEMAIS was better than Authorware for both exploring and communicating behavior”) didn’t surprise me, given the context of this paper is prototyping and not programming interactions. I found the second and third claims more interesting, though. “DEMAIS was better than pencil and paper for communicating behavior” seemed a bit vague, but I thought to myself, “hey, who couldn’t use a little more help communicating?” And “DEMAIS was able to capture most of a designer’s behavior design ideas,” which sounded only slightly less vague, didn’t sound like terrible thing either – a tool that is as effective as paper and pencil AND can capture most of my ideas for the behavior of an interface? Worth a read.

I continued on to the introduction, which further piqued my interest by stating that low-fidelity prototyping tools are “ineffective for helping a designer explore and communicate behavioral design ideas while high-fidelity tools require a designer to invest too much time and effort.” Having previously experienced both of these struggles at various times, I found myself nodding at this point and pressing forward, eager to read about their supposed solution. Before I go much further, it is probably important to note the authors’ statement of what their tool is. In their own words, “DEMAIS enables a designer to quickly sketch temporal and interactive design ideas and then run the sketch to directly experience those ideas.” They go on to explain that by using this tool, a designer can do the following:

  • Sketch, annotate, and edit electronic storyboards
  • Develop voice scripts and import audio, video and image content into a storyboard
  • Sketch temporal and interactive behavior using an expressive visual sketching language
  • Run the sketched behavior

A view of a DEMAIS storyboard a multi-view of several storyboards. You can see how the storyboard on the left has four behavioral strokes, and the multi-view has three. When the design is run, the DEMAIS tool transforms the sketch into a low-fidelity, functional prototype.

This sounded simple enough, but comparing this tool to other prototyping methods really helps understand this tool’s potential and give the author’s claims some context. To compare their tool with the pencil/paper and Authorware tools, the authors asked professional designers to perform typical (i.e., what would be encountered in practice) design tasks, creating a design for each task using each of the tools. After the design session, a designer met with a “client” for three minutes to communicate the design using the artifacts created with the tool. The authors then measured each tool’s impact on the exploration and communication of behavior. I could continue on and on about the experiment set-up and design, but I will leave those details to readers. The results of the comparison between the various tools are much more interesting for me to discuss.

There were a variety of results presented in this paper, unfortunately too many to discuss every one and it’s implications. Those that were most interesting to me, however, were the post-experiment rankings of exploration of behavior, communication of behavior, and creativity for the various tools. Notably, the Authorware was ranked last in ALL of these categories – a testament, perhaps, the importance of rough and quick prototypes to the creative design and communication processes. The authors state this importance beautifully, as they reflect on the results, remarking, “designers spent too much time working with the tool and not enough time exploring design ideas.” This is a great nugget of information for any designer that tends to want to jump straight in to Photoshop or other high-fidelity tools before really giving the creative process a chance to do it’s thing.

Paper prototype and an Authorware prototype from the comparison performed in the paper. Which looks more creative to you? Which would be easier to change based on feedback? Which would typically take longer to make?

I also found the following chunk very interesting: “When a designer and another person discuss a design using a low-fidelity, functional prototype, the discussion gravitates towards the behavioral aspects of the design, and when they discuss a design using static artifacts, the discussion gravitates towards the non-behavioral aspects.” Having devoted more time to static prototypes in my own professional practices, this comment really caught my attention and got me thinking. With both the behavioral and non-behavioral aspects of a design so critical, perhaps there is more of a need for the type of tool the authors are presenting here that can more effectively communicate these behavior aspects?

I feel that at the heart of all of this discussion is the communication afforded by the prototypes that each of these tools help to create – how well do the prototypes communicate the intended features, functions, and behavior? How much time will be spent with each iteration of a design to explain what does what, and what tools can be used to increase the efficiency and effectiveness of this communication? And, with an ever-growing variety of tools for designers to pick from, how do we navigate to those best suited for our particular task at hand? These are the questions I must unfortunately leave you with. The DEMAIS tool presented in this paper seems to introduce an effective method for communicating behavior in a prototype while maintaining the low-fidelity constraints, but how do tools like this fit into the overall design process, which can often be already limited by time and competing tools?

So many tools, so little time. Which ones do we use, and when? Why?