This is the first half of my summary for the book “Prototyping” by Todd Zaki Warfel. See my review of the book in Goodreads (one-sentence summary of the review: “a tad disappointing”). It will cover the first three chapters, “The Value of Prototyping”, “The Prototyping Process” and “Five Types of Prototypes”. The second half will cover the guiding principles for prototyping, tools and how to test your prototype.

EDIT: see also the second part.

Value of prototyping

A prototype is a representative model or simulation of the final system, which goes beyond show & tell and let you experience the design: if a picture is worth 1,000 words, a prototype is worth 10,000. As the complexity of a system increases, the cost-to-benefit ratio of prototyping increases dramatically. Some technical requirements can’t be captured in a prototype, but a short and simple supplemental document can cover them. Also, it often takes less effort to produce a prototype than to create a detailed specification document + annotated wireframes. Disadvantages of specification documents:

  • Nobody wants to read a 60-200 page document.
  • If you can’t get them to read it, you won’t get them to fully understand it.
  • It hides the big picture.
  • Words leave too much room for interpretation.
  • They don’t encourage play (which prototypes do), which makes people understand the system better.

[There are some notes about experiences with prototypes, which I didn’t find that convincing. In summary, prototypes are much better and cost less effort to make than (lengthy) documents, at least for the initial understanding of the system before it’s built. —Esteban]


It’s commonplace in architecture and industrial design, why not in software engineering? Process in a nutshell is (1) Sketching, (2) Presentation and Critique, (3) Modelling/prototyping and (4) Testing. Sketching is present through the whole process.


The goal is generating many different concepts and put them on some tangible format. The point is not fleshing out the ideas fully, we’ll refine later. It’s a good idea to limit the sketching time to, say, 10-30 minutes. [Unfortunately, there are many things that aren’t clear to me after reading this part: who is part of the sketching process? Is it a meeting? Is there anyone looking while someone else sketches? If so, who? How many people sketch, and many many sketches do we produce concurrently? —Esteban]

Presentation and critique

The goal is to find the best ideas. This step if focused on quality, and it’s arguably the most important step in the prototyping process. You present the strengths of your sketch, and your peers highlight the parts that need more work or clarification. Guidelines:

  • Keep it short: around three minutes for presentation and two for critique.
  • Focus presentations on the strongest parts: If you need more than three minutes to present your sketch, there’s probably something wrong with it.
  • Critiques mention both good and bad sides: mention two or three things that are good, and one or two to improve.
  • Take notes: it’s best to take the notes on the sketch itself.


After the last step, you’re left with the strongest concepts. These are the ones you’re going to prototype. Always consider the following: (1) use a tool/medium you’re comfortable with; (2) make sure you have the ability to communicate effectively with the audience or consumer; (3) consider how much time you have; (4) consider the level of fidelity you need. Once you have a prototype, run the presentation and critique again, but with longer times. Tip: if you project your prototype on a whiteboard, you can take notes on that whiteboard easily.


Testing can be done in two different ways: with clients and with end-customers. When testing with clients, run a presentation and critique for 1.5-3 hours, but instead of making a list of revisions, simply sketch the changes. This makes everyone walk away from the meeting being on the same page. At the end of the session, the client gets a copy of the prototype to play with. After two or three days they typically come back with some more feedback.

Testing with end-customers it a standard usability test, with 8-12 participants, 5-6 scenarios, audio-video capture, analysis and reporting of the results afterwards.

Types of prototypes

[I don’t even know why this chapter is called “types of”. They feel more like “uses of” to me —Esteban]

  • Shared communication. Get a designer and a developer to sketch ideas together. Benefits: it opens the line of communication between developers and designers, it teaches them how to communicate with one another, and it builds relationships. It’s a great team-building exercise. Tip: record a video of yourself using the prototype.
  • Working through a design. If you are going to make a big redesign, you need to test it first, explore the different possibilities, work through them, test them and refine them.
  • Selling your idea internally. Prototypes work as a tool to sell the feasibility and value of your idea.
  • Usability testing. A prototype allows you make usability tests and do data-driven decisions.
  • Gauging technical feasibility and value. Simulations are good to get both managements and engineering to buy into concepts and prove if it can be built.

And this is the end of the first half of my summary. I’ll post the second half soon.