British Gas
On Demand

One of the key features that enabled customers to book a repair within the app and purchase cover.

 

 
OnDemandAnimation2.gif
 
 
 
 
 

Problem framing

 

We started looking at On Demand repairs with a workshop. This started as a huge information gathering exercise. Here we listened to the web team that already have already been working on the existing journey and heard about real user stories of smoothness or friction and the pain points of where the journey had failed entirely. The follow up calls made to the call centre were explained by the agents. With key stakeholders present we took down business objectives and the future vision of sales as a whole.

In digestion of all the information we used the Google venture’s “How Might We” exercise seeking solutions and opportunities. From here ideation time with crazy 8’s and solution sketches from the whole room. 

Equipped with the popular potential solutions from the workshop, me and UX teammate broke down the core function of the journeys to visualise the essential touch points end-to-end. 

 
 
Design Sprint Energy Company.png
 
 

Rapid prototyping

We jumped pretty quickly into high fidelity screens for the prototypes, approaching the problems with a different angle for each prototype. Under the observation of all attendees of the workshop we took the prototypes into the lab for testing, attendees were able to see something that was their idea now in an customer facing interface.

 

The test involved 6 real customers and app users that were eligible to make these purchases. We saw some popular ideas fail entirely and some sit delightfully into a seamless journey. We made a test report documenting this focusing on what major takeaways we’d gained.

 
 
Testing.png
 
 
 
 

Technical capability

With some meaty insights under our belt, we had to see what our technical capabilities were before implementing any of our test findings. Despite having a technical voice in the workshop, all were encouraged not to feel limited in concept phase.

Here we saw what was possible in one back end system talking to another, whether certain account information can be reached to then be automated or if it would be another task for the user to have to complete within the journey and so on.

 
 

User flow

At this point we have solid knowledge on the tasks our user needs to achieve within the technical availabilities. I was able to map out the user flow, this being the start of the official master file. This is done with consideration of all the different needs of people that would be consuming it - from the developers to the brand sign off team. 

 
 
User flow.png
 
 

Refinement

With there being key issues from the initial test findings being crucial to layout and information overload within the limited real estate, I took time to pick apart and re-arrange this in sketches looking at all the variants and what was most clear and digestible to the eye. I selected a few versions to take forward into digital format to apply into the rest of the journey for the second round of testing. 

 
UI-progress.gif
 
 
 
 
 

Round two

The second round of testing we focused very much on efficiency and timing with the users ability to recall information. We noted pain points and the unexpected as we observed. As we collated all the notes in writing the report we saw very clearly that some versions were to be written off entirely, where the common friction laid in the “winning” prototype and adjustments to be made were quick wins. 

 
 
 
 
Post test stuff.png
 
 
 

Interfaces

After the many rounds of copy change, and some last minute technical issues, the final screens were signed off and ready for development. The design from initial workshop to handover was in turned around in 12 days. The experience received praise around the business and me and my team mate have since been consulting with the web team on how we have optimised the journey. 

 
 
Interfaces.png