Problem Context

If an Emirates customer wishes to retrieve a booking to their personalised ‘My Trips’ section of the app they first need to enter the booking reference and passenger name. The system then looks for an corresponding entry in the backend databases and if present retrieves the data.

This search can take up to 20 seconds due to legacy back end issues. 
The IT and back end teams struggled to prioritise this concern over their pre existing backlog of work despite efforts from product owners elevate this concern. I was approached to see if an alternative solution could be realised.

Discovery

I could see the issue quite apparently however the back end issues would eventually be upgraded so this particular solution need to be cost effective and resource light. We were already sprinting and therefore any research efforts needed to be light.
We revisited and relied on existing research such as personas and user flows

This is an issue that did not seem to affect our first class or business users but our infrequent and leisure travellers would have the biggest impact

Learning from persona review

Based on our user flow we anticipate that this issue would affect users immediately post booking or 24 hours before travel

User flow and journey map review

Still I wanted to verify if the problem was widespread before solutioning, and if possible develop a range of potential solutions.

Firstly, I held a mini discovery workshop with product and engineering in the war room to understand constraints and boundaries, and if we were lucky, stumble across some solid design direction’s.

If we cannot fix the backend, or build something new, could we move some features to distract the user

Primary learning from the workshop

Secondly, I interviewed 5 potential customers while using the application to understand expected time spent on task (retrieving booking) vs actual. Users indicated a desired response time of between under 5 seconds which agreed with Don Norman’s work on website response times.

If the app takes longer than 3 or 4 seconds to retrieve a booking I feel the app has crashed.

Quote from interviewee

Finally, I conducted a product review with the design leads to see if there were any other similar issues in the rest of the application and how they were addressed. Similar issues with the backend were present in most parts of the application but there was no clear path forward and the issues were placed on our design technical debt backlog.

Back end issues plagued the app in multiple features but we can overcome this with personalisation that is locally stored and referenced on the device

Learning outcome from product leads

Solution

Given that it seemed impossible to change the actual backend, or speed up the front end, I really only had two options. 

1. Provide visual system feedback of the delayed time to load. This paradigm was used throughout the platform already and an existing pattern would be fast and easy to implement.
2. Find some way to provide a distraction so that the user was not aware of the passing time. This paradigm was not used, but given the duration and importance of the delay this proposal was preferred.

Scenarios such as flight naming, seat selection, pre checking questionnaires etc. were explored with sketches and discussed with product owner.
Sketches were brough forward to wireframes, verified with design team.

Trip naming was determined to be be the least costly solution as it was stored locally. Additionally it was deemed to be a forced cognitive burden as I was forcing the user to think of a name which could take time.

Final agreed proposal

Wireframes were taken to prototype and tested with another 5 passengers. Feedback was the same in that users expected the process to take under 5 seconds. However the overall duration took about 10-15 seconds (as they thought of a name). Despite this duration, the passengers believed the app performed the booking retrieval instantly.

I didn’t want to rush the name selection, it was a big trip and I wanted the right name!

Quote from Interviewee

Conclusion

Overall feedback was extremely positive from stakeholders and passengers. Critiques from the design team circled a scenario that would exist when a booking was not found or there was a server error. In these scenarios we would be asking the user to name a trip that didn’t exist. Ultimately this concern was accepted as there would be a much smaller cohort that would experience this issue and the severity of this was deemed to be minimal.

Overwhelmingly the majority of users saw a positive improvement in response time and general experience. I love this case study as it proves that solutions can be really quite simple.