This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Why Worse Might Just Be Better
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
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."
Whoops.
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.
Previous Topic
