SharePoint is a platform that was designed by a lot of developers, often working independent of one another, over a span of several years. All that time, they were working toward the admirable goal of providing business users with pretty much any kind of document-sharing or collaboration functionality they could think of that might improve the efficiency of their processes. But, for most of this time, they were thinking too much like software engineers and not enough like business users. The result has been a vast and impressive set of tools that it’s often really hard for anyone to figure out how to use.
If you do a search for “SharePoint user adoption,” you’ll find endless materials going all the way back to Microsoft’s initial launch of the platform. It’s not like the tools are so difficult to use that no one can learn how to effectively integrate them into their work routines. After all, around three-quarters of Fortune 500 companies use SharePoint in one capacity or another. Still, the simple fact that adoption has been such an important topic for so long tells you that there’s a usability issue.
The problem isn’t necessarily with the platform itself—implementers often have the same focus on extending potential functionality at the expense of immediate business applicability as early SharePoint designers did. But the whole mentality of “If you build it with enough cool functions, they will come” works just fine with other technologies. Have you ever attended a user adoption event for email? Actually, email is often the document-sharing tool workers turn to—or stick with—when SharePoint proves too frustrating.
And this brings us to an important principle: people will use a new tool if it’s simpler than the older tool they’re already using. Of course, they have to either be shown or discover on their own how easy it is.
So, if you’re beginning a SharePoint implementation, what are the main tricks you can apply to your information architecture to ensure adoption once your solution is deployed? There are basically two:
1. Make the tools work like others we’re all already familiar with.
This is one Microsoft has already given you a head start with. For instance, take a look at Yammer, Microsoft’s enterprise social media platform. Look familiar? You’ll never have to read a blog post on Yammer user adoption because people already know exactly how to use it. That’s because the user interface looks almost exactly like Facebook. Then there are all those Office tools we know so well. Since Office 365 makes cloud services more integrated, you may find yourself doing things like working on a document at the same time as your colleagues, sharing, saving, managing permissions—all through Office Web Apps. What’s actually going on here is that you’re running SharePoint in the background and probably don’t even know it.
The idea is that you essentially front-end your platform to work like something with a familiar interface even as you harness SharePoint functionality behind the scenes. Another good example is Delve for Office 365, which uses so-called “machine-learning” to predict which documents you’re going to be most interested in and presents them on a template that looks an awful lot like Pinterest.
The things that you can do on your own when you’re planning your implementation all have to do with keeping processes users are already familiar with in mind. People sign in to social media sites to get updates and share their thoughts and experiences. Does your SharePoint dashboard provide access to relevant, useful news? Or does it bring workers to a picture of your last company picnic? When a worker signs in, do they see a list of things they were just working on? Or do they have to go searching? Is the Search function set up to work like Bing or Google? Or are you making your employees learn new tricks to perform routine tasks?
2. Treat the project as an ongoing, multistage process.
Okay, so this isn’t really a “trick.” This is good old-fashioned planning, design, and follow-through. First, if you want to make it easier for people to do certain tasks, you need to have a good idea what tasks you should focus on. SharePoint provides so many tools you’d need hundreds of pages just to list them. You can’t blame workers for getting lost without the proper information architecture. Planning begins with figuring out what challenges each type of worker is facing so the platform can be designed and implemented in a way that actually makes their lives easier instead of more frustrating.
Once you’ve created use-cases around what workers will actually be doing with the tools, you still need to keep everyone informed about how the implementation is progressing, keep them engaged with the project more generally as it proceeds, and have a deployment plan in place before launch. Workers shouldn’t feel like the technology is being forced on them. Keeping them involved in the process will make them feel like they have a stake in its success. And it’ll send the message that the tools are being put in place for their benefit as much as management’s.
Training and internal marketing are essential as well. Even if you set up a dashboard with all the most amazing tools for making everyone’s workday a breeze, they may still keep on using whatever tools they relied on before if you don’t show them how easy the new stuff is to use. Ideally, everything will be as simple as email and Facebook, but even these can be a little tricky at first (if you remember).
So your IT team needs to get away from the one-and-done mindset and start looking at SharePoint projects as longer processes, ones that need to involve close collaboration with HR and department heads, along with representatives of various types of workers. And, if you’re looking to hire an outside firm for the project, remember you’re not looking for a vendor—someone who will create the platform and just hand it over. You’re looking for a longer-term partner, someone who’ll be able to take you through all the stages from planning, to implementation, to deployment and beyond.