This is possibly the most important tip! While the past 96 tips are essential guidelines to follow, to truly understand your site's usability is to test it with actual users. The 5 quality components measured in usability testing are learnability, efficiency, memorability, errors and satisfaction. Watch this video to learn some of the key practices, processes and considerations to follow when conducting a usability study.
Speaker: Now that I’ve shared with you just a ton of tips on all these different type of usability issues that you can run in to in SharePoint; I mean literally up until these last five videos that I’m doing, I’ve literally shared with you 96 different usability issues that you can actually receive in the system like SharePoint. So, now I want to kind of wrap it up by spending a few videos and actually talk about what we can do about this and how do we figure out what exactly the issues are with our users and our systems and that kind of stuff.
The first step is actually something we’ve talked about all along the way and that is actually doing usability testing. So, you might remember or you may not, back in the first video, we actually talked about some of the heuristics that we would look at in there, including these five quality components from learnability, how easy is it for a user to figure out how to do something. Efficiency; how quickly can they get that task done. A memorability; after they haven’t done it for a while can a user remember that, especially when talking about search in SharePoint, can I figure out how to get back to something. Errors; what happens if I receive an error and can I recover and how severe are they. Satisfaction; how pleasant it is to use in there.
When we start looking at doing usability we like to do what’s called heuristic. Otherwise we are going to do task base testing. One of the first things we want to do is want to determine what we are trying to figure out. We want to establish a purpose; why are we testing, what are the issues that we are seeing or hearing, is it feedback or is it that our websites really old or is it that our SharePoint seems to be really hard for people to use or what is it?
So that we really understand what do we really need to test? Again, it’s not about testing a specific thing as much. It’s about testing patterns that people actually do. So, once we’ve established that, we want to design our tests. Overall a good rule of thumb is to test at least five people and it will give you a level of significance. What you’re going to find is that if you are asking the people the same questions, which you should in any good usability test, you’re going to find that at about five people and after you’re going to start getting a lot of repeats in what their seeing and the usability issues that you’re seeing. So five people tends to be a very good number, so as long as it is kind of randomly selected from your company.
You can set up used cases; so what are you trying to do? Sometimes you want to match those people with the different types of users that you might have in the systems. Obviously, get permission to use whatever data you’re going to do. One of the most important parts, out of everything out of there from age to gender to any other type of demographic data, the most significant thing that you should be testing is users from different levels of competency. Otherwise, somebody who’s a beginner to somebody who’s very comfortable to somebody who is maybe in your IT group or something like that that is a true expert. But, that’s a lot of times where you will get the biggest variety, is for how they actually use it because they all have different user patterns that they tend to follow as far as how they work with things in the browser.
Some of the usability tests that we can do, well, first and foremost is what we’ve been talking about heuristic evaluation, paper prototyping, card sorting, which is kind of more of an information architecture activity and then surveys. The only one that we’re really going to talk about is heuristic evaluation right now.
Heuristic evaluation is having a small set of evaluators examine an interface and judge it against recognized usability principles. So, these tend to be the ten usability heuristics that we look at; visibility of system staff, do you know where you are at in the system. The match between system and the real world. How much is it between the way you do it in SharePoint to the way that you would actually do this when you weren’t in SharePoint. How much user control is there? Do you have to follow a real stringent path or are you able to move around in that? Consistency, does the interface stay consistent? We’ve talked about that; from people changing templates and all that kind of stuff. Error prevention, we all know that story in SharePoint. A recognition rather than recall; what that really means is that instead of having to remember something, you actually see something, whether it’s a navigational component or maybe the name of a page or something like that and you recognize that. Flexibility and efficiency of use; how efficient is it to use. Do you have to go 47 clicks or do you have a clear path that you can go down. Obviously the stats are of minimal design, so much is it? Look; recovering from errors. We’ve kind of already talked about that. Then, help and documentations. So otherwise, if I get stuck, is there something there for me that can actually help me out?
So, when we are designing our tests overall we want to develop a list of tasks that you want the user to perform. We like to set up representative tasks and complete some kind of process; you know, go find this piece of information or go sign up for this new event or whatever it might be. Create something, whatever it might be. Overall, have task oriented things and things that these people may do in their daily lives in the SharePoint system.
We’re not going to look at a sample usability test right now. But, overall you can run your tests. One of the big things that you want to do is to really reassure your users. You want to go over the expectations and make sure that the user understands that you are testing the system, the interface and the SharePoint site and not them and that’s really critical. The tester should not be a stake holder in the project. In otherwise, you should not be testing people on your project team or people that have a serious personal stake in the SharePoint system because they will tend to give you much skewed results. Once you kind of run your tests, then you’re going to run through the tasks and collect the data so you’re going to do that. We are going to talk in another video about some of the tools that you can use for that but overall what you can do is kind of collect the data. You don’t want to be coaching the user, whoever is proctoring this, you want to let them do it. Sometimes you’re going to actually sit there and they’re going to be struggling, struggling and struggling and you’re going to want to say something so really bad but you really shouldn’t. As a matter of fact, there is a good reason that people on the project team really shouldn’t run this if you can possibly get away with it, because they tend to be too personal, like oh hey, it’s just up in the corner, look at that. We see that all of the time. You know, ask the user to verbalize their task so that you don’t know what’s always going through their mind, so ask them to kind of share that with them.
Make sure that they don’t do too much time. What’s the value? Well, if somebody is going to take 20 minutes to complete a task, then obviously you’re probably going to assist and you are going to know that they completely failed that task.
After, you will kind of debrief the user and ask them about their overall experience. Ask them for any suggestions and thank them. We are actually going to talk about another thing called system usability scale that is something that we actually use after our usability test to do some objective grading based on a real established scale that I’ll be talking about in another video as well.
Once you get that done, you’re kind of looking at your analysis and as you can kind of see here on the screen we are actually looking at some of these things. This is actually a task here for a college that we worked on. This is actually time on task in seconds and you can see that right here 45 seconds is about the threshold of most college student’s patience and we literally have almost every single test; one task actually took 228 seconds.
We can look at these different things; severe, how frequently something happened, the impact and how persistent it was and that kind of stuff. Then, you want to put it in some type of report. There is a lot of information out there on how you should kind of write these to be able to present them to people.
In summary, what you want to do is do a usability test that’s going to be useful and you want to have it very functional in nature and you want to use a wide variety of users. Even though you’re only using five. The most critical parts is to use users that actually have different competency levels around your SharePoint system.