Design, prototyping, and construction

Reference: Sharp, H., Rogers, Y., & Preece, J. (2007). Interaction design : beyond human-computer interaction (p. 464-521). Wiley.

A prototype is a model or representation of a product whether it is physical or electronic that “simulates the scenario of use.”(Sharp, Rogers, & Preece, 2007) A prototype allows prospective users to envision what it would be like to use the real product. Prototypes are highly supported and encouraged in the design process with researchers like Liddle (1996) recommending that it precede any writing of coding.

Prototypes serve many purposes which include:

  • To  test  out  the  technical  feasibility  of an  idea
  • To  clarify  some  vague  requirements
  • To do  some  user  testing  and  evaluation
  • To check  that  a  certain  design  direction  is  compatible  with  the  rest  of  the  system development.

(Sharp et al., 2007)

Prototypes usually come in two forms: low-fidelity and hi-fidelity with the latter posing risks for both users and developers. Low-fidelity prototypes are obvious models of the real product because they are usually made with a different material from the final product and the functions don’t work. Someone would obviously realize that a real tablet device is not made of paper or plastic. The danger comes when the device is operational and the customer can interact with it. In this case they may tend to think that prototype is the final device and may develop wrong impressions of it. Also developers may be tempted to use these prototypes by simply adding a few more functions especially if time is against them.

Low fidelity prototypes are intended to be thrown away and this is perfectly understandable. Why would anyone decide to keep such a prototype unless they want a souvenir? On the other hand I would be less inclined to throw away a hi-fidelity prototype, in spite of the dangers associated with it. From the view point of a programmer, too much work and effort have been place in the prototype to throw it all away and start again from scratch. In addition enough information would have been collected to know which parts of the prototype had high quality usability and which functions had to be revamped. If this is done properly, then I think that a highly usable product can be produced from that prototype.

The authors also made a valid point that I tend to agree with. Due to the fast development cycle of products today it makes more sense to have a “good enough” product on the market than having high quality product released two months after your competitors. Do what Microsoft does, release a “somewhat good product” then later release updates and fixes.


One response to “Design, prototyping, and construction

  1. So, make this information YOURS. Do you use prototypes in your work? Did you know about them before doing these readings? Will you use them in the future? Why? How?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s