Modernizing an Enterprise Situational Intelligence Platform

Context

Initial Ask

The project started with the business wanting to move the application to a new version of Angular, and tasked me with a like-for-like redesign of the existing legacy application with only minimal UI updates.

I pushed back on that and recommended we run discovery first and strategize a value-added modernization based on the findings. I built a discovery plan with the stakeholders, working around real constraints: limited user availability, one shot at discovery, and very little existing documentation.

Discovery

Understanding the existing state of the application

The business challenge

Upon talking to business stakeholders, the following challenges were identified causing frustration among product owners

User adoption

Platform growth gradually declined to zero increase in new or unique monthly visitors, as teams reverted to offline methods.

Outdated functionality

Cluttered legacy grids required extensive scrolling and disjointed screen jumps, making it tedious to retrieve basic information.

Disconnected features

Unlinked components forced operators to jump between separate modules, adding friction and dropping engagement.

Eroding trust

The gap between what the product did and how the work actually ran caused confusion, and confusion cost the system its credibility.

What I proposed instead

The modernization approach, phased by capability rather than by screen.

Research

To understand the users' pain points and future needs, I used four research methods, chosen around user availability and business constraints.

Identifying the role based personas

The platform had been built for an average operator who does not exist. In practice four distinct roles arrive at it with different questions: reliability managers accountable for regional performance, control centre leads coordinating live events, customer assurance leads answering complaints, and restoration specialists working out where to send a crew. They depend on the same underlying analysis, but they need different things from it, and none of them was being served well. I built and validated a persona library so those differences had somewhere to live, and so feature decisions could be argued against a role rather than a preference.

Delivery Assurance Lead, the primary user.

Production and Operations Lead.

Formulating a clear plan for the re-design and validation and handoff

Thirty features across a twelve-month build, with a team of ten and an API that was being rebuilt underneath us. The order mattered as much as the design. I planned it around three things: what the platform needed to be able to do, when engineering could actually deliver each part, and who had to agree before anything moved.

Capability

I mapped what the platform needed to be able to do, rather than which screens needed redrawing. That produced a capability matrix the business could argue with, and it is what every later decision was measured against: a feature was redesigned, added or removed depending on whether it served a capability, duplicated one, or served none. Slicing by capability also meant each release could stand on its own instead of waiting for the whole migration.

The capability matrix the roadmap was built from.

Milestones

The sequence was set by the API team's readiness, not by what was easiest to design. Each milestone depended on specific data being available, so I worked backwards from what engineering could actually serve and when. That kept design from racing ahead into work that could not be built, and kept engineering from waiting on decisions that had not been made.

Milestones sequenced against API readiness.

Collaboration

Nothing moved to engineering until users and stakeholders had both seen it. I ran a regular cadence with the product owner to gather requirements and feed back on each redesigned feature, demoed designs to developers to pressure-test feasibility early, and worked with data engineers on what the sources could support. The point was to answer “is this buildable?” while the design was still cheap to change.

The cadence between design, product and engineering.

Examples of re-designed features

Each feature was redesigned, added or removed against the agreed capability matrix, to cut redundancy between features and consolidate fragmented capabilities into one place.

01

Navigation and learnability

Legacy

1

Filters gate the map

Layers and assets only appear once the top-level dropdowns are selected.

2

Region comes first

A region is required, because all internal reporting and analysis happens at regional level.

3

No free exploration

Users can't pan across the map to view devices in their areas without first setting a global filter.

Why it mattered

Area Managers are accountable for regional reliability, but the work happens at individual feeders and devices, often across 3 to 4 management areas. Checking one nearby device meant resetting filters and reloading the view, which slowed investigations between outages and escalations.

Redesigned

1

Filters are optional

Region still leads the bar for regional reporting, but the map no longer waits for a selection.

2

Filters refine, they don't unlock

Area, SVC and Feeder narrow the view for feeder and substation level work. Reset returns to the full network.

3

Pan across the whole network

Feeders and devices load across every region, so users can follow a feeder over area boundaries.

What changed

Users could previously see one substation at a time. They now start from the network and narrow down only when the task needs it.

Making it feasible

Make the case

Tech and API teams were concerned about load times. I researched Esri and Leaflet patterns and showed comparable applications that render full networks, to prove it was achievable.

Tune performance

The first build was too slow. We tested it over several rounds while the tech team improved loading speed, until the map was usable.

Set zoom rules

With stakeholders, we defined which devices appear at each zoom level, keeping the map readable and the load light.

Keep filters where they matter

Fault investigation still happens at feeder and substation level, so filters stayed available for that work.

What it changed for users

• Serves several personas: a restoration specialist can now get work done just by panning the map.
• Devices can be compared and distances measured across area and region boundaries.
• Less training needed for new users, with strong positive reactions in reviews.

02

Fault investigation

Everything needed to assess a fault was consolidated into a single event card, with the map, telemetry and related tickets alongside it. Additive search and direct access to the data layers meant investigating an outage stopped being a fight with the interface.

Legacy

1

Context hidden behind toggles

Related data such as trouble tickets only joined the faults list after users switched it on in the investigations panel.

2

Manual cross-checking

SCADA messages weren't filtered to the fault, so for every fault users searched a separate raw log to verify the messages, like using another app within the app.

3

Endless device list

Each fault was listed with all its details, so users scrolled through 5+ screens and struggled to skim or compare faults. There were no filters to isolate one.

Why it mattered

Fault investigation is time-critical. Grid Operations Managers need to locate faults and isolate risks before they become outages. With the evidence split across toggles, a raw message log, a long device list and several browser tabs, every investigation depended on manual cross-checking.

Redesigned

1

Context in one place

The detail view pulls in data from other parts of the app, like SCADA messages and trouble tickets, that used to need separate tabs.

2

Messages matched to the fault

SCADA messages are filtered to the selected fault, with linked devices and a clear type, so there's no separate log to search.

3

Filter, preview, then dig in

New filters for type, feeder status, phase and section isolate a known fault fast. Cards preview the key details so operators can skim and compare.

What changed

Investigating a fault went from piecing together three views to reading one. Users see what happened, which devices faulted and where they are on the map, all from the selected fault.

Comparative usability test

• 5 of 5 users rated the redesign much better.
• Comparing multiple fault events at once was much easier.
• SCADA, tickets and related data sit in the details pane, instead of tabs across browsers.

Making it feasible

Align on value

The tech changes were complex, so I made the case for their value to users and operators, and aligned stakeholders and the product owner to prioritise them.

Redesign the API

Bringing SCADA and trouble tickets into one pane meant redesigning the API, plus new code to match SCADA messages to fault events.

Create a fault ID

The new filters needed a fault ID data field that didn't exist, so it was added as part of the technical change.

Shape the cards

Card fields were defined with SMEs first, then refined after user feedback sessions so each persona has what they need.

03

One platform, several operators

Reliability managers, control centre leads, customer assurance leads and restoration specialists arrive with different questions. Personalisation and multiple interaction modes let the same product serve each of them, instead of a product built for an average user who does not exist.

Legacy

1

Search hidden in the nav

A search icon on the left nav opened a separate panel, taking the place of whatever the user had open.

2

One result at a time

A scoped search covered 9 categories, such as address, device, feeder and ticket, but users could only act on a single result.

3

Every click reset the app

Selecting a result reloaded the whole app around it, erasing the map and the investigation in progress. There was no history or saved searches either, so users retyped the same assets each time they came back to check on their area.

Why it mattered

Investigations rarely involve one thing. Checking a second address or device meant losing the first, so users rebuilt their view again and again, or kept notes on the side to remember what they had found.

Redesigned

1

Results stack on the map

Each added result becomes a lettered marker. Users keep searching and adding, with no limit, and remove markers one by one or all at once.

2

Add without losing your place

Add to Map drops a lettered pin and marks the result as added. A new search only replaces the results list, never the map.

3

History and Favorites

A banner and the legend always show how many markers are on the map. Area Managers return to the same assets to check for updates, so History re-runs recent searches and Favorites keeps the ones they check most, one click away.

What changed

Search now builds on the investigation instead of replacing it. Users typically plot up to five points, such as addresses, devices and tickets, and compare them together on one map.

Making it feasible

Additional dev work

Keeping searches on the map, plus History and Favorites, was extra work for the development team.

Users advocated for it

The old flow erased the map and kept no previous searches, which users found highly frustrating. They pushed for adding pins.

Stakeholders prioritised it

Prototype feedback was so positive that product owners and stakeholders pushed for it to be built.

How additive search works

Search, add, repeat, manage. Pick a type and enter a query, add a result as a lettered pin, run the next search while pins stay on the map, then remove pins or re-run searches from History and Favorites.

Prototype testing

• Users could keep their existing work while adding points to the map.
• It matched how they investigate, so they expected it to save time.
• Less frustration and faster investigations.

How I knew it worked

After launch I tracked adoption through the platform's usage analytics. Growth had been flat at zero new monthly visitors, so any movement was attributable. I also went back to the same ServiceNow categories I had read through during discovery, and the drop was sharpest in the ones I expected: minor navigation questions, and requests for help finding a feature.

What it left behind

The project became the blueprint for how work like this should run. Other teams began using the same approach: talking to users before building, writing personas, getting Figma screens validated before anything went into a sprint. None of that existed anywhere when I joined.

Engineering shipped with less rework. Because features were agreed with users and stakeholders before they were built, far fewer changes came back after release, which is where the cost of getting it wrong actually lands.

And the business came out of it with a modern tech stack. New capability no longer means working around a legacy platform.

Reflection

Takeaways that continue to shape how I work.