UI Stockholm Syndrome

stockholm_syndrome_compLady2.jpg

Stockholm syndrome: Noun: Feelings of trust or affection felt in some cases of kidnapping or hostage-taking by a victim toward a captor. Are you holding your users hostage?  Is your application so hard to learn that users are afraid you’ll change it?  Do they not make any adjustments to the app out of the box or after they get their basic needs met for fear they “might break it”?  These kinds of interfaces often have loyal user bases who have been kept in the room long enough to learn to get along with the application.  But products with long, steep learning curves risk alienating new users. The accumulation of lost time spent on regular tasks cuts into efficiency and makes the tool vulnerable to new competitors.

I love it just the way it is.

Usually hostage-taking applications are mission-critical production apps – they’re running supply chains, medical billing or banking transactions.  They’re tracking parts, DNA or versions of a document used by ten people.  Some applications have such a large market-share that they’re difficult to migrate from, such as the Microsoft Office Suite.

These applications take users a long time to learn – weeks, sometimes months, and even longer to get it working the way they want it to.  Once a user has learned the app, they are beholden to it.  They’ve spent days understanding it and contorting to its ways.

It’s not uncommon in our user research to spend an hour watching a user struggle with a product and then profess a love for it.  They say “Don’t change it!  I like it the way it is!”  They are hostage.  They look lovingly on a challenging interface because at this point it is all they know.

It calls for an intervention.

You have to start by finding out what’s working and what’s not.  This goes far beyond reviewing support issues and feature requests.  Have you watched both new and current users work with the product?  Use in-depth research to guide you.  This user research is not taking users at their word, but rather looking deeply into their environment, tasks and behavior to arrive at new solutions to old problems.

Based on this research and company and market conditions there’s usually a choice: make tactical changes that incrementally improve the product’s core workflows; or, go for the bigger risk and potentially larger win – change the way people fundamentally interact with your tool.  This may be changing the navigation paradigm, moving key tasks to mobile platforms, or automating data collection and connection on the backend so tasks are eliminated entirely.

If you go for the big change you need buy-in from the top of your organization that they will support and fund the changes through the major design and development effort required.  Stakeholders must also know that they will have to ride out the initial howls of disbelief from users who are pried from the clutches of the existing system they spent so much time learning.

Let your existing users know that changes are on the way.  Give them a chance to accept their upcoming new life outside the confines of the current application.  Use existing communication channels to talk about how the changes will make users’ lives easier.  If there is a public user community, it may help to release the new version to a small group of champion users who can spread the word that the new system is not only not the end of the world, but a big improvement.

As with treating Stockholm syndrome, it may take some time for long-time users to let go of what they’re used to. If you’ve done the right research and prioritized users’ needs, the ease of use will quickly win over existing users, while opening up the application to a wider audience who expects to use a tool, not be hostage to it.