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  
   
 

ISSUE 21 - Q1 2007

The dark side of prototyping

How to steer clear of the pitfalls in prototyping

Are there any downsides of prototyping? Not really. But as with everything else in life, you might stumble and hurt yourself if you don’t watch your step. This article points out some of the banana skins to steer clear off.

At a conference where I did my talk on the benefits of prototyping (based on my article The promised land of prototyping), a person in the audience had the nerve to ask me if there aren’t any downsides of prototyping. If I had had a spin doctor, I would have been prepared for that question. But I was taken by surprise. I couldn’t come up with a single drawback to prototyping.

After some weeks of pondering, my conclusion is that there are no real downsides to prototyping. At least not in the same way as there are downsides to nuclear reactors (they might melt down) and love affairs (you might get dumped). Prototyping can’t hurt. But of course, we may run into problems if we don’t play it wisely.

These are the most common pitfalls that I’ve heard of, seen others fall into, and fallen into myself:

  • Not aligning the design with project constraints
  • Going high-fidelity early in the design process
  • Not involving colleagues

What these pitfalls have in common is that they are really not that hard to avoid if we just pay a little attention to them.

Not aligning the design with project constraints

Designers are creative creatures. In our urge to show off our exceptional talents, we might be tempted to invent ingenious solutions that exceed what is possible with the time and budget the project has at its disposal. We might come up with designs that include features that go beyond the scope of the requirements that has been agreed upon with the client. And we might come up with designs that are too hard to implement within the project’s technical constraints.

Going beyond what is reasonable within budget, timeframe, technology, and requirement agreements can be quite hazardous. We are heading for trouble if we show excessive designs to our clients without having consulted our colleagues and project managers first. It can put the project in a precarious situation, where we either have to cover the extra cost ourselves, ask the client for more money, or explain to them that what they saw, is not what they are going to get.

Going high-fidelity early in the design process

The term fidelity means how perfect a prototype is made (if you want to read more on this subject, you might want to read my article Balancing fidelity). As with perfection in any other area, perfection in prototyping comes at a cost:

It makes the design process rigid. Obviously, creating and making changes to a high-fidelity prototype takes more effort than to a less perfected prototype. It’s a labour-intensive approach and doesn’t lend itself to a creative and dynamic design process where we want to explore alternatives and be able to quickly change things that don’t work out as expected.

We get attached to our creations. We all hate making changes to things that has taken us a lot of effort to create. Since high-fidelity prototypes take blood, sweat, and tears to build, we are more likely to become reluctant to improve them. We get attached to our initial ideas and will settle for less than good enough. Also, managers are likely to be highly reluctant to support costly changes to something that has already taken its bite of the budget.

We waste time on things that will be changed anyway. Prototypes are built to get answers to questions that are important to the product design. The longer it takes us to create the prototype, the later we will get the answers we need. And the more time we use polishing our prototype, the more time we risk wasting on something that won’t survive the next iteration.

We will have to struggle to get the feedback we need. If we present a detailed prototype to our clients, their eyes and attention will inevitable be drawn to the details. Issues, such as colours, image quality, logo treatment, typography, spelling, data validity, stability, and response time will put the conceptual aspects of interaction design and of information architecture in the shade. Form will trump function, and minor flaws and temporary solutions will stand out. While the details have to be discussed sooner or later, it’s counterproductive if the design is still in a conceptual stage. We will get a whole lot of input, but will have to struggle to get feedback we need.

Not involving colleagues

Many bad things have been said about “design by committee.” But we can’t ignore the fact that interface designs have far-reaching consequences for the entire development project. Design by blinkered dictatorship is not a viable alternative.

Involving colleagues in the design process will help us align our designs to project constraints and can make us aware of opportunities that we didn’t know about. But there is an emotional side as well. Not involving colleagues might result in fierce opposition against everything we propose. Not because our suggestions are bad or infeasible, but because we haven’t taken the skills and views of our colleagues seriously.

In conclusion

One might argue that there are whole lot of other dangers in prototyping, such as not initially studying user behaviour to uncover their needs and not testing a design to see whether people can figure out how to use it. While these are indeed important concerns, I consider them general issues that aren’t specific to prototyping. What I’ve tried here is to point out some of the most common pitfalls of prototyping. The pitfalls aren’t that many and they aren’t very dark and dangerous. But if we don’t pay attention, we might have to struggle harder than necessary or even get ourselves into trouble.

Therefore:

  • 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

Have you experienced other pitfalls in prototyping? Share your insight by leaving a comment below.

Text: Henrik Olsen

   
 

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

RELATED POSTINGS

 
Posting added before you last visit at GUUUI Visio - the interaction designer's nail gun (2nd edition)
Posting added before you last visit at GUUUI The promised land of prototyping
Posting added before you last visit at GUUUI Balancing fidelity in prototyping
 
 
     
  To the front pageSign inTo the frontpageSearch in GUUUI postingsAbout GUUUI