QA Arrivals Case Study
While on an extended stay at Training Provider QA an interesting problem arrived. Delegate for the Training Courses QA offer typical arrive for a 9:30 start at 9:00, and we know that our Reception Colleague take over a half an hour to register everyone's arrival as they are required to.
In some of the QA Training Centres this equated to a few too many people hanging around a lobby, but in others it caused Health and Safety concerns, and it caused problems with Landlords and saw Delegates standing in the rain in a queue that snaked out onto the High Street.
My user stories wrote themselves. Our Reception Colleagues wanted to register Delegates quickly, Delegates needed to confirm their arrival, while their Funders wanted to make sure that Delegates had attended as expected.
A review of the process revealed quick wins around signposting, but mostly our issues were bottlenecks in the Registration App every Delegate had to be registered with. There was no self-service option, for contractual reasons.
The Registration App problems resolved itself to a mathematical one. Taking the worst problem if one thousand two hundred Delegates need to be signed in in twenty minutes, then each one needed to use the system in a one second multiplied by the number of colleagues available, which was often at least six. Each Delegate took twenty-eight seconds to be signed in. So myself as User Experience Designer & Front End Developer, with a back end developer at my disposal, needed to make the app twenty-two seconds quicker.
User Experience Design is well equipped for this. Large contact buttons, and increased visual signing, sped the App up by six seconds. Designing and building a custom keyboard to search as typing sped up another eight. Other best practices supported this drive.
When Delegates were asked for their name, they most often replied with "Steve" rather than “Mr Williams”, and allowing a change in the sort order, and a way to index that quickly, sped things up.
The Registration App searched all Delegates, and shrinking that search to only those expected on the day saved vital seconds, more could be saved by removing those who had already signed in during the pre-course window saved us more.
The handshake with the back end that happened when confirming a Delegate had attended cost us seconds and given that it could never fail for anything other than a breakdown in that handshake keeping the application unlock while sign in happened, and buffered sign ins, reduced sign in time to 6.3 seconds per Delegate.
The final 0.3 seconds came from the oddest source. At the top of The Registration App, we added a line of text to remind the Colleague to say “Lunch is at 12:30” every time. Every Delegate took slightly longer, but the average time per Delegate was reduced as individuals did not take long periods with the back and forth of conversation.
So sign in was lowered from twenty-eight seconds to six, and the queue no longer snaked out of the door. The project was a success, but the reason for that success was a tight collaboration loop with a developer, with colleagues, and a razor sharp focus on the user’s goals.
An Interface Build For Speed
The Plans For An Interface Build For Speed
