It is far more effective to sit in a chair than judge its comfort by a picture of it.

  • Web Site
  • Browser Application
  • Kiosk
  • Mobile Application
  • Desktop Client
  • Digital Appliance

 

  • Paper Prototype
  • Click-Thru Screenshots
  • Click-Thru HTML
  • Interactive HTML+JavaScript
  • Flash or Silverlight
  • Adobe Air or MS WPF

 

Concept Car Chart
  • Stickiness of Decisions
  • Overall Speed
  • Ability to Iterate
  • Reuse of Assets
  • Reuse of Code
  • Stakeholder Involvement

Ability to make key decisions during the prototyping phase that remain valid in the final product.

Ability to save time cumulatively over the course of the entire project by using this prototype method.

Ability of this prototype method to promote iteration during the entire project.

Ability to use icons, images color palettes, and other visual assets in the final shipping product.

Ability to use scripts, CSS or other code in the final shipping product.

Ability to communicate what the final product will be to people not privy to the day to day product development, such as executives, customers, and sales people.

Marker Marker Marker Marker Marker Marker

 

Stickiness of Decisions – Optimal

Decisions made—whether they are aesthetic, behavioral, structural or with regard to branding—are so well informed they are likely to be valid for the final shipping product.

Stickiness of Decisions – Effective

It's possible to make critical design and engineering decisions, but there will be a portion, often with regard to behavioral details, that cannot be made final until feedback is gathered from the real, working product.

Stickiness of Decisions – Acceptable

Most, if not all, design and engineering decisions made at this level will require some sort of followup, verification, or validation when the real product is built.

Stickiness of Decisions – Minimal

Only the most common and basic decisions can be made. These are generally decisions about product direction overall, and can be compared to the same kinds of decisions one would make with pixel-perfect screen renderings.

Stickiness of Decisions – Marginal

Decisions based on this prototype are rarely useful for anyone outside of the design team. Using only this type of prototype often requires designers to create low-fidelity assets that wind up filling time rather than contributing tangible progress towards shipping a product.

Overall Speed – Optimal

Significant time savings will be seen over the entire course of the project, anywhere from 33% to 50% versus other prototyping methods.

Overall Speed – Effective

Respectable time savings will be seen over the course of the project, anywhere from 20% to 33% versus other prototyping methods.

Overall Speed – Acceptable

Decent time savings will be seen over the course of the project, anywhere from 10% to 20% versus other prototyping methods.

Overall Speed – Minimal

Little to no time savings will be seen over the course of the project versus other prototyping methods.

Overall Speed – Marginal

While at first it may feel like time is being saved, at best, no time is saved over the overall course of the project, and at worst, time is added due to the inappropriateness or inadequacy of the prototype for the product category.

Ability to Iterate – Optimal

The nature of the prototype, once built, provides ample opportunity to experiment with a wide variety of design choices with very little reconstruction time. More often than not, changing the prototype will be faster than changing any other static deliverable.

Ability to Iterate – Effective

While the prototype is malleable if constructed smartly, it will require some time to make changes. These changes generally take the same amount of time as reconstructing pixel-perfect screen renderings.

Ability to Iterate – Acceptable

Changing the prototype is often slower than fixing static deliverables, however, the time difference is not significant enough to lose the ability to see the changes in action.

Ability to Iterate – Minimal

The speed to change the prototype is such that it would only be done at key stages, and as such, may impede constant iteration of the overall design direction.

Ability to Iterate – Marginal

Time would be better spent iterating with static deliverables than spent iterating this type of prototype.

Reuse of Assets – Optimal

More than 80% of the assets made for the prototype can literally be copied and pasted into a source control system to be used for the final shipping product.

Reuse of Assets – Effective

Roughly 50% to 75% of the assets made for the prototype can be used in the final shipping product.

Reuse of Assets – Acceptable

Approximately 25% to 50% of the assets made for the prototype can be used in the final shipping product.

Reuse of Assets – Minimal

Few, if any, of the assets made for the prototype can be used in the final shipping product.

Reuse of Assets – Marginal

There is nothing that you can repurpose here. All assets made at this level are purely for the purpose of internal design and engineering processes, and are of little to no use outside of the team.

Reuse of Code – Optimal

Most of the code and scripts written for the prototype can be used as is for the final shipping product.

Reuse of Code – Effective

A significant portion of the code and scripts written for the prototype can be used in the final shipping product. Often times, code will have to be refactored into a different form by engineering. For example, HTML layout code might be refactored into Java code that writes out the HTML layout.

Reuse of Code – Acceptable

Code and scripts written are good enough for prototyping, but will always have to be refactored into a final form by engineering.

Reuse of Code – Minimal

Code and scripts written are only useful for the purpose of prototyping.

Reuse of Code – Marginal

There is nothing that you can repurpose here, not even for future prototypes. Any code written is a complete one-off, making it useful for only that prototype.

Stakeholder Involvement – Optimal

You can safely have executives, customers and sales people view and interact with the prototype without specific guidance. Feedback received from these stakeholders about this prototype will be as good as feedback received about final, shipping products.

Stakeholder Involvement – Effective

You can safely have executives, customers and sales people view and interact with the prototype as long as they are guided through it or someone with knowledge drives it. Feedback received on this type of prototype from stakeholders is often very good.

Stakeholder Involvement – Acceptable

You can have executives and customers view the prototype as long as someone with knowledge of the prototype guides or walks them through it.

Stakeholder Involvement – Minimal

Sharing this type of prototype is usually only meaningful to people who have working knowledge of the project and understand that what they are seeing is incomplete. Feedback here may be useful for the design and development team, but is mostly inadequate to make critical decisions without supplemental data.

Stakeholder Involvement – Marginal

Involving stakeholders in reviewing this type of prototype is usually not valuable unless they are deeply involved in the project and have an understanding of the design process up to that point.

 

Tools + Resources

Design:

Supplemental:

References:

Design:

Development:

Design:

Development:

References:

Design:

Development:

References:

Design and Development:

References:

Design:

Development:

References: