SharePoint is a complex product. It can be used for Intranets, websites, portals and custom solutions. It supports document management, workflows, content creation, business intelligence and more. Is it little wonder users get confused?

And confused they certainly get. A typical SharePoint intranet project needs considerable investment after it goes live to get users involved, and keep them involved in the long term. 

Many clients ask me for an intranet users can use intuitively. I’m not sure such a thing exists, certainly not for everyone. Sure, you hope users can pick up the basics on their own (no one gets trained in Facebook after all) but a certain degree of hand holding will help them get the most out of SharePoint (certainly when it comes to using the more advanced features).

Training plays a huge role in fostering this adoption. This doesn't have to be expensive classroom sessions, it could be as simple as a weekly email newsletter packed with hints.

shutterstock_64362010.jpg

No matter how training is carried out there are three core SharePoint concepts that you need to explain to your end users, to give them any chance of sticking with SharePoint in the long term. These are Sites, Lists and Webparts. For those of us in the know this is basic stuff, and of course there are a ton of other things you could educate users about. But I firmly believe teaching these three things to the man or woman on the street will give them a huge head start.

Before we look at them, understand that these concepts are meant to set the scene for real novice users. It’s a starting point, a basic way of giving users enough confidence to explore. With that said let’s have a look at them, shall we?

1. Sites

Sites are key to SharePoint, all users need to understand this. With them we can build up a logical structure of information (I’d generally ignore pages for now, they just complicate matters). I often like to use a "container" metaphor to explain sites. A sites "contains" all of the content that will eventually be displayed somehow. You can then segway into a discussion on site templates, and even the security model of a site (everyone asks about security, who knew a spreadsheet of lunch options in the canteen was so important!).

Introducing sites first to a user will give them an idea of the "big chunks" they need to think about when designing their system. If they are happy with sites, then go for the pages conversation. Heck if things go really well you might want to talk about Site collections. If you pitch the sites conversation the right way, then users will almost guess what concept number two is.

2. Lists

Lists are next. Everyone who uses SharePoint knows what a list is, or they should. SharePoint 2013 seems to be confusing this previously simple discussion a little bit, with its odd description of apps, but I’d leave that for now.

The easy way to talk to users about lists is as the main data stores in SharePoint. Tell the user that everything is a list, compare them to Excel (with columns, cell types and filters), and leave it there. Just get the user thinking in terms of lists of stuff. Lists of documents, lists of staff, lists of data. You can expand if you wish by adding in Views, maybe even external lists. But keep it simple at first.

3. Webparts

The final piece of the puzzle. Once you have described Sites (containers of information) and Lists (stores of specific data) it should be easy to explain Webparts. Again SharePoint 2013 confuses the issue with apps, but lets take one step at a time.

I generally tell users that webparts are the main way with which to surface list data on a page. Sometimes you might want to leave it there, depending on the audience. But you can go on to describe standalone webparts, and how they expand the functionality of SharePoint if you wish. You need to be careful not to lose people who aren’t that technical here. I tend to describe webparts as two things: 1. a way of surfacing list data (windows onto the original list data) and 2. a blank canvas for text and images (the content editor) -- and leave it there.

Image courtesy of Morena Valente (Shutterstock)

Editor's Note: Chris writes regularly about SharePoint. To read more:

-- When is an App Not an App? When It's in SharePoint 2013