I wholeheartedly agree with what Jordan Frank says in his post “Pros and Cons of Emergence”:

  1. A marketing plan to introduce the technology and how it may be used.
  2. Appropriate scaffolding and careful seeding of content… an empty tagging system will prove too much of a blank slate for users more accustomed to the structures of conventional systems.
  3. Coaching and mentoring on how to use selected technologies to accomplish their goals. This coaching would focus on working out strategies for how to use the technology to accomplish specific business and organizational goals.


I couldn’t have put it so succinctly, but that’s pretty much exactly what we did here at NHS Orkney when introducing our blog/wiki/newsfeed technology. One detail in particular caught my eye:

Enterprises are limited in scale as compared to the web, but can benefit quickly by establishing best practices, tag templates, and patterned use cases which make it easier for users to adopt the technology and to get traction quickly as they move between wiki and blog spaces to perform their regular communication and content management activities. Detailed taxonomies are too rigid, but enterprises will benefit readily by synchronizing tags between wikis and blogs. One simple example might be agreeing on the tag “Status” vs. leaving users to the task of creating an array of similar tags like “Status” and “Update”
Given appropriate scaffolding, software interface elements such as those described in Making Wikis Work in Business – Leading Users to Water can help to nudge late adopters in the right direction

We made a lot of effort in advance of rollout to provide users with some initial structure. The hope was that this would result in more consistency across the whole site, but also make users more confident in the initial stages. I’m always aware – as a programmer and as a sysadmin – that most people will take the easiest option when doing something on the computer. (Of course that’s not always the shortest path – many people prefer to stick with their established practice no matter how bizarre or time-consuming it is rather than learn something new!) So if you want people to do things in a particular way, make it (a) the most obvious (b) the simplest and (c) the quickest route, in that order of priority. We pre-populated our Traction server with projects, content blagged from the all-staff email list, and labels which we thought would be useful (especially where those labels were useful across all projects so that the labeling was consistent). When a user first uses FeedDemon/Newsgator, they are automatically subscribed to a dozen newsfeeds to get them started. The feeds include our internal Traction stuff, but also the local newspapers and the Scottish Exec’s health newsfeed.

[An aside: I think we programmers too often assume that speed of data entry (or content creation) is an all-important factor in the perceived usability of software. But you have to consider carefully how regularly the user will be using your software. If the product will be used all day, every day by bank clerks for instance, speed of operation is imperative. If the product is used by itinerant healthcare professionals, speed is much less important than “obviousness”. The UI may be super-slick and speedy, but if it’s not obvious to a less-than-regular user how to achieve their goal then the user will lose time and the product loses credibility. If the UI trades usability for speed, new/occasional users are made to feel stupid and slow – not a good thing at all.]

So those are the techniques we use to “nudge” our users towards adopting Traction and NGES, and I try to keep these principles in mind when writing and critiquing my own software.