Replacing hours of data wrangling with minutes of visual analysis — building Delphi at RWE

This was the hardest design problem on the project. Analysts needed dozens of filter parameters — turbine ID, site, date range, event type, severity, operational status, wind speed range, power curve deviation, and more. Showing all of them at once was overwhelming. Hiding them behind a single search bar meant too many clicks.

The solution was a progressive disclosure model: the filter panel opens with the 4 most-used parameters (site, turbine, date range, event type) visible by default. Below that, an “Advanced filters” section expands to reveal the remaining parameters grouped by category — operational, environmental, and event-specific. Each filter showed active state counts so analysts could see at a glance how many constraints were applied.

Critically, I added a “recent filters” feature — since analysts often re-run similar investigations, the system remembered their last 5 filter combinations. This came directly from a user interview where an analyst said he kept a sticky note with his common filter setups.

AI-ready note: The “recent filters” feature is the manual version of what will become AI-recommended filter configurations. I designed the progressive disclosure system to accommodate a “Suggested” section above the primary filters — where the system could recommend parameter combinations based on the analyst’s context.

The core value of Delphi was the interactive time-series chart plotting 10-minute interval data — power output, wind speed, rotor RPM, pitch angle — over user-defined time ranges. But raw performance data alone doesn’t tell the story. Analysts needed to see when events happened in the context of the performance curve.

I designed event markers as vertical annotations on the chart timeline — color-coded by severity (critical, warning, informational) with expandable tooltips showing event details on hover. Users could toggle event categories on and off so the chart wouldn’t become cluttered during dense-event periods. For multi-turbine comparisons, events from different turbines used distinct marker styles to remain distinguishable.

AI-ready note: The event overlay system was built to display machine-flagged anomalies, not just manual entries. The color-coded severity system and expandable tooltips handle ML-generated confidence scores — so when anomaly detection ships, the UI supports it without redesign.

Delphi was replacing workflows analysts had used for years. Even though the new tool was more efficient, the switch itself was a friction point — people don’t abandon familiar tools willingly. The challenge: Delphi had multiple chart types (Scatter Plot, Time Series, Box Plot, Wind Roses) each with their own parameter sets and interaction patterns. A single generic walkthrough wouldn’t work because each module had different controls and concepts to learn.

The solution was a modular onboarding system. On first login, users see a welcome modal (“Welcome to Delphi”) with a clear choice: “Skip For Now” or “Yes, Let’s Go!” — a deliberate autonomy-first pattern that respects the user’s agency from the first interaction. If they opt in, the tour begins with the Alarms module, then offers to continue to Scatter Plot, Time Series, and so on. Each module has its own dedicated walkthrough.

Within each module tour, a progress stepper at the top (Parameters → Assets → Scatter Measures → Color Gradient) shows users exactly where they are and how much is left. The walkthrough highlights relevant UI sections with a spotlight border and presents contextual tooltips explaining what each control does and how to use it — including shortcut tips like “select ‘Power Curves’ to automatically populate X and Y axes.” A persistent “Skip Tour” option in the header lets users exit at any point without penalty.

At the end of each module tour, a completion screen gives users two paths: “Continue To Time Series Onboarding” to keep learning, or “Finish” to start working — with a reminder that they can always re-access the tour from the help icon. This modular approach meant experienced users could skip modules they already understood and only tour the ones that were new to them, while new hires could walk through the entire system end to end.

Since Delphi was an ongoing, iteratively shipped product, I needed a mechanism to capture user feedback continuously — not just during scheduled usability tests. Analysts are busy; they won’t send an email or fill out an external survey when something frustrates them. They’ll work around the issue and move on. The feedback channel needed to be built into the tool itself, not bolted on.

Rather than a small floating widget that limits what users can express, I designed a dedicated Feedback Area as a full page in the main navigation — giving it the same status as Alarms, Scatter Plot, or Time Series. The page has two tabs: “Leave Feedback” for submission and “Reported Feedback” for tracking.

The submission form lets users categorise their feedback upfront — Issue or Bug, Enhancement or New Feature Request, or Other Feedback — with a title, a rich-text description field (supporting formatting, lists, and emphasis for detailed bug reports), and a drag-and-drop attachment zone for screenshots, videos, or supporting files (up to 5 files, 8MB each). This structure meant the PO and I received consistently well-formatted, actionable feedback instead of vague one-liners.

The “Reported Feedback” tab was equally important — it showed users a table of all submitted feedback with priority levels (High, Medium, Low), current status (New, In Progress, Recognized, Done, Rejected), reporter name, release target, and a direct “View in ADO” link to the Azure DevOps work item. This transparency closed the loop: users could see that their feedback was acknowledged, prioritised, and tracked — not disappearing into a void. It also reduced duplicate submissions because users could check if an issue was already reported before filing a new one.

Impact: The Feedback Area became the primary channel for analyst input, replacing ad-hoc emails and Slack messages. The PO cited it as one of the features that most improved sprint planning quality — because feedback arrived structured, categorised, and with screenshots attached.