The Challenge of User Adoption with Small, Remote Teams


We’re web workers and for the most part, we’re comfortable with technology. We’re not as put off as the typical user is by having yet another login username and password, or a new line of icons in our toolbars. Bring it on, we say, we like to play with what’s new and interesting on the internets. It’s all about increasing our productivity, and we’re usually not afraid of trying something new in the process.

If you work with a team of folks who have the same attitude, that’s wonderful. Chances are, you work in web development. But what happens when you work with a team, who while comfortable with email and web surfing, wouldn’t know their ActiveCollab from their Zimbra? Collaborative software that you use alone is a bit like clapping with one hand.

You have a Basecamp account, but your team members still insist on emailing you directly instead of going through the site. You have all your files on OmniDrive, but you can’t find that important spreadsheet because Mary still has it on her computer and she’s on vacation. You use a tool that publishes a RSS feed of changes, but your colleagues still email you constantly asking for updates. Your users love reading Wikipedia, but are themselves resistant to using a wiki to collaborate on projects.

It can get frustrating when colleagues fall back on old habits that are not potentially as time- and cost-effective as the new tools that the social web can bring to the table. How do you convince your co-workers or clients to not only try a change in their work process, but stick with it after the novelty has worn off? Do we have to become scholars in change management just to get people to update a wiki?

Last year, Suw Charman outlined some user adoption strategies that may have some relevance.

There are two ways to go about encouraging adoption of social software: fostering grassroots behaviours which develop organically from the bottom-up; or via top-down instruction. In general, the former is more desirable, as it will become self-sustaining over time – people become convinced of the tools’ usefulness, demonstrate that to colleagues, and help develop usage in an ad hoc, social way in line with their actual needs.

Top-down instruction may seem more appropriate in some environments, but may not be effective in the long-term as if the team leader stops actively making subordinates use the software, they may naturally give up if they have not become convinced of its usefulness. Bottom-up adoption taps into social incentives for contribution and fosters a culture of working openly that has greater strategic benefits. Inevitably in a successful deployment, top-down and bottom-up align themselves in what Ross Mayfield calls ‘middlespace’.

While aimed at the enterprise, Charman goes on to outline concrete tips that are also applicable to smaller teams and are worth a read.

Some simple tips that I’ve found effective in remotely encouraging user adoption of social/collaborative tools:

Understand your team’s work habits. Do they already use Instant Messenger clients? Do they use Firefox or Opera, or are they still using Internet Explorer with the default home page? Do they already use other tools that may conflict either by process or design with the tool you want to introduce? If they use Outlook, have they customized it to their liking? I know my co-workers well so I know how off-the-beaten-trail I can go. I know that everyone on my team is very comfortable with content that is emailed to them, so collaboration tools that are email-centered are more successful. It is easier to get someone to send an email to an address to post content to a collaborative site than it is to get them to remember to visit that site on a regular basis. It may be very different for the people you work with and you have to tailor your expectations accordingly.

Deploy slowly. Resist the temptation to tell everyone about something that is so cool they have to start using it immediately. After a period of testing a collaborative tool on my own (using dummy email accounts), I share it with one colleague that I feel would not only benefit from its use but is also willing to help me test out the best processes for our group. Then I slowly introduce the concept to others, documenting the questions and concerns carefully as I build the support documents for our team. It took months, but now most of our team instinctually loads Salesforce in their browser to assign tasks to others or to check calendar availability. It didn’t happen overnight. Don’t change for the sake of change. Make sure the tool truly adds value.

Ask the tough questions. Technologies come and go. Don’t be lured by pretty design with AJAX navigation. Do your research. Send email to tech support. See how fast they answer and if the answer is satisfactory. Make sure any data you put in can be pulled back out easily. You don’t want to encourage your team to adopt an application only to have it go south.

Be prepared to offer user training. Don’t rely solely on the help files provided by the tool. Don’t assume that because you picked it up quickly and you read the developer’s blog or forum that everyone else will. You have to be willing to put the time in to do some hand-holding. You want to show your team how they can use the tool to answer your specific business need. As tempting as it may be to show off all the cool things that can be done with the application, limit your demo time to just what it is needed for your business. It is better that your colleagues use the tool consistently (read: by habit) to collaborate on one small project, than they know everything that is possible in the first lesson. Once the tool is ingrained, they’ll explore other uses on their own.

I’ve found that a combination of on- and off-line training tailored to individual need works best. Start by using web conferencing software to host a live demo of the application, where your co-workers/team can see you working through a specific process unique to your business. Prepare tutorial documents with step-by-step instructions, including screenshots, using your own projects and settings. Try to anticipate where the challenges will be. It isn’t about getting your colleagues to buy into the application. You are not selling the technology. You are persuading your co-workers to adopt a new process that can increase overall productivity and project success. This is the make-or-break point. Keep it simple and be patient. It takes time to become habit.

Be consistent. If you want your team to adopt a wiki for project management, then don’t send a lot of content through email. Write it to the wiki and send colleagues a link. Gently remind your colleagues to do the same. You have to set the example.

Look for tools that will be easier to adopt. It’s half the battle. If an application requires a complicated registration process, only works with a single browser or has no email functionality then the chances that a less-technical team will adopt it drops dramatically. Look for tools that work with applications your team already uses so they won’t have to manage yet another login. Many collaboration tools are designed for enterprise or small businesses where management can dictate a common denominator or enforce adoption. Web workers aren’t often that lucky. We have to adapt to situations and users we can’t always control. Don’t look at tools with web savvy eyes or based solely on your own work process. Imagine that you are a team member who is using their computer right out of the box. Try to anticipate barriers and workarounds.

What has/has not worked for you? Have you tried a great web application only to abandon it because you couldn’t get others to adopt it into their own workflow? Why do you think organizations have been slower to adopt wikis and RSS for collaboration as compared to other new technologies?


Inside Sales

Just want to make a comment about being consistent. Using the wiki is such a good idea. When you try to send everything through email it gets so disorganized and messy.

Paula Thornton

Gadzooks! User training? When did you ever get trained on Google?

The key to adoption is good experience design. That’s not the same as good UX design (but you can be lucky and get the same results). Not all UX practitioners are savvy enough to question the fundamentals of a concept altogether from an economic perspective: does it add value, does it add relevant value?

In over 20 years there is still a high-value function that most high-profile word processing users need (and that Word Perfect had in place that many years): parallel columns (the ability to have two things side-by-side and behave as a single unit down the page — different from snaking columns). The only way to achieve it is in tables and the minute you put text into tables it takes on behaviors and limitations you’re not prepared to deal with.


Thanks Judy. My colleagues from the teachnical department used the same strategy when they try to convert us to use Gmail for work in stead of Outlook. However, it depends on a corperate culture. It’s hard to kick an old habit. If you are patient and supportive, they will come around.


As a member of a software team that specializes in the development of online communication tools which shall go unnamed because I don’t believe in shameless plugs, we have attempted to create intuitive interfaces that lead the user in a sort of wizard way which we refer to as “Initial State” screens, but even that is not enough. We find that users still want us to manually train them in either a face to face visit to their campus or in a web based training. The bottom line is that if you don’t get the buy in, and the best by far is organic proliferation of your apps, they will die a slow and painful death.


I just finished going through this with google apps for a volunteer board I’m working with. The handholding is essential. For many of us (at least me), that’s the least enjoyable part of the work. I’ve tried to get volunteer teams like this to make changes in the past without the extra guidance and it just doesn’t work. It will be worth the extra effort in productivity that you squeeze out of the initiative, and you get karma points with the people you are helping.

As long as you’re nice about it….


A very pertinent article! I am singular alone in the world of web / tech in the office – my one success so far is getting people to use Basecamp, which is proving a real success. I am going to champion this for a few months and then seen what happens…. wish me luck!

Philippe Borremans

A lot has to do with the corporate culture in place; do people naturally share information or is there a culture of not trusting other colleagues…?

I am convinced that people in general do not like change but that some “tactics” can work:

Use case studies with clear and understandable ROI: show and tell them how it worked with others with a similar challenge. This can go as far as taking examples of competitors in the same industry, people in the same mind set etc… Return on investment should be explained in very concrete terms like “faster”, “more productive” but with percentages and figures is that’s what they understand. Example: explaining wikis by telling them exactly how much time and money they will save by using them in comparing with the current “email” culture.

Use “champions”: every company has highly regarded individuals; sales heroes, the communicative manager, the fixer who makes it all happen etc… Try to engage them and lead by example. Getting to a “if he/she does it that way then it will be a good way to go”.

Include people from the start: if a decision to start internal blogging has been made, then engage employees in the set up of internal guidelines (through a wiki) and do not impose guidelines which have been created by corporate communications and the legal department.

Definitely go for hands on, face to face and very practical training.

Just my 2cents.

PS: great blog !


We have been trying to standardize the use of wikis both internally as well as for most customer project communication.

The trouble with wikis and other 2.0 software is that things like tags and search only start to become useful after a lot of content is in there. Rather than asking the team to get to that point of heavy usage, the approach I’ve seen work is to ask them to only use the app for their very specific tiny areas, and to let them measure their own productivity improvement as a result. These Islands of contributions could later be linked together in the wiki.

This involves finding ways for the users themselves to see the value of the app in their own work. Prior demos or trianing helps very little, but once you get them to run atleast one cycle of tasks through the app they will start to appreciate the app more. Adoption is easy after that, provided the app truly does make things faster or easier for them.

So how do get them to go through that cycle? They should not feel that they are learning how to change ALL of their existing workflows around a new app. Maybe you can evangelise and lead this as “a way for this specific project team to work together for this specific set of tasks” until you can unify them to run only one work thread end-to-end on the app.

Comments are closed.