September 27, 2017 | 5min read
Short Guide to Quick Accessibility User Testing. Part 1
If you want to know how to advocate for user testing, check out the introductory article from the series here. In the following post, I will present short guide to quick accessibility user testing, based on our project with Papereed. You can read more about the project here.
Papereed is a Swedish web service which enables listening to audio recordings of narrators reading articles from magazines. Polidea was responsible for designing and developing the mobile version of the product—the application available on iOS. Thanks to it, users can create playlists of articles and save them on their phones in order to listen to them offline.
The main goal of the user testing was to verify whether our assumptions concerning accessibility features were right. We wanted to make sure that the design mirrored the needs of the users suffering from vision impairment, those who are blind and fully sighted. Papereed’s objective was to discover potential problems and opportunity areas based on the already working product. We decided to start with MVP version of the app. When the first milestone was behind us, we were ready for the evaluative research of the product. The testing scope was quite narrow: our client wanted to conduct the study in short time, with the maximum of 7 participants. This time we had a real challenge to face: testing with a specific group of users.
It’s very important to understand the end goals of all design actions you decide to perform. So before starting our work on user testing, we asked ourselves the basic question:
Why do we need this research?
Papereed was to prove that the iOS application is fully accessible. They had a clear goal to achieve and we had it always in mind. It set the direction for creating testing scenarios and structuring the report. We picked up a couple of scenarios: 5 tasks of various complexities to perform while using the application. We tested the real product, not a prototype. This decision influenced the final range of the chosen scenarios. Naturally, we already had some assumptions concerning certain features that may be problematic for visually impaired and blind users. We wrote them down preparing a set of focus points—the most important elements in the Papereed iOS version we had to test carefully.
Before you start working on a research study, be sure to clarify what should be the outcome, who will be the testing participants, how big is your budget and a team and how much time you have to deliver it. Only then you will be able to pick up the appropriate research method: the most efficient way to find answers to all your testing questions. As far as Papereed case is concerned, we have decided to conduct In-Depth Interviews (IDI). Why? Here come the 2 main reasons.
1. IDI are useful in case of a challenging recruitment
Private setting of our user testing was one of its core elements. We wanted to create a comfortable environment, allowing our participants to relax and talk openly about their everyday habits. Thanks to IDI we were able to elicit candid responses and make our responders feel at ease. We conducted 6 structured, in-depth interviews with 6 users: 2 blind users, 3 visually impaired and 1 fully sighted user. They were of different ages, genders and their levels of technological know-how also varied.
2. IDIs offer deeper insights
With one-on-one talks we could devote full attention to each participant. We observed their body language while they were using the tested app. We also had time to investigate new and interesting subjects that appeared spontaneously during the interviews which allowed us to gather deeper responses. Each participant had more time to share thoughts and feelings. Also, there was no group influence factor.
Hint: Want to make it even quicker? Schedule all interviews for one day and prepare templates for your notes. After several interviews you will notice that some things come up regularly.
Prepare a wish list to identify the responders for your research. You can use an open source document prepared by Michael Margolis, an UX Research Partner at Google Ventures: Worksheet: Writing a User Research Participant Screener
We did not hesitate even for a minute. It saved us lots of time! Recruiting companies have lists of contacts, professional teams and years of experience. Nevertheless, we needed to prepare the letter of intent. It introduced the idea of Papereed accessibility testing and clarified our goals. We also stressed the importance of accessibility in mobile apps.
When you’re trying to recruit very specific and less common types of users, you should look for them in the appropriate professional associations, community groups, student or university clubs. Prepare a screener questionnaire based on the criteria you defined at the very beginning and send it everywhere! Sometimes the official letter of intent can be helpful as well.
Hint: Don’t forget to recruit more people just in case some of the users resign. Inform them that they are on the waiting list. Send reminders to everyone one day before the study.
Now you’re ready to conduct the study. Stay tuned for the next blogpost with the detailed scenario of our testing!
Further reading and inspirations: