Lee’s post originally appeared on the Headshift blog.
The user interface isn’t that important you know. It’s just an internal intranet application that will be only used by our employees. Just focus on the business logic and make sure that everything is locked down for security.”
It’s unfortunately something that I heard over and over again in my previous client engagements as a systems integrator and solutions architect. Somehow, when we are talking about IT applications for employees, all of a sudden user interface and user experience don’t matter.
A recent tweet from Rena Patel, from Capgemini’s UK PR team, states the obvious: “Internal employees are also clients.”
So far, the social software industry has often separated social engagements in roughly two flavours:
I see in my current client engagements at Headshift that this artificial boundary gets more and more blurry. To what extent is an external customer community different from an internal employee community?
Think about it, they serve similar goals:
… and they often suffer from similar (potential) problems:
So why is it then that we don’t put the same effort and value in social software / community solutions for our employees as we do for clients? Why is it that we want to have the best for our own children, but not for our own employees?
Many companies that are experimenting with introducing social collaboration tools for their employees start with low-budget, under-the-radar projects and it often starts with putting a software package in place and see what happens. There are roughly two outcomes of this:
In both cases you have a problem, the former is a luxury problem, the latter is a sad reality for many projects. So, how can you safeguard yourself from the above-described problem, without breaking the bank?
The first and most obvious question you should’ve asked yourself before starting this Enterprise 2.0 project (heck, you should ask it before doing ANY project at all): “what does the user want?”. This can be done by running a workshop with some business stakeholders and (most importantly) end-users from the field, and can be further extended by stakeholder interviews.
Knowing what the user wants is quite crucial to tackle both problems. If you know what your users want, you can more easily control the growth of your community and steer it in the right direction to speed up the tipping point in a controlled and more predictable way. Knowing what the user wants, helps you better understand why certain things don’t work or intervene when your community lacks adoption.
Depending on whether you are a “bottom-up”-evangelist or a “top-down”-believer you might or might not agree with what I just said. I’m a big fan of macro-economics and the theory of Adam Smith’s invisible hand. However, I’m realistic enough to see that this laissez-faire approach works very well in an artificial text-book environment, but when applied in reality it has certain “issues”.
At Headshift and the Dachis Group, we are a strong believer in the intentional creation of such social environments in companies. This means that we strongly believe that the user is central and that they drive the success of the community (bottom-up), but that having a good and strong community management (top-down) tremendously raises the quality and success of your community. A very famous example is the SAP Developer Network, led by Craig Cmehil (@ccmehil), which is a prime example of a thriving collaboration community.
As the very famous Cluetrain Manifesto states “business is fundamentally human”, so we need to stop treating employees as “resources” and start seeing them as clients with their own interests, desires and drivers. Once we made this mind shift, perhaps making the business case for focusing on user experience for internal intranet tools is more easier to make…
Enjoy the end year festivities and all the best for 2010. My motto for the coming year will be: “Humans For The Win!”