At most organisations a lot of useful information remains in the heads of individuals or is buried in their local email inboxes since the ‘knowledge workers’ see no simple and appealing way to share it otherwise. To mitigate this inefficiency more and more companies set off to establish ‘social platforms’ like blogs, wikis or social networks within their intranet. Many platforms, however, fall short off the expected participation to become eventually abandoned and, worst of all, leave some burned grounds for any future initiatives. Users quite often complain that the platform is too cumbersome to use, that they are ‘too busy’ to deal with it or they just do not see a purpose or (personal) benefit. Consequently they rather stick to their ‘well proved’ habits of sharing information on demand via email, attachments, shared drives, local office documents and alike.
It is often stated that the successful deployment of social software is a question of the ‘right’ organisational culture and the ‘right’ leadership. To which extent this is really a prerequisite is still under discussion, but you are definitely doing much easier tackling these ‘soft factors’ after spending serious considerations on some rather technical and conceptual basics of your platform. Moreover, you counteract any excuses for non participation because of (perceived) technical shortcomings.
First of all, each corporate system should (at least indirectly) contribute to a clearly stated business objective and should therefore be integrated in daily processes as much as possible. This is true for ERP systems as well as for any social collaboration platform — even though actual usage pattern will be ‘emergent’ in some way. Needless to say that basic technical requirements like information security, reliability, availability and performance are crucial also for any social tool since any weakness will jeopardize the trust of the users. It is the users who power your platform and who will eventually decide on it success. Hence, there should also be at least a rough idea about the intended user base and their potential personal benefits. For their (long term) participation the following issues are key.
How do users get content in?
Most platforms offer a more or less comfortable web interface to create or edit content. While this requires just a web browser and might be the preferred way for some, it still feels very unfamiliar or too inconvenient for a lot of people. A separate manual authentication process adds another motivation killer. To meet the different preferences of your users the platform should offer various ways for contribution, e.g. via a local desktop client and a client (or ‘app’) for mobile devices. The success of Twitter is to a large extent based on the many possibilities for accessing the platform. In addition, users should also be able to use a client they already have: Particularly for forums, blog or microblog like systems a publication mechanism via email can be a killer feature. The success of posterous is the best example, including features like automatic tag/ category extraction.
Tags and links are a powerful technical concept for organising and structuring content. As a major benefit they free contributors from the burden of knowing the ‘right place’, e.g. the right subfolder in a predefined structure, before being able to contribute anything. Structure and context are rather emergent and are based on the ‘filter on the way out, not in’ principle. Lowering the barrier for contributions as much as possible should be one of the major design goals to achieve the desired participation. Technical supportive features can help you a great part of that way.
How do users get content out?
People will only contribute to a platform if they know that there are a sufficient number of potential readers, i.e. if they have an audience. Let’s face it, a gain in corporate visibility and recognition are major motivational factors. Thus, the platform should make it as easy as possible for any (authorized) individual to consume the information of his or her interest. Like in the section above, the preferences on means and ways are divers, so that the system should offer a variety of desktop and mobile access options leaving the individual choice to the user. That includes particularly configurable signals about updates on topics the individual is interested in and to increase awareness.
For this purpose subscriptions to feeds (RSS and alike) are widely used on the Internet, but have not really taken off in the corporate world yet. Thus, it is necessary to give users some guidance how to integrate feeds in their email client, web browser or a local client to set up a personal information dashboard. At best, your intranet offers individually configurable start pages with widgets displaying feeds. With email being still the major means of office communication the possibility to subscribe for updates via email can be a killer feature. At a recent conference a company reported that they were eventually able to ‘close the loop’ with a simple to configure feed service delivering updates or summaries right to your inbox. Hence, even with the introduction of the new platform ‘well proved’ habits, e.g. email distribution lists, still work, i.e. there is no pressure to change from one day to the other. Rather everybody can adapt and explore at his or her own pace. Most importantly, there is no reason to bypass.
Besides getting automatically informed about updates it is equally important to find content right when you need it. Enterprise search is an ongoing (and very complex) issue and still many report that it is easier to locate content on the Internet than on their local intranet. With an increase in participation there is some evidence that taking into account link topology, access frequency, user
ratings and recommendations can definitely improve the ranking of search results to find more quickly what you are really looking for.
Addressing real office needs
There are at least three reasons why most office workers prefer traditional office tools over web platforms: (1) easier too edit content (not everybody wants to learn wiki markup or HTML) (2) offline accessibility (“I want to work on it/ read it while I am on the train.”) and (3) looks nice in print and is easy to distribute to externals. Particularly free open source collaboration tools were developed by rather techie people for whom those aspects were of lesser importance. In a real business context aiming for broad participation things are a little bit different. When designing your platform you should explicitly address these concerns and offer appropriate solutions.
Conclusion: Addressing the need of your users with the right technological features should be the starting point of any new corporate communication platform initiative. Users are rather lazy and for most of them a tool is just a tool to get their job done. In plain English, if it is not easier to use than email they just won’t use it!