Product
B2C
Company
AES Corporate
Redesign the outage reporting workflow
Overview
I spent the summer 2025 interning in the Indianapolis office of AES, which is an energy company serving over 500,000 residents and businesses in the capital city of Indiana.
As the only UX designer in the office, I noticed that there was no acknowledgment after users reported a power outage. I advocated this need with internal stakeholders and managers, finally transforming this dashboard to a more user-centered one while integrating business requirements.
Challenge
Technical constraints:
Map data is supported by the Outage Management System, which is slow because it integrates data from numerous meters across the city. As a result, instant report acknowledgement is not possible.Operational limits:
Repetitive reporting was also the result of customer impatience caused by slow power restoration, which could not be sped up due to limited engineer capacity and storm severity.
Solution
Report acknowledgment (unauthenticated)
Report acknowledgment （authenticated)
Read safety tips
Search for outage status on the map
01 Context
Frequent storms during spring and summer in mid-west often lead to massive power outages. Electricity companies have an outage map that allows users to report issues and check restoration status.
02 Problem
Users report the outage through the portal. However, when they check the outage map after submission, their information will not be updated to the map until 15 minutes later due to backend system constraints.
Without an acknowledgement, users are very worried if the outage is known by the company and if there are people working on the problem.
03 Drive changes
I identified this issue while conducting a UX audit for another project. I discussed it with my supervisor, the Product Owner, who seconded my thoughts and encouraged me to advocate for the project.
I proactively reached out to the researcher and developer team through 1:1 meetings. I highlighted the project’s UX value and how it fit with their current priorities, successfully rallying their support.
04 Quick patch
The first thing the team decided to do was send an SMS to confirm a successful outage report and explain that updates might be delayed. It wasn’t a perfect solution, but it launched much faster than updating the outage reporting portal, which was a quick patch to close the most urgent gap.
From a customer experience standpoint, it didn’t solve everything. Often, it’s a family member or a tenant reporting the outage, and they don’t always have the phone number linked to the account.
05 Design decisions
How transparent should we be about how the system works?
I had two options. First, be fully transparent and tell customers the backend is slow due to massive meter responses, so they’ll have to wait a few minutes. Second, display the newly reported case on the map immediately through the front-end, even if the system hasn’t updated yet, to reassure customers.
At first, I leaned toward the second option because hiding the messy backend feels intuitive and keeps the experience smooth. After talking with the electrician team, I realized that simply reassuring customers doesn’t achieve what the team wants. Especially during severe storms, the sheer volume of damage can’t be fixed quickly, and pretending otherwise only creates the illusion that power restoration is effortless. My design should instead reveal parts of the system behind the scenes to help customers understand the work involved, set realistic expectations, and then improve the overall experience.
Do users need to log in to report outages?
The developer asked if it's feasible to ask users to all log in first as it takes less efforts to track data and provide acknowledgement.
I conducted competitive analysis and user research to understand this problem. It turned out that it's an industry common practice to allow customers to report without logging in and removing this option can cause really big trouble as some users don't know the account number or passwords during power outages.
I made this matrix to consider all the pros, cons and non-negotiables.
So my solution is two-step: customers are allowed to report the outage with simply their address if they're in a rush, but they can always log in to get real-time repair status and monitor multiple addresses.
06 Impact
My internship ended before the project got off the ground, but I still ran six user tests to see how my redesign made a difference.
I handed my work to the Product Owner. The next step is to collaborate with the mobile app team to keep the experience consistent and synced.
Rage click rate
