Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Wednesday, May 10, 2006

Why Worse Might Just Be Better

For years, I was puzzled by the strange reaction of customers to nice-looking software prototypes. It went something like "This is great! Looks like you're pretty far along. Can I have this by the important conference/board meeting/presentation next month?"

Why would they do this? I clearly stated that I was showing a prototype. Something I put together to demonstrate a concept, not a production-ready, working system. Which syllable of pro-to-type didn't they understand?

And then, after several more painful episodes, it hit me. My prototypes looked good. They looked like something you would want to use at a sales meeting or conference to impress someone. You'd have to be impaired not to want to use it as evidence of progress, innovation, or in a word, sizzle. I've started calling this the "sizzle syndrome."


For my next prototype, I went more low-tech using paper sketches, and some in-person whiteboarding to demonstrate the concepts. This worked almost as well for feedback, without the "sizzle syndrome." I recommend this approach when you have an engaged customer at your location.

When dealing with either extremely busy or remotely located customers (like the ones more than 20 feet down the hall), sometimes you still need a more interactive prototype that they can play with without your involvement. HTML prototypes can serve this purpose, but I try not to get bogged down in look and feel details. Keeping things clean and simple helps me get feedback on the areas I'm interested in, while minimizing the noise that colors, fonts and shapes can generate ("Are you really to make that yellow? I hate yellow.")

Interestingly, with actual software, the effect I've seen is often the opposite. A perfectly functioning, but unremarkable-looking piece of software often elicits opinions on the color scheme, layout, use of certain types of widgets and more. A beautifully designed look and feel can generate great praise and excitement, even if the underlying functionality is mediocre or even suffers from usability problems.

So is worse really better? For early conceptual prototypes it can be, as long as you're getting the kind of feedback you want. Warning signs of too good a look are that you get lots of non-specific glowing praise ("This looks great!"). If you skew too far in the other direction, you'll know by the very pointed feedback ("I don't think this is ready for prime time", or "Perhaps we should bring in a graphic artist").

The point of prototyping is to get rapid feedback about the user interaction and how well it solves the problem at hand. The more you can eliminate obstacles to getting that feedback by removing user interface distractions (either positive or negative), the more meaningful your feedback will be.

Sometimes that means making something look worse, so that the final product will be better.

For more on agile tools and techniques:
(Tags: , , )

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I wonder also whether people who will *actually* use the system are as impressed by sizzle. Are we presenting our prototypes to the right people?

    By Blogger Jason Yip, at 2:29 PM  

  • Jason,

    You raise a good question. I think for product companies, it's often tough to find the right person, which is why is important to have a strong product manager (who isn't influenced unduly by sizzle).

    For corporate development, connecting with several different types of users is often appropriate. Managers and staff often have different agendas for software function.

    By Blogger David Churchville, at 6:25 PM  

  • Many business people have an understanding of software that is superficial--they see the outer shell, not what's inside. Paper prototypes are a good thing. But we must somehow attempt to educate business people on the importance of software *functionality*, and the difference between application behavior and graphic design. We have to understand them better, and they have to understand us (programmers) better as well.

    By Anonymous Anonymous, at 8:43 AM  

  • In one of the software conferences I was in, the speaker said that to solve this problem they did the following:

    Developed all thier prototypes in Flash. (For windows applications and for other applicable solutions also)

    So even if the customers liked it, they would not be able to use
    it ;-) as it was not written using C#, or Java..


    By Anonymous Anonymous, at 8:41 AM  

  • By Anonymous Anonymous, at 11:14 AM  

Post a Comment

<< Home