Avoid the “Clippy Cliff”: Interactive Notifications and Effective End-User Engagement

Let's dig a little deeper. Here’s a typical workflow:

1. An application crashes.
2. Tachyon detects this and reacts, prompting the user to:
   a) Restart the application
   b) Log a ticket in the service desk
   c) Check if there’s a newer version of the app available to install

If your device is running out of disk space, Tachyon notices this and prompts the user to:

1. Perform an automated disk cleanup
2. Provide some options for manual file removal
3. Log a ticket in the service desk

The user performs the automated disk cleanup and we’ve diverted a helpdesk incident – again, sounds great, right?

OR, you create a survey to ask users about their digital experience and their satisfaction levels with IT. But, how do we ensure that the action of prompting users to gauge their satisfaction levels doesn’t, in and of itself, negatively impact on end-user satisfaction.

And if you need any help visualizing how that could possibly happen…

The "Clippy Cliff"

Remember this guy? One of the first ever “Digital Assistants”, Clippy – who only ever wanted to help! – became derided and hated almost universally. It seemed that he didn’t learn that you could learn. Every time you opened a doc, he’d tap on your screen. Yes, it was cute the first time you saw it, but by the 3^rd time the shine had worn thin and by the 250^th time you were imagining new and innovative ways to torture anthropomorphic paper clips – only kidding! By the 5^th time it popped up and annoyed you, you’d likely found out how to disable it. Then, a month later, your version of Office was upgraded and when you’d start up a new doc and “tink tink” here’s Clippy back again!

As a user, he’d pop-up at the worst times, offering needless, useless help and when something was actually wrong, it was difficult to get help from it. It was an overall frustrating process.

Let’s go back to that user with the filling hard disk. Say, for example, we check for disk space issues every 2 hours. At 09:00 you get a prompt and tell the pop-up to auto-clean. Auto-clean then clears up some space, but it mysteriously fills up again (perhaps there’s some logging process gone nuts on the device). At 11:00 you get another prompt. You tell it to auto-clean again, but it comes back at 13:00 – you tell it to log a ticket for you – but if no-one has come back to you by 15:00 and you get your 4^th prompt of the day – your end-user experience is far from positive and you can’t help but be frustrated. THEN the survey asking you your satisfaction levels appears while you’re screen sharing during a Teams call.

So, how do you avoid turning your attempt to provide interactive help into the 2021 equivalent of Clippy? Well, the good news is that the Product Managers and Engineers in 1E have put some thought into that question and they’ve given you a host of tools to enable you to do your best to avoid the “Clippy cliff”.

Effective End-User Engagement

There are two main routes to create end-user interactions in Tachyon:

1. Through Experience Surveys
2. Through Interaction workflows

The first is driven entirely by the UI and has a lot of anti-Clippy functionality built in, which I’ll describe shortly. The second is driven by Tachyon SCALE code, so while 1E can provide you with a host of tools to make sure you create “nice” functionality, you can build what you like with it – as annoying or otherwise as you want it to be.

So, let’s have a look at what Tachyon does when it comes to Surveys to make them as non-intrusive as possible. We can also consider the tools 1E gives you to make it easier to create workflows that are equally positive end-user experiences.

Experience Surveys

The first thing we did in 1E was decide that each “Survey” would be a single question. At most a two click end-user experience (choose the option with one click and hit “submit” with the second).

You can create multiple choice questions, with icons and colors of your choosing – but ultimately, they are a two click experience.

The next thing we decided was to add a bunch of logic which allows you to define when NOT to display a survey, how frequently to display them, etc. These are set in the 1E.Client.conf file for each endpoint (which can be updated for one, some, or all endpoints at once using Tachyon instructions).

For reference, here are the items, and what each one means:

So, as you can see, users shouldn’t be “bothered” too often by Surveys, even if you have quite a few questions to ask them. They will only ever get one at a time, with hours if not days between them. They will only be prompted when they are not on “Do Not Disturb” and never when they are actively typing or moving their mouse. When a Survey does pop-up, the user knows (after the first couple of times it happens) that it is a two click situation – not something which will drag time from them.

A key concept of the surveys is “Audit Universe” – what is the minimum number of responses you can get in order to understand the general sentiment? Sampling a few hundred users a day, adding up that data, and understand it is massively powerful, even if there are tens of thousands of users out there. Garnering opinion in a way which isn’t a negative experience is more important that getting all the users to answer everything every day – that will soon grow old, and negatively impact the very opinion you seek!

Tools for Hand-Building Workflows

So those are the rules for “normal” surveys, as triggered by the 1E Client, based on what you setup in the Experience module of Tachyon. But, you can also create your own surveys using the Interaction features of the 1E Client (Tachyon agent).

These surveys can be run as instructions by a Tachyon user with appropriate rights, or as Guaranteed State rules as a result of a “Trigger”. So, when someone wants to send out a message, question, or survey, they can! They can also do so in response to disk space filling, an app crashing, performance degrading, or any other trigger you can think of.

You can chain these together – to the point where you ask one question, get an answer, optionally take an action, perhaps then asking another question – as many questions and actions as many times as you like.

Don't Be 'That Guy'

This is where the danger of “Clippy” lies. Don’t be that guy. Try to bear some basics in mind when designing these workflows:

1. Allow the user to not participate at any time
Maybe I know that performance is bad, or my disk is filling up but I don’t care right now. It isn’t a priority for me right now. I don’t want to play, I don’t want to ask questions. I just want the prompt to go away. If I do that, I likely don’t want it to come back in 5 minutes time either, so consider how long to “lurk” for before coming back to prompt the user again.

Consider using Tachyon Storage.x() functions to record when they opted out, so you can use this time to give them space before showing similar messages in future.

2. Allow the user to request human help when relevant
When putting these interactions together, I typically include options to “Raise a ticket” for the user, rather than them continuing to help themselves. When that ticket is raised, you know what stage in the process they were at. You know what the trigger was that brought them there. You can raise a ticket rich in context information to help the service desk agent to fix the issue more quickly – especially as they can use Tachyon instructions to do so. Use all that richness when you create the incident/request/whatever.

3. Allow the user to opt-out of future prompts
You can please some of the people some of the time – but some of the people won’t want to be interrupted with this type of pop-up again. Use Storage.Set() to record if they are opting out of this notification type, or ALL future notifications.

4. Allow the user to trigger these prompts/assistance for themselves, on-demand
Sometimes you may not want to deal with (let’s say) a low disk space issue RIGHT NOW, but you may want to go back to start the wizard/interaction again at a later time that suits you as a user. Allow users to trigger interactions through self-service, 1E Shopping perhaps, the ServiceNow catalog/portal, or maybe even the Virtual Agent. All of these can interface easily with Tachyon, so leverage that and empower the user to start clearing down disk space or identifying apps which are impacting performance BEFORE it reaches the trigger point – or at any time they chose to.

There are also useful methods like Interaction.GetInteractionState(); which will show you how long it has been since a user logged in, last moved the mouse, if their device is in a good place to receive a notification, etc. Think about combining that with your own notification workflows.

As always with Tachyon, they sky is the limit and you are bound only by your own imagination (for better or worse!) when it comes to creating instructions, rules, and workflows. Remember why Clippy was so unpopular, leverage the tools and techniques here to help you avoid some of those same pitfalls!

Finally – if this was of interest to you, why not check out the on-demand replay of the Tachyon Masterclass from our latest Work From Anywhere conference!