This entry has 4 comments

• 
  On September 30, 2008

  Dan Harrelson wrote:

  An additional constraint is the time available to build the prototype. Maybe you have a week, maybe you just have an afternoon. Maybe you have a bunch of afternoons spread over a month as you iterate through a user testing / prototype tweaking cycle. Whatever the answer, looking at the amount of time you have available to you greatly affects what you can and should aim to show in a prototype.

• 
  On October 2, 2008

  Todd Zaki Warfel wrote:

  Great point, Dan. Time is also a critical factor. That’s another reason why you should pick a tool you’re comfortable in. A comfortable tool is more efficient.

• 
  On October 30, 2008

  Martin Svendsen wrote:

  One of my main criterias is as you say fidelity, but for me it is in relation to who is going to build the application afterwards.

  Very often, the prototype is a part of the documentation (and when building “in house” often THE Documentation), so i always start of with the developers, discussion to wich degree I have to specify the details and data sources.

  Then we discuss wich elements in their development is out of the box and wich elements takes time to build.

  So when i have to choose between different approaches (thats equally user friedly and usable) to my prototype, i take the one thats easyest to build. That ensures that i don’t promise the user something that the developers can’t build within the budget.

• 
  On February 26, 2009

  Bernhard Doll wrote:

  I have tried to capture all my thoughts and ideas on this in a generic picture. May be you like it (the article is in German, however, just click on the picture in the middle, it’s in English

  http://bernharddoll.wordpress.com/2009/02/23/prototyping-framework/

• Click here to subscribe to the comment feed via RSS

Leave a comment

You must be logged in to post a comment.