Exploring Problems through Prototypes

The Problem

Prototypes exist to help development teams answer a few questions. Is this feasible? How long might this take to develop? What pain points are there going to be? Are we on the same page with the customer? As such, code and design quality will suffer. After all, we're trying to build things fast and get answers to our questions.

In the classic book The Pragmatic Programmer, the authors suggest that certain details can be ignored including 1. Correctness, 2. Completeness, 3. Robustness, and 4. Style. However, it should be more nuanced than completely neglecting these four points. Depending on the project and the intent of the prototype, you may invest more in one of the areas.

Big problems can occur when the development team and/or customer fall in love with the prototype.

How Do You Prevent This Problem? A couple of suggestions…

  1. Prototype in a language or tool that you'll definitely not use long term. I've seen MS Access proposed. It's impossible to secure but easy to use.
  2. Separate visual design from the prototype. Using wireframes will help customers understand how the final product should look without getting too attached to the visuals of the prototype.

You may also like