User login

6 Lessons from Usability Testing a SharePoint Project


After several weeks of user research, design, and building, it can be a little scary to finally begin showing your work to end users. But if you do take that risk, you'll find a rich supply of specific, actionable ideas that no amount of interviewing, surveying, or contextual inquiry could reveal. Here are some lessons I've learned from a couple of recent tests on our pilot SharePoint installation.

Fit the test method to your stage of development. Because this project had to happen quickly, and also because we were using SharePoint (which is relatively easy to customize), I began building the site directly after user research. There wasn't much of a pre-build design phase. However, your project could be different, so you should think about when and how to complete your tests. If you're building an entire site from scratch, wireframing and paper prototyping could make a lot of sense in the early phase. In my case, I think I hit testing at the perfect moment: after I had gotten as far as I could based on the user research, but before I was too attached to anything I had done in SharePoint.

Help the user feel comfortable by explaining what you're doing. You really don't want people to feel like bugs under a microscope! The important thing is to test the software, not the users. To set up the correct kind of feeling going into the test, I say “I've been staring at this system for weeks, and I may be blind to basic problems with the interface. During the session, I'd like to ask you to complete four tasks without any training, which will help me see how intuitive it is and what I can do to make it easier to use."

Prepare/test the user's desktop before the session begins. I ran into some browser compatibility issues in both early tests, which took place on the users' computers. This made me wish I had more control over the testing environment. Browser compatibility obviously isn't what I'm testing at the moment. For my next session, I invited the subject up to use my own computer, and I'm really glad I did. We were able to focus more on the system itself than the browser bugs that were out of my control.

Make sure the tasks fit the user (ie, their persona). Don't forget, personas should be part of your process all the way through. So don't make the mistake—as I did on my first test—of asking someone to carry out a task that doesn't fit their persona. In fact, you might even be able to pick up real tasks right from the personas you created during user research.

Write a script beforehand, and test it. I knew from previous experience not to wing it in a test. You definitely don't want to just ask a user to have a look around and give feedback. Instead, I wrote 4 specific tasks to be completed. For example: “Find a client letter explaining how being a tenant-at-will affects a lockout case." This is a realistic task our SharePoint system is supposed to make easier. When I wrote the task I tested it too: did I have the right file pre-loaded into my sample library, and was the metadata right?

Always record your sessions. I brought an mp3 recorder to my tests, but many people go as far as video recording the screen and the subject using separate cameras. In my case this certainly wasn't necessary. However, the audio recordings were essential. When I listened to my recordings, I heard some useful things that notes wouldn't have captured: the users' quiet asides and side commentary; specific likes and dislikes about the interface; and perhaps most importantly, my own impact on the results of the session. Hearing this last will make me a better tester for future sessions. Additionally, recording the sessions freed my hands up from note-taking and allowed me to be more present for the subject.

Further Reading

Many people have written about quick and dirty usability testing, so my goal here was only to add my own lessons from these tests. To get acquainted with usability in general, see UX Matters' Usability category, or anything by Jakob Nielsen.