Unreliability and Abandonment

One of the more frustrating experiences around Amazon Echo’s killer app, music, is when it becomes unreliable in its response. “Alexa, play Rawhide” should consistently come back with the theme for Rawhide by Franky Lane. If a new hit called Rawhide came out by Lady Gaga, I’d understand if the device switched, but that’s not likely.

However, the response to a regularly played song from an Echo can be inconsistent, ranging from being spot on, to playing a sample, to playing the completely incorrect song. The internal discordance felt when anticipation is met with disappointment is painful. There’s only so much pain that someone will tolerate before changing their behaviour to avoid pain.

In the case of the Echo and music (or any device and unreliable actions), the result is the abandonment by the user of that feature. Once a feature is abandoned, it’s very difficult to lure a user back to it — there’s too much baggage.

So what can a product designer do? First, create an early warning system for features that are not being engaged with in a designed fashion. This might first involve manually sifting through user logs to flag issues. Second, ask users if they’re getting frustrated and what are the mechanics of the interaction. Third, fix the issue. This could mean pulling the feature or holding back larger deployment or pushing through a fix.

It’s a small tragedy when a great and potentially killer app gets a bad rap because of early problems with implementation. If the feature is critical to the product, best to build systems around it to prevent users from abandoning it.