The Dirty Secret: End Users do not use the Tools you buy for them

There is a dirty secret in the world of technology. No one wants to talk about it. Not the vendors. Not the buyers. No one.

And yet, the secret must be told. It is the elephant in the room, and someone needs to shout out and say “look, a bloody great elephant is in the room! Over there! Right a bit… yes, there!” So, in the absence of anyone else stepping up, I’ll play elephant spotter.

The problem with most technologies purchased by organizations is that the end users (i.e. ‘people’) either do not use the tools at all, or use them to a tiny fraction of their capabilities.

For example, I was chatting to a company selling e-learning solutions (I won’t name them). Their real worry is that their clients do not renew annual contracts if / when they discover that only 10 people out of 200 used the tool at all in a 12 month period. So it is better not to provide the use information at all, and talk about ‘soft benefits’ (and obviously ignore the elephant).

Another example is blogs that allow comments. Yes, there are features that allow people to comment on a blog. Therefore, technically, a blog is a collaborative application. And yet, if you do any form of the most basic research you find that people do not comment on blogs, and if they do it is a tiny fraction of the total readership. A 0.5% response rate does not count as a success. It doesn’t.

My own blog, InnovationBBL, is a real example of this. I have allowed comments since I started. I have personally put in around 90 posts, and I have received around 30 comments. 20 comments were spammers trying to use my site to boost sales of Viagra (whatever). The other comments were brilliant and substantive. However, that would give a collaboration rate of around 15% (percentage of main documents that receive one or more comments). Moreover, in terms of blog readers, with around 600 readers a month (and rising again, now that I have restarted posting), there are only 2 authors who have posted comments in recent months, which gives us an active participation rate of 0.3% (percentage of readers who actually make a contribution).

I remember going to a workshop on blogs back around 3 years ago just outside of Boston. The speaker was insistent that blogs were a great collaborative tool. When challenged to prove that it really was, he claimed there was no research to show the contrary, therefore it must be true. In the background, I did a quick run through a random series of public domain blogs (for blogs on blogger, you can click on ‘next blog’). After 20 sites I had found the following:

  • 90% of blogs allowed comments
  • 5% of blogs had any substantive, non-spam comment in the last four weeks

At the very least, small data points like that have to make you think. The tool is meant to help you collaborate, but people are not using it, or they are using it all wrong.

I believe that the technology challenge of the next five years will be to focus on boosting actual, productive use of computer systems. New software development tools make it all too easy to invent new software products and features. Applications can be created in less than a week, and with the internet, reach a potential audience of millions. And yet, if people do not use the tool, who cares.

IT departments and vendors are largely responsible for this. I would though hold business leaders more accountable that the poor IT group. IT departments tend to follow orders. A business leader may suggest that he or she wants their business to become more collaborative, and so the IT group gets to investigate collaborative systems. When the resulting system is implemented and not used, the business leader must be held accountable, honestly accountable.

It should not be permissible to use one of the 20 common excuses for lack of adoption. Instead, prior to a program introduction, you should perhaps give the business leader and their purchasing team a check list of 20 excuses that will be used to explain future failure, and get them to sign off on the ones that they agree NOT to use when things go pear shaped (London-speak for things not working – not sure why though…). So, for example, if they agree that they agree not to fail because they forgot to coordinate training with the live availability of the tool, then if they fail for that reason, they get a slapping (possibly with a wet fish of some type, halibut perhaps).

The real damage – and the reason why this secret needs to be exposed – is that companies are wasting millions on IT solutions that do not get used, and honestly have no hope in hell of ever delivering the benefits used to justify the purchase. They are wasting millions in outright expense, and millions in wasting people’s time and energy.

A final thought. If you do not believe me, go and poke around your company’s knowledge management system, blogosphere, in-house wiki, and see for yourself how actively they are being used. Prove me wrong. Share your findings. And, final final thought, please do not feel bad if my view has exposed the dirty secret in your firm. We are all to blame.

One Response to “The Dirty Secret: End Users do not use the Tools you buy for them”

  1. This is an important issue, and it’s one we’ve been thinking about a lot at our company – we design business and research software. Our solution is to involve the end users more in the development of the tools we want them to use. Part of the reason the people don’t use tools is because they don’t do exactly what the people want, or they don’t do it in the way the people want it done. Extra clicks here, awkward organization there. And this is because the software is designed by someone who isn’t going to use it, and then built by programmers who also aren’t going to use it. So by the time the users get to try out the tools, they’re 90% effective – but 10% irritating.

    We built a tool, the Dekstrus DNE, that lets you build working software on the fly (without extensive programming experience), and test this software on the ground as you design it. The working, testable software is a by-product of design, so you can have real users employ it with real clients even before you call up the programmers. Because real users can test it with real clients right away, valuable feedback gets back to the designer immediately, and can be incorporated directly into design rather than “maybe” incorporated into “a later release”. Designers get feedback when it matters: while the software is being designed. Once the process is designed and tested, then you can call in the programmers to build a final version with your own look and feel.

    We believe that if companies use the DNE to design the software they use, they’ll be able to come up with solutions that their people will actually use, because their feedback helped to dictate the design.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: