Energy IQ | Transaction History

Case study

Overview

Energy IQ is an energy monitoring mobile app. It gives the user insights in to how they are using their selected energy.

Over time, increased discrepancies between the web and mobile app version of Energy IQ has impacted users’ experiences in different ways.

My challenge was to enable Transaction History functionality into the native mobile app, a missing feature that is present on the web app. We made sure the usability friction was identified and resolved, before the feature was introduced to the mobile app to enable a better customer experience.

Length of Project: 2 weeks 

To comply with my non-disclosure agreement, any confidential information is omitted in this case study.

Discovery

 

How might we...

Design for the majority

Google Firebase shows the majority of users are accessing Energy IQ via the mobile app, which is around 70% vs 30% from the web app, meaning the majority of the customers weren’t able to access transaction history information via the Energy IQ native app.

Reduce operational cost

The existing customer experience around the transaction history on the web app has, at times, led to an increase in the number of customer calls to the Call Centre. This was due to the ambiguity of the transaction history.

Provide consistent experience

Energy IQ is a product that spans multiple platforms (web, iOS, Android), it is important to maintain feature parity to enable consistent experience on different devices, the disparity of the transaction history between the web and mobile app means the user is not able to find the transaction information history on their mobile app.

 

Synthesizing

Wireframes and a prototype were created to explore the experience in more detail on a screen-by-screen level. Assumptions and hypotheses were tested against eight individuals with Invision and Lookback.

By using an iterative approach to the design and working closely with real users, we were able to pivot from the insights to uncover opportunities.

Findings:

  • The user found it is not easy to differentiate the debit and credit payments.

  • The user asked for the option to be able to filter the type of transactions made throughout their history. 

Design solutions: 

  • Icon and colour codes were added to the transaction items to allow the user to quickly identify debit and credit payments. 

  • Simple filter functionality was added as part of the requirement. 

 
 
 
 

Deliverables

I worked very closely with the team, including the Product Owner, Business Analyst to deconstruct the feature set into bite-sized user stories, and the cross-functional team are consulted so we know where to push the boundaries, and know what is realistically achievable.

The user story contains clear and precise acceptance criteria to ensure the resulting product, would meet business requirements.

UX product specifications

UX specification is created to provide practical guidance not just for the design team, but for everyone else involved in the development of the product, it can effectively support decision-making, prevent misinformation or scope change to creep in and cause bad decisions during the development process.

 

A better Transaction History

Despite the limitation of the mobile screens, the transaction history information is carefully optimised to be able to fit in different mobile screen sizes, the filter functionality is added to trigger bottom sheet to enable additional filter options consistent with existing design patterns. The use of icon and colour coding removed ambiguity between the transactions and helped users to distinguish displayed information.

The often-overlooked empty states opportunity was not missed to make sure the experience is complete and well supported. A design QA is also in place to ensure design quality control and accuracy is fully translated into the production.