Using Doherty’s Threshold Law of UX to Design the Special Olympics World Games 2019 App
In 2019, my firm got the task to design and develop an app for Special Olympics World Games 2019 which was being hosted in Abu Dhabi, United Arab Emirates.
“The Special Olympics World Games 2019 will be hosted in Abu Dhabi, United Arab Emirates in March 2019 for the first time in the Middle East North Africa since the movement’s founding over 50 years ago. The Crown Prince Court led the winning bid efforts with a mission to promote positive social change for people with intellectual disabilities and create a more inclusive society.”
The Challenge
To design an access control app for Special Olympics World Games 2019 that will help us manage check-ins, meal access, and lounge access for the primary stakeholders — participants, media personnel, management staff, VIPs, and event supervisors
A huge task
While it seems like a small app, the weight of this project was enormous. Yes, the numbers back this statement. It was a 10-day event and there were a total of 9 venues with 45 lounges where this app was to be deployed. The post-event analysis showed that there were 65000+ registered users and we stress-tested our system for 80,000 people. 350+ mobile app users were concurrently using this app. There was a need to establish an equilibrium or a flow in order to scan all these QR codes.
So yes, we wanted to design a robust, scalable system with a seamless experience.
The Solution
Every single stakeholder involved in the event was given an event ID Card that was on them at all times. The ID Card had a unique QR Code that could be used to check-in that person. But it wasn’t that simple. There were thousands of people involved and there was no margin for error. A single delay for a single person could cause a chain reaction disrupting the schedules of the mega-event. I had to design a solution that was seamless in operation, had a rapid feedback system, and covered all end-cases.
Doherty’s Threshold Law of UX — Voila
Since the volunteers had to scan so many QR codes in one go, the trick was to ensure that each volunteer established a flow and each interaction was in-phase with the response of the app.
This is where the infamous principle of Doherty’s Threshold is employed as an underlying law of user experience to design this app. The law states that:
Productivity soars when a computer and its users interact at a pace (<400ms) that ensures that neither has to wait on the other
So what does this exactly mean? To elucidate the law, it is important to understand the fact that the timing of a human-computer interaction is the key. Users get frustrated when they have to wait for long times after clicking a button or generally performing any action. We, humans, need feedback instantly and that is how our mental models are.
Before 1982, it was perceived that a response time of 2000 ms(2 seconds) was ideal for a system to interact with the user since the user took these 2 seconds to think of their next action. Walter Doherty, an IBM researcher published a paper that presented a hypothesis stating that indeed it was not 2 seconds but 400 ms (0.4 seconds). So when a user and computer interact at a rate of 0.4s, it is more likely that the user’s attention is retained and he can be more productive while doing a task.
I like to keep it simple when I am teaching my students and interns so the crux of the law I present to them is that “the system response time is directly proportional to the time it takes the user to think and do the next action”. So even if we get rid of the seconds mentioned above, the key is to make sure that the interaction is constantly happening at a uniform pace which establishes an equilibrium that reduces the human perception of waiting since the user knows when the next screen will appear.
So how does this apply to our scenario? The trick is to make sure that the major flow of the app has a constant interaction time of 400ms so the volunteer knows when to expect the next screen. Couple this law with a few micro-interactions, some visual design principles, and voila, we have an app that can seamlessly scan thousand of contestants for our event.
Read more about Doherty’s Threshold
The Flow
The main scenario is that a volunteer who is the operator standing at a specific point in a specific lounge of a specific venue scans QR codes for all the participants entering the area. A supervisor is also appointed for each venue who acts as a super-user in case there is any trouble with identification.
I identified the minimal pathway after dry-running several scenarios. The main use case to scan a QR had to follow the simplest, least complex path since the volunteers had to repeat the process several times to check-in all the participants from a team (sport/country).
Alongside flow diagrams, sketches, and wireframes were employed that helped me refine the most important use cases.
Prototyping the Interaction
Since I was working in a cross-functional team, the key was to work closely with the developers initially to understand the QR reader and its timing. Luckily, I was working with a kick-ass team of devs who developed a really fast QR Reader while I was creating the prototype.
The QR reader programmed was tested for different positions with the actual ID card which had QR code and the experiments were timed.
The tests indicated that the average approximate time to scan a QR code is about 200 ms. So what we needed to do was to make sure that the transition time after the scan was also around 200 ms to take the overall time somewhere around 400 ms.
A simple bezier (ease-in-out) timing function of 200 ms was applied to this transition.
Important Design Decisions
Android devices were allocated for this app so the design was made for android screens. Only a single screen size was designed for this reason. Testing was also done on the same android devices.
A sticky button for “Scan Another” QR code was placed at the bottom of the screen. This was decided as the major flow included the need to scan multiple QR codes since each team consisted of a large number of team members even spanning up to hundreds. The position was kept at the bottom since the application was optimized to be quickly used with a single hand so the button was put in a thumb-reachable area at the same place making it easier for the volunteer to scan multiple codes quickly.
Along with this, all other transitions followed the simple bezier (ease-in-out) timing function of 400 ms. This kept the uniformity and maintained the perception that each and every action had a constant response time which led the volunteers to enjoy a really smooth flow. So the splash, log-in, settings, clearing cache, updating logs, and all other screens had a transition of 400ms.
Adding Micro-interactions
A micro-interaction is anything that helps with providing feedback and aids with communicating the result of a trigger. It makes the engagement more delightful.
For this app, I did not design any fancy animations but two really important physical features were added to the QR scan trigger.
- Small beep sound and vibration: For every valid lounge scan, the volunteers can hear a small beep sound along with a physical vibration.
- Long beep sound and vibration: For every invalid lounge scan, the volunteers can hear a long beep sound along with a physical vibration.
The beep-sound helps the user to instantly identify if the access was valid or invalid. It also gives a general perception of a scanner. The vibration has a similar function but it reinforces the boolean feedback and since the mobile apps are being used in large arenas, there’s a chance the beep sound might not be heard at all times. And of course, these two micro-interactions could be switched off from the settings if some volunteers didn’t like the constant sound and/or vibration.
Testing
The app was tested in our studio as well as in the real environment i.e. the venues with multiple volunteers. We asked all the volunteers to think aloud while operating the app.
The app was tested for multiple scans for the major flow and the design came out to be successful. The only change we had to do was to increase the size of the sticky button since when the volunteers were scanning for larger teams, they developed a pattern of keeping the thumb at the bottom part to quickly scan another, and sometimes they missed it by a few pixels and pressed on top instead. This small fix helped them maintain that pattern.
One important thing to note was that when we tested for 50+ QR codes, the volunteers developed a tendency to produce a ‘hmmph’ sound whenever they scanned a QR code. This was because they were mirroring the response of the system that was the beep sound. This showed that they were in-phase of the system and had developed a pattern since they were interacting at a constant pace with the app and anticipated the responses of their actions would come.
Conclusion
My design journey shows how important these Laws of UX can be. Even if we are working on a simple app, design principles such as Doherty's Threshold can act as powerful heuristics to improve usability.
