As I have noted in previous posts, there is comparatively little information about the value and best practice of user testing in back-office systems, where the users are not 'customers', but employees using the software as part of their work.
In this post I share some of the things I have learned through my own experimentation in this area.
Why user testing?
However, most resources focus on websites, apps etc that are aimed at customers or public users. There are far fewer resources discussing best practice for user testing on back office systems. But these systems often represent a substantial capital investment for companies in terms of development, and getting it right from the beginning can mean less money spent on the project and also better results, such as improved productivity, increased sales and higher staff morale.
User testing on back office systems
Since being involved with project, I have worked to learn more about the area of usability and user testing, through books, articles, blogs, webinars, UX events and even gaining a usability qualification from Nielson Norman Group. The UX community is very generous in sharing knowledge and best practice.
It has been interesting try to apply what I have learned, in the context of back-office systems. Here are a few of the things that I have discovered so far…
1. Remember your goals are different
2. Involving real users too early can be a risk
There can be great benefit in testing early concepts on real users for the design team, but consider the effect on the reputation of the project. These users will be the first to see the system, and if you are testing early concepts, their experiences could be quite confusing or negative. Most users aren’t familiar with how software is developed, so may come away with idea that the system is badly thought-out or you don’t really understand their needs. They will of course share these first impressions with colleagues, and it could prejudice an implementation before it has even started.
3. Real users are not needed at the start
4. Use moderated tests - you are allowed to show users what to do
5. Use expert users from the project team
6. Observe people who are already using the software
7. User testing back-office systems is inexpensive and very beneficial
This research does not have to be expensive. In the image above I have used a couple of laptops and Gotomeeting to record the sessions. You could even do this remotely as long as you can confidently manage expectations and understanding of the users. The sessions pay for themselves by helping to direct the design and development early on to ‘get it right first time’.
And finally... you can even power the whole thing with a squirrel on a wheel, as in Steve Krug’s ‘Lost-our-lease usability lab’ below, from his book Don’t Make Me Think!