This post is part 3 of our Software Support and Artificial Intelligence series. You can find an overview of the series on our introduction post. If you are reading this before all posts have been published make sure to sign up for our AI & Docs mailing list, where we send notifications when we publish these posts and similar content.
In our previous article - The Helpful co-worker model - we explained why teaching others and giving advice is very human but not always welcome. Sometimes we fail even when we try to be helpful, just like Clippy, Microsoft’s artificial helpful colleague. So why did Clippy fail? Why is today different, and why should we now be able to make a programmatic helpful colleague that works?
Clippy’s story: Microsoft’s attempt to replace the helpful colleague
Anyone who used Microsoft Office in the late 90’s remembers Clippit a.k.a. Clippy, a well meaning usability feature that terrorised Office users during its 9 years tenure. While it wasn’t as reviled as Internet Explorer 6, few people mourned when it left the Office suite. Now that many web applications are again experimenting with automated unsolicited support interventions again, there is an important question that we need to ask…
Why did Clippy fail?
Clippy was optimized for first use. While you might have been delighted when you first interacted with Clippy, a lot of its advice was useless for power users. Once you didn’t need it anymore, you had to figure out how to turn it off, and keep it off. Simply closing it only temporarily turned it off. Every time you restarted Office, Clippy would be back with its smug little pseudo-face. So the last thing everybody remembers about Clippy is how difficult it was to get rid of it.
Clippy couldn’t adapt fast enough because it wasn’t able to learn
- Developers didn’t have the ubiquitous data about real-time usage that could have helped them adapt the content and interaction triggers of its communication models.
- Clippy’s software wasn’t able to collect the information needed to build up the highly contextualized models needed to personalize the experience for individual users.
Misunderstood brilliance before its time
Clippy has been a really easy target for jokes about UX failures and bad documentation practices. It is easy to bash a product that everybody already declared a failure. But I think the basic principle of automated proactive support as a delivery mechanism for documentation is a brilliant idea. Instead of ridiculing Clippy, we can learn from it to build proactive documentation delivery mechanisms that won’t backfire.
_There was an_ audible groan in the audience _when I suggested we should bring Clippy back in my "Embed the Docs!” talk at Write the Docs Portland_
Web applications make it significantly easier to collect information about a user’s journey. Combined with the rise of inexpensive AI solutions it should be possible to provide much more relevant content and personalize the experience: the user would have less, more qualitative interactions with the documentation content. If we do this right, it could feel like magic, resulting in happier and more loyal customers.
Recently, personalisation became an important driver in marketing investments, to help marketeers target different customer segments with messages adapted to their interests. I however believe that personalisation could be much more valuable if applied to the support and training requirements of web applications.
Other posts in this series:
Part 1: Documentation at a crossroads
Part 2: The Helpful co-worker model
Part 4: Repeating Clippy’s mistakes with Walkthroughs
Part 5: Automated proactive support as embedded messages
Interested in AI for Documentation? Sign up below and we’ll email you updates on our research.
Subscribe and get notifications about the next parts in these blog post series!
