Don‘t make the Demo look Done

When we show a work-in-progress (like an alpha release) to thepublic, press, a client, or boss... we‘re setting their expectations.And we can do it one of three ways: dazzle them with a polishedmock-up, show them something that matches the reality of the projectstatus, or stress them out by showing almost nothing and asking them totake it "on faith" that you‘re on track.
The bottom line:
How ‘done‘ something looks should match how ‘done‘ something is.
Every software developer has experienced this many times in theircareer. But desktop publishing tools lead to the same headache for techwriters--if you show someone a rough draft that‘s perfectly fonted andformatted, they see it as more done than you‘d like. We need a matchbetween where we are and where others perceive we are.
Joel Spolsky talked about this way back when inThe Iceberg Secret, Revealed. The secret:
"You know how an iceberg is 90% underwater? Well, most softwareis like that too -- there‘s a pretty user interface that takes about10% of the work, and then 90% of the programming work is under thecovers... That‘s not the secret.
The secret is that People Who Aren‘t Programmers Do Not Understand This."
He goes on to add corollaries including:
"If you show a nonprogrammer a screen which has a user interfacethat is 90% worse, they will think that the program is 90% worse."
and
"If you show a nonprogrammer a screen which has a user interfacewhich is 100% beautiful, they will think the program is almost done."
You‘ll have to read the rest to get the other corollaries, and to see where else he takes the topic.
My First Robert Scobletalked about this recently, in a story about the early fake prototypes of Vista:
"Later... I found out that all we really saw were MacromediaDirector-based movies. They looked so cool...how good they made usfeel... This actually was NOT a good thing for Microsoft...when youbuild up expectations and you aren‘t able to meet them you look prettysilly.
But behind the scenes things were even worse. Why? Becauseexecutives bought into the Flash and Mirrors song and dance too. Theythought what they were seeing was possible... it‘s very possible thatwhat you are dreaming of is simply not possible."
So, overpromising by delivering a flashy (or Photoshopy orPowerpointy or Visioy) demo is tempting, but it‘s short-term gain(you‘re a hero to your client, boss, the public) with long-term pain.But there‘s another problem with overdone demos that‘s just if not moredamaging than wrong expectations:
The more "done" something appears, the more narrow and incremental the feedback

We see this with books and software all the time. Show themsomething polished and pretty, and you‘ll get feedback on font sizes.The reviewers make incremental tweaks, blinded by what‘s in front ofthem. But show a napkin sketch, and they don‘t just see what‘s there, they see what‘s possible. Obviously you need to tell reviewers about the kind of feedback you DO want at this stage... you don‘t want big-picture-forest feedback when you‘ve really moved on to the tree stage. My point is: all you‘ll get is tree-tweaks when you show something finished-looking, so if you want big picture,make it fuzzy!
Finally, it‘s great to know that there are tools to help make the look match the state, with my favorite being theNapkin Look and Feel,a GUI "skin" for Java that makes the interface look--quiteliterally--like it was scrawled on a napkin. I think it‘s brilliant,and creator Ken Arnold (Java guru, fellow Sun refugee) paid astonishingattention to detail. For example, if the radio buttons were all exactlythe same, no matter how sketched they look, their exact sameness wouldbreak the spell. So, there‘s more than one of nearly all of the GUIcomponents from sliders to buttons to tabs to...
Here‘s just one picture, but I urge you to go check out thesnapshots on Sourceforge or even better, try the actual Java demo (youcan get to the demo from the link above).

I realize that there are a million exceptions and caveats (like, for example, when you‘ll be firedif you don‘t show something jaw-dropping early on), but in general, themore closely what you SHOW matches what you HAVE, the more likely youare to have less pissed-off people down the road, and the morelikely you are to get much better feedback, at the stage you need it.Bottom line: when it‘s an early demo, think fuzzy. Think sketchy. Thinkunderpromise-and-overdeliver.
[Related links:
* 37Signals blog talks abouthow to make sure you fix the ‘placeholder‘ stuff before the final release
UPDATE: flow/state discusses the same thing inMatching Design sketches to the desired level of design feedback]