Utilities System Modernization — 2025
Service completion: from operational bottleneck to a seamless and efficient journey
While working as a designer on the modernization of a commercial system for the utilities sector, I was challenged to structure the service completion process (the closing of executed orders). Although the customer service module already allowed for opening these requests, the product team had identified that the existing structure was insufficient to support the closing flow, creating an operational bottleneck. My task was to design a solution that bridged this technical and experience gap.
The problem 😵💫
The preliminary study for the service completion flow presented a linear and restricted view, covering only one service type and a specific scenario. The designed flow was as follows:
While functional for an isolated case, this preliminary model did not support the operational complexity of the utilities sector. In reality, service completion requires flexibility: different service types and subtypes demand specific forms and allow for various completion types, which dynamically changes what should be presented to the user.
To understand the gaps in this initial structure, I raised some critical considerations and questions about the flow:
The main goal of the project was to transform a rigid flow into a dynamic and adaptable experience. The objective was to make the interface as flexible as possible, reacting in real-time to the Script Workflow designed for each selected service type and subtype.
The Proposed Solution 💡
To address the rigidity of the previous model, I proposed creating a Completion Hub based on a side drawer. Unlike a fixed form, the Hub acts as a task orchestrator that reacts in real-time to user choices.
How the Flow Works:
Script-driven triggers: Upon selecting the completion type, the system queries the workflow script and instantly loads the tasks required for that specific scenario.
Contextual forms: Instead of a "set in stone" form, the Hub renders fields exclusive to the service performed. If a user enters information that requires an extra action, a new task layer is dynamically generated upon returning to the hub.
Persistence and editing: A key differentiator is the freedom of navigation. Users can complete a task, return to the Hub, and review or edit information without losing progress. No data is definitively sent to the back-end until all script conditions are met.
Task Hub Wireframe ✏️
Current Project Status 🗓️
With the Task Hub implemented, the focus has shifted to scaling. This will be the new service completion standard adopted by clients in 2026. The impact was immediate: the PO and the engineering team (architecture and PL/SQL) recognized the solution as an evolutionary leap forward compared to the previous system. Our priority now is quality assurance; we are currently in the QA phase, validating every detail of the flow to ensure a seamless and robust delivery for our clients.