To the front pageThe Interaction Designer's Coffee Break - Weekly postings and quarterly articles about interaction design  
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI  
   
 

The dark side of prototyping

The Q1 2007 issue of GUUUI points out some of the most common pitfalls of prototyping and how to avoid them:

- Make sure that the design reflected by the prototype is realizable within the project constraints
- Keep fidelity at a minimum throughout the design phase
- Involve colleagues in the design process

Links:

Henrik Olsen - January 01, 2007

See also: Prototyping and wireframing (119) 

 

COMMENTS

I find that one of the difficult things to balance is the client expectations. I generally try to be quite fast and loose with the prototypes so that we can go through multiple design & review iterations quite quickly.

Clients almost always want to see some creative work, even before we've started prototyping and it can be problematic if they get attached to a specific creative design. Either they resist prototype changes that do not fit with their favourite creative concept, or they feel that we should build a full creative concept for each design iteration.

It's a bit heavy handed, but in extreme cases I've sent a seperate quote for the work involved in updating the creative concepts, that usually gets them to focus on the prototype and forget about the creative for a while.

Dave Kinsella | January 02, 2007

 

My experience with the prototyping dark side is similar, sometimes clients don't want to let them go!

On one project we were tasked with designing and building the front end to a larger system. Before we got involved, the client had designed a prototype to get buy in from their management without any input from us. It was a real battle to get the client to abandon their prototype, one or more members of the client team would leave a workshop with the action to "Update prototype to match design".

It took months, but we killed the prototype in the end. The benefit of this was building up a good and trusting relationship with the client.

Roland | January 09, 2007

 

If a good series of 'management of change' activities have not already gone on, you won't have the right audience involved in either the design or the review. A prototype is typically the first serious deliverable that screams 'pending change'. Everything else is just words...

If a good dose of 'design thinking' has not been going on, the design may likely address the wrong problem...which then wastes the investment of time (this is different than not getting it 'right' -- the true purpose of a prototype). Again, this would also be influenced by not having the right people involved or context applied (as implied above).

Paula Thornton | January 11, 2007

 

An additional issue to early high-fidelity prototyping (which has been indirectly addressed in some of the comments above) is that the stake-holders tend to focus on the details of the prototype, rather than the functions.

While you may be trying to evaluate a flow, the stake-holders are arguing over the type of font in the navigation. The method of prototyping should best fit with what the prototyping is trying to evaluate.

Douglas Potts | January 11, 2007

 

I find that the greatest challenge in either low or high fidelity prototyping is convincing the client/business partner of its overall value. Often they want to bypass the prototype and move straight to design where allot of resources can spend a great deal of time "spinning".

Another pittfall is using prototypes to nail down business requirements. While similar to "Not aligning the design with project constraints" as illustrated above, often times vague or loosely defined requirements get fleshed out in the prototyping phase, reducing the impact and value of the prototype as a tool itself.

john w michael | January 31, 2007

 

A banana skin not mentioned here is failing to align one's work with accurately assessed user needs and culture. I would add this to the great points already mentioned.

Adhering to the practical constraints of the client is, of course, a necessary reality. And using expert (colleague) testing to flesh out details and hone the rough edges prior to presenting ideas to the client can be a life (or at least a time) saver, as mentioned in the article.

A recurring situation is clients who think they know their user's needs; or, worse yet, feel that they know better than the users in regard to what is needed.

In the former, clients often have performed no assessment. Their opinions are based on gut-level feelings or anecdotal sources of information. And when any form of assessment was implemented, it was generally biased and self-serving to the direction or goals of the client.

Prototyping based upon any of these has, in my experience, met with limited success. Even if the design doesn't miss the mark, users resent not having been given the opportunity for input.

So, I would add this to to the points made in the article and the comments that followed.

Robert D. Wright | March 04, 2007

 

Taking this in a slightly different direction...

I've been corresponding/working for almost two years with Robert Lane of Aspire Communications (http://www.aspirecommunications.com/). He has been developing what he calls Relational Presentations; basically, interactive PowerPoint networks that allow you to change direction or focus depending upon what your audience (or clinet) wants.

He has broken some new ground by integrating a lot of common practices and theories into what could conceivably be a massive library of images ( he currently has 10,000 or so networked.

My question is, if you have a huge project, how would you go about rapid prototyping when trying to cover so much?

Prototyping the navigation of several specific topics would demonstrate coverage of those topics; but might not fully explain the navigation to a client.

Prototyping to explain navigation rationale would demonstrate the navigation possibilities; but, if thorough, would almost totally exclude the breadth of what the client was interested in.

Shooting for the "happy medium" could conceivably leave with the worst of both worlds rather than the best. A definite banana peel.

Robert Lane discusses rapid prototyping in his training and materials. But, I'm curious to hear waht others have to say when rapid prototyping has to tackle a complex situation.

I'd be interested in hearing the thoughts of other members of the group.

Robert D. Wright | March 07, 2007

 

I have to agree that there isn\'t a downside to prototyping. Even though I do 3D fit & function objects it is all the same concept. Often my customers during the design & prototype phase go through many iterations to just get to the prototype. Then once the prototype is built often it shows exactly what needs to be tweaked not just in the design, but also to ensure mass production goes smoothly.

Great article!!

Rapid Plastic Prototypes

Scott Lamon | February 06, 2009

 

Sponsor

Ad for TechSmith Morae


Browse GUUUI postings

Methods and the design process

Prototyping and wireframing (119)  Usability testing (68)  Cost-justification and ROI (27)  User research (23)  Personas (19)  The design process (24)  Eye-tracking (14)  Card sorting (13)  Web traffic analysis (12)  Expert reviews (11)  Implementing user-centred design (9)  Site and flow diagramming (6)  Envisionments (4)  Use Cases (3) 

Design elements

Navigation (63)  Web page design (40)  Search (27)  Text (24)  Forms (30)  Links (19)  Guidelines and Standards (15)  Site design (14)  Ads (9)  Design patterns (8)  Sections (8)  Shopping Carts (9)  Error handling (7)  Home pages (9)  Help (3)  E-mails (3)  Sitemaps (2)  Personalization (1)  Print-friendly (1)  Landing pages (5) 

General aspects

E-commerce (27)  Persuasive design (21)  Visual design (19)  Information architecture (15)  Accessibility (13)  Search engines (7)  Credibility, Trust and Privacy (6)  Emotional design (10)  Simplicity vs. capability (7)  Web applications (6)  Intranets (3) 

Technology

Flash (6)  Download time (5)  Javascript (3)  URLs (3)  Browsers (3)  Web standards (2) 

Humour

Bad designs (20)  Cartoons (14)  Fun music and videos (13)  Funny tools and games (12)  Misc humor (8)  Fun with Jakob Nielsen (9)  Designs with humor (3)  Fun posters (5)  Funny 404 pages (2) 

Resource types

Research (129)  Tips and guidelines (95)  Tools (106)  Books (47)  Audio and video (48)  Interviews (30)  Cases and Examples (28)  Talks and presentations (18)  GUUUI articles (11)  Primers (14)  Online books (5)  Posters (5)  Glossaries (3)  People and organisations (3) 

Information sources

Blogs (12)  Websites (11)  Discussion lists (4)  News (3)  Newsletters (3)  Online magazines (3)  Wikis (1) 

 
     
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI