A form for everything
Before eConnect, a Registered Electrical Contractor completed a two-page paper form and faxed it to CitiPower Powercor. Even though the form seemed simple, it would have to cover a variety of requests, including new connections, work at an existing property, an abolishment and a solar pre-approval.
Different requests needed different evidence, rules, appointments and internal processing. A contractor applying for a new connection did not start with the same information as someone altering an existing supply. Once submitted, the work could move through several systems and teams before the contractor knew what would happen next.
I led the experience design for eConnect as part of a team from Capgemini, working with a dedicated team at Citipower Powercor. Business analysts and subject-matter experts brought the service and regulatory detail. I translated this into journeys, interactions and a responsive interface. I stayed involved as the product moved into development, working with the Salesforce team to resolve gaps between the service rules and what a person needed to understand on screen.
Let the request determine the journey
The central design decision was to stop treating every request as the same form.
We started by asking what the user needed to do, then built a path for that request type. A new connection could begin with the proposed work because the property or supply might not yet exist in the system. An alteration or abolishment could begin by finding the existing property or meter. Solar pre-approval and other requests had their own relevant questions and supporting information.
That structure let us remove fields that did not apply instead of asking users to interpret a generic form. It also gave us better opportunities to pre-populate contact and account details, carry known property information forward and validate entries before submission. Related questions were grouped together so the journey followed the way the request would be assessed rather than the order of boxes on the old paper form.
The result was a set of connected journeys with a common design language, not a collection of unrelated forms. Users could submit a request, attach documents, book an appointment where the job required one, and return to track or manage work already in progress.
Design the cases that do not go to plan
The happy path was only a small part of the service. We also had to account for a property or meter that could not be found, information that did not match existing records, requests already in progress, missing documents, appointment constraints and work that needed to be changed or cancelled.
Those scenarios shaped the design from the start. Validation happened close to the relevant field. Known information was reused where possible, but users could correct it when needed. The dashboard and request details needed to make the next action clear, including when the user had to supply more information rather than simply wait.
Appointment states were a good example. A generic “Book appointment” action was misleading when a job did not require an appointment or one had already been made. Feedback from usability testing prompted me to consider when the action should be unavailable and when its label should change from booking to changing an appointment. Small wording and state decisions made for a much more understandable experience.
Build the interface the service needed
Salesforce was selected because it could coordinate workflows and connect to the systems behind the service. Its standard interface, however, was not the experience CitiPower Powercor wanted to put in front of contractors and other industry users.
I designed a custom responsive layer for desktop, tablet and mobile. The work covered the request journeys, dashboard, tracking, appointments, attachments, validation and supporting states. I created a style guide and reusable interface patterns so those parts remained consistent as the portal grew.
I also built the HTML and CSS. The Salesforce developers integrated that front end into Visualforce and connected it to the underlying data and workflows. We worked together throughout delivery to keep the build aligned with the design and resolve issues in real time.
Contractor feedback changed the details
The team from CitiPower Powercor conducted sessions with Registered Electrical Contractors and Licensed Electrical Workers through focus groups and industry roadshows. I worked with the team to define how they could conduct quick, informal user tests to gather feedback. They brought those findings back to the team, and I assessed them against the service rules before incorporating them into the design.
The feedback was practical. Contractors challenged terminology and column labels, which mattered in a service full of industry-specific language. They raised questions about appointment states and the wording of actions. The team also considered whether the colour treatment and contrast would remain legible for people working outdoors and which devices should receive the greatest design priority.
That input helped turn the interface into one shaped around the conditions in which contractors would actually use it. It also gave the team a way to test decisions during development rather than waiting for the whole service to be complete.
From paper requests to a phased service
eConnect progressed through development into a phased launch beginning in late 2015 and early 2016. Alongside faster connection times, the redesigned request flow reduced completion time from around two minutes to approximately 30 seconds. It gave industry users a digital tool to submit and track connection work, provide supporting documents, manage requests and book appointments instead of relying on a generic form and fax handoff.
eConnect remains part of CitiPower Powercor’s connections service today.