How to do Inclusive Research
This week I attended the virtual 'How to do Inclusive Usability Tests' training with AbilityNet. This is very much something we want to start doing at Post Office and I was looking for any help in how to get started.
I obviously run usability sessions and other research on a regular basis, but there are extra things to consider when running sessions with people who have a disability.
This training session highlighted some of these things for consideration, for instance when running usability sessions we tend to use the rule of five on how many people we recruit for the session. However if we want to start being more inclusive we need to include more people with different access needs, which means five is not really enough anymore.
Obviously budgets and timelines will affect recruitment and timings of sessions, but as Raphael our trainer said, a larger sample size will make it much easier to spot the patterns.
He suggested participant numbers of 20-30, but if that is not possible, to really focus on the type of participant you actually need, for instance low vision people should have less of an issue with a product like a smart speaker than someone with hearing issues.
He also spoke about recruiting people and the different platforms you can use, and how important it is that these are accessible too.
We often use a recruiter to help us find suitable participants and Raphael suggested asking them what information they already hold on people, rather than having to write a whole new set of questions for my recruitment brief.
Of course once you have recruited for your session you need to make sure your participant can actually join your session, whether that is in person or remote.
Both have pros and cons, and some of it depends what you are trying to find out.
If you are running remote sessions (rather likely just now) then it means the participant is more likely to be comfortable in their settings using their own set up and software. But there can be additional technical issues getting them to join the session. For instance participants with screen readers will need to adjust audio settings so everyone else can hear the screen reader too.
But it does mean you can test with people from anywhere.
Testing in a lab means you are likely to have less technical issues, but you will need a good array of different accessibility software so people can use something close to what they use at home. You do not want to be testing their skills with a new software instead of your website or prototype.
It can also be a more social experience for everyone and make it easier to pick up body language cues than when testing remotely.
But in a lab you do need to make sure it is fully accessible to your visitors, and you might need to meet participants from public transport to help them find the session. Make sure you have someone on hand to help with this.
The session was interesting and covered the whole process of usability testing, but it felt a little basic to me, as this is my day job. I would have loved more focus on things like recruiting and interacting with participants - the sort of support they might need before and during a session for instance, which will be different to be more inclusive, rather than how to write a test script which should not really be that much different whoever you are testing with.
Still as an introduction to usability testing it was pretty good.