A Clearer Way to Buy an Essential Service

Owned: journey and information architecture, transaction-state design, UX writing and interface design across purchasing, meter management, history, rewards and advances. Worked with: business analysis, product and development, on an app already in delivery. For the customer, the goal is to use the electricity they bought; payment is only one step. Depending on the meter, there may still be a voucher to use or a load-to-meter action to complete. I framed the target behaviour as recognising and completing that next step, including after leaving the app and coming back. The risk I designed against was someone treating payment confirmation as the end of the task.

I organised the work around the five points where ambiguity could interrupt the purchase: selecting the meter, reviewing the amount, returning from payment, understanding the status and finding the transaction again. A clearer label or a missing recovery state could matter more than a larger visual change if it helped someone finish the task.

A successful payment doesn’t mean electricity has reached the meter. The model separates the payment result from fulfilment, with two paths: a manual voucher, and a smart-meter journey with a load-to-meter action. A load request being sent is not the same as a confirmed load. Confirmation, transaction detail and the return journey all show the current state and any remaining action, so the system carries the memory of an unfinished task.

History has two primary events: Electricity Purchase and Advance Repayment. Rewards, payment method and advance recovery are context inside a purchase, not separate transactions. A direct repayment stays its own event because it is a different customer action. The list answers “what happened?”; the detail explains how it was funded or allocated.

I connected eligibility, the amount taken, the outstanding balance and repayment activity so the obligation stays visible after the initial decision. A repayment taken from a purchase sits in that purchase’s context, a direct repayment is separate, and an active-advance view links them. One-time-code verification was a requirement for advance and reward transactions; my job was to make that step understandable and recoverable. The principle is to make consequences available both when people choose and when they return.

Meter verification happens during onboarding, before registration, and the meter stays visible as context throughout the purchase. Search, adding and renaming meters support recognition for people managing more than one. The review step is a second chance to confirm the meter before paying: proportionate friction around a consequential action, not friction everywhere. Notifications separate information from action, and an unfinished purchase links straight back to its task.

The journey and transaction-state model became the shared basis for discussing labels, navigation, states and exceptions. I tied each change to a customer action and the uncertainty it removed, which made it easier to argue for a small state or content change alongside larger delivery work. Release decisions and technical implementation stayed shared with product and engineering.

Delivered: a connected experience, now live, across meter verification, purchasing, payment return, fulfilment, history and advance tracking, built on a transaction model that separates paying from completing the task. The leadership judgement was how deeply to intervene in a live product while delivery continued. Still to measure: can someone recognise the right meter, identify the purchase state, find the remaining action and explain their outstanding advance balance?