We strive to improve our intranets, adding functionality and honing usability. Intranet Managers are inundated with feedback, requests for features and criticism; everyone has an opinion about the intranet!
Even when we implement features and functionality at the behest of stakeholders to meet the needs of the business and intranet users, there’s no guarantee that people will care. Sometimes we launch a new feature, only to see it misused, or worse, go unused. We should be able to predict if a new function or feature will be useful, usable and adopted, but it’s difficult. Ask any marketer involved in product launches – Zune anybody?
There are a few basics we have to tick off; we need the intranet platform to support the new feature; we need the new feature to be easy to use – completely usable – and we need written governance (however brief) to layout the ownership and purpose of the feature. It should look something like:
Good Tech + Good Usability + Good Governance should = Good Usage
How can we fail? If we’ve got a modular intranet then it should be especially easy to just plug in a new widget!
But ‘good usage’ is relative; different audiences have different needs and perceive / gain value from features differently. We might be looking for a 90% adoption rate, but why? A 5% adoption for some features may be considered ‘high’, and such adoption by active users can benefit 100% of the business. If 5% of staff regularly blog about their tips and ideas about customer service, product development, intranet use and tips for effective presentations then everyone benefits. Not all features need to be used by absolutely everyone in order to be considered a success.
“Something can be brilliantly executed, but valuable to a small audience. Maybe measure usage as a % against theoretical max.”
Jonathan Phillips
There may be real reason why the new feature isn’t adopted, or proves unpopular. User Acceptance Testing may not always be appropriate, but focus groups (that don’t become ‘group think’ experiments) can help you consider all the angles.
People might have found a different way to create the same benefit with an alternative system or feature. While you might love the new feature you’ve rolled out, it may be prudent to support the popular feature, unless of course it must be retired / shut down (like unwieldy legacy systems). People are going to use whatever seems easy, convenient and most beneficial to themselves; they’re not going to switch to a new system without going through ‘change pain’ unless they can experience immediate improvements to their ways of working.
Then again, there may just be a lack of awareness about the feature and its benefits; ‘good governance’ should include good communications, but such tactical matters can’t be guaranteed without a comprehensive long-term communications plan. Too often we ‘launch and let go’ – meaning we promote the new feature in the run up to launching (over egging it perhaps) and then step back and move on to our next project. We don’t maintain momentum, we fail to follow through, and we then wonder why people haven’t heard about our wonderful thing-a-majig three months later.
People need to be shown (not told) the purpose and benefits (to them) of a feature, through examples and narratives. Not only do we need to embed the new feature into the heart of the intranet through regular use ourselves (how many times have you launched a themed blog only to have the articles dry up after three weeks?) but we need to apply good communications theory to the subject. We need to tell different audiences in different ways in different formats, multiple times.
Thanks to @jenetics, @jencutler1, @stuartamckenzie, @simoneverest and @digitaljonathan for their thoughts on this subject. I take credit for any errors or poorly worded ideas herein.
[Wedge]Photo credit: cogdogblog
If you’d like to share or tweet this article, the short URL is: http://kilobox.net/2274
The real reason ‘cool stuff’ doesn’t gets used is, as you point, down to utility.
Its a trueism that if the feature isn’t useful, people won’t use it.
The only bit I’d disagree with you on is how to find out what people really need.
Focus groups, even really well run focus groups, don’t help. Gerry Mcgovern does a good job of explaining why: http://www.gerrymcgovern.com/nt/2010/nt-2010-11-01-Focus-groups.htm
I’d be happy to delete ‘focus groups’ from my vocabulary and replace it with ‘need discovery’ by watching what people do. There is a need to discover what pains people, what doesn’t work, what ticks people off. This is very different from asking people ‘what would you like’ which never works, agreed. I wish more time was spent discovering what people do in their day jobs and where the pain points are.
I hope my article (above) is about use and purpose, rather than focus groups.
I wouldn’t go as far as quitting focus groups as long as one remembers that focus groups are for brainstorming, not problem solving
I think Focus Groups have a place but need to be skilfully run and participants have to be carefully managed. Strong personalities and opinions can many times overshadow others with great ideas but timid voices.
Workplace Observation (or need discovery) is one excellent method of identifying user requirements (additional methods well explained @ http://www.steptwo.com.au/papers/kmc_needsanalysis/index.html). It is very important though to ensure that Intranet functions and not implemented to replace manual tasks just because you can. Some people might work better with their favourite contacts pinned to their cubicle wall rather than the ability to set up an electronic My Contacts list in the Intranet.
Nice piece Wedge. Always enjoy reading your posts.
Hi Wedge,
Great article. I think there is a place for focus groups. However they should be used once a trend analysis has been completed to see what sort of ideas you want from your focus group, otherwise it’s like herding kittens. This can be based on your stats and feedback, both structured and ad hoc.
I also think the importance of communication can’t be underestimated, both at launch and as a gntle reminder months later.
Some featues are fortunate enough to quickly gain a critical mass as they make something easier to do and the time of launch happens to maximise the opportunity. Other bits may go round like a piece of sushi on the conveyer belt until someone is finally brave enough or encouraged to nibble on it. Leave it too long and it will ‘go off’ and end up canned.
Something I’ve found helps a feature be a success is involve small groups to test a beta version. Let them do it in a controlled environment, ask more questions about their day to day job and let them feel like they own it. Often they will go back to their teams and want to show it off. The ‘it’s mine and made for me’ can never be underestimated.
Keep up the great work.