Clippy, Interactivity, and Product Success
The other day I read this: "Now, they make a big deal out of the "interactive menus," but I was working under the impression that all menus were interactive, like when you go into a restaurant and point to where it says "steak," it shows up a little later and then you eat it. Now that's interactive." [Red Green, Ardmoreite.com article, may require free registration]
That led to my recent thoughts on Clippy. There were two problems with Clippy: the experience provided an expectation of interactivity but faked the delivery; and the ensuing lack of use (and therefore feedback) ensured Clippy would never improve.
It doesn't matter whether we're discussing Clippy or (the vast majority of) automated phone switchboards. People rightfully don't like either. Any time you put a pseudo-solution that promises interactivity in place of a real solution that delivers it, there will not only be disappointment, but disappointment compounded by frustration.
Clippy was ot good at understanding my context, and it's frustrating not to be understood. I couldn't talk to Clippy. And once frustrated, I didn't have any tools or weapons to destroy Clippy. Unchecking a box on a menu does not deliver the satisfation promised by interactivity. There were other ways the experience was unsatisfying, perhaps we'll read of a few in feedback.
The second problem was that when you release something that no one uses, it can never improve. The golden rule of the ASP.NET team is (paraphrased) "in time, people won't remember whether you released on time, but they will always remember if you release a bad product." If a bad product fails to deliver on a core promise like interactivity, you can cripple the potential for success completely. Delivery must meet the expectations you set.
If delivery meets expectations (and also meets a need, but that's another topic), people will use the product. When people use a product, a feedback loop becomes possible, and the product will improve. If that doesn't happen, or you prevent it from happening by failing to meet expectations, then you've poisoned the brand and need to re-build from scratch. Therefore Clippy and MS Bob should never be reincarnated.
If I could have easily configured my own commands for Clippy, it wouldn't have been a closed, frustrating experience. It would have enabled me to implement use cases not anticipated by the team that created Clippy. And that's a shame, it's an obscure fact that that there was a simple API for Clippy and its brethern, but no one really touched it, because the out-of-box experience poisoned the acceptance of anything with origins in that technology. The lesson? Understand the expectations you're setting. If you're promising interactive, make sure you can invoke a service that delivers steak.