Usability testing for successful SharePoint implementations

Working for a company that puts a heavy focus on user-centred design and as a business analyst, my workshops rely heavily on user interaction and user-driven requirements. It is all fine and well to state that your solution focuses on the user’s problems and is designed for them, but how can you measure its success unless they are the ones who test it?

Why is usability testing so important?

Consider this statement: usability testing measures the usability, or ease of use, of a specific object or set of objects.
How do you decide how easy a system is to use? This point demonstrates how many SharePoint implementations can go wrong. If you rely solely on the developers and testers to put your solution through its paces, of course they will discover fundamental issues and bugs relating to the functionality or look and feel of it. What they won’t discover is perhaps the complexity of achieving certain pieces of functionality. When I come up with a requirement to be able to create a site, using a custom template that the users have helped me design, when it comes down to using it, my knowledge of SharePoint allows me to do it with ease. The question is; If it's not as simple as one or two clicks, will user’s get frustrated with it? Will they go back to using templates that aren’t really what they need? This is exactly why usability testing is so important.

Not only is it fundamental in measuring the success of your solution in terms of ease of use, but the earlier you can get actual users involved with the system, the better (and quicker) the up-take will be within the organization. It is one of the key steps in your user adoption plan. If users feel comfortable with the new system, the likelihood is that the change will be a much smoother process. You will then have a sample of users within the organization who would be your ‘champions’ for SharePoint. This is also vitally important as it helps to drive the change further down into the organization, helping it take hold.

User Acceptance Testing

Ok, so you now understand the relevance and importance of usability testing, but what is the real expectation when a solution is handed over to a client? Often, it is the case that developers or vendors of SharePoint solutions dedicate a portion at the end of a project to User Acceptance Testing (UAT). It is in this phase that users get their first glimpse of their shiny new SharePoint solution. The initial excitement comes in when they see how nice it looks, especially if there is attractive branding included. The next thing they notice is how they go about using it. It is at this point that consultants or business analysts observe the user engagement with the system.

Unfortunately, at this point it is almost too late. Asking questions like; “How long did it take to figure something out? How long did it take to find what they needed? Did they use the search bar or the navigation?” should guide the consultants in designing something that is fit-for-purpose and easy to use prior to it being built. For this reason usability testing needs to be carried out on a prototype of some description in order to make sure the final solution is really what the users need. This can be carried out using wireframes, site maps, navigation samples, html prototypes etc. All of these deliverables should go through usability testing in order to reduce the risk of a solution that is not fit-for-purpose. It actually saves a lot of time and money in the long run if you catch design flaws early rather than having to re-design and re-build whole solutions.

SharePoint training

The final point to consider is more of a question of users’ technical ability in SharePoint. More often than not, especially with SharePoint, after a user-designed solution is built, clients are handed the solution and left to work out how to configure and set up the solution themselves. Without any guidance on some basic SharePoint principles, the user will get frustrated easily and give up and you will have lost the engagement battle before you ever really get off the ground.

So, in terms of attacking the issue of usability testing in SharePoint specifically, I would always recommend that the users take a foundation SharePoint course or some form of training on how to use SharePoint at a basic level. This will inform their movements around a site and will let them test the more complicated custom features without getting stuck on the basic principles. This will significantly benefit both the vendor and client; the client will feel empowered and the vendor will get valuable feedback​ that they can work with. Taking all of this into consideration, it is safe to say that if usability testing (not just in SharePoint) is carried out during the various stages of product development, it really becomes the corner stone of a successful SharePoint implementation.