We iterated this design to remove the notification banner
This design began as a ‘straight to support’ MVP but was adapted to be a design that will accommodate when the API is unavaliable. Knowing the API isn’t too far away, it did not make sense to do a large redesign as a support only service.
When the service launches there will be no API. Once the API goes live the service will only fallback to this design if the API is down.
Highlighting timescales
When the API is unavailable we need to:
- set expectations by indicating that requests will take longer
- give an indication of support timescales
- promote the phone line for urgent queries
- emphasise the benefit of giving all information up front
On the start page we:
- include a notification banner about the delays
- move the phone number above the Start now button
On the confirmation page we:
- talk about information being received
- reiterate timeframes and promote the phone number again
- playback the Zendesk support ticket if available (while also aware not to make it look like a TRN)
A user also receives an email restating these details. This replaces the ‘Your TRN’ email they would receive if there was a match.
Technical expectations
Before the API is built we expect to:
- immediately create support tickets for requests
- playback the Zendesk support number straight away
When the API is built but unavailable we expect to:
- try to reach the API for a few minutes before we go to Zendesk
- create support tickets for requests if the API could not be reached (for example 5 to 10 minutes)
- attempt to match the given data as soon as the API is available again
- send any TRNs when we find a match
- close corresponding support tickets if there is a match
In both situations we will always ask the ITT provider question.
We will need to decide how the API unavailable state is enabled and disabled.
Video walkthrough
Find a lost TRN: API unavailable
Screenshots
Start
Confirmation
