Shipped 2025

ECM — Explainable Congestion Management

Designing an explainability layer for a critical infrastructure tool — so grid operators can understand not just what to change, but why.

Role UX Researcher & UI Designer
Company 50Hertz
Type Internal Tool
ECM — cover image coming soon

Who is the user?

Grid operators who are responsible for keeping the electricity grid stable. Our users work in day-ahead congestion management — fixing tomorrow's grid problems today.

The preventive redispatch (pRD)

Germany has five national preventive redispatch (pRD) processes. These consist of adjusting which power plants and energy assets will generate more or less the day after, so transmission lines are not overloaded when electricity actually flows and the grid is always balanced.

The pRD2 tool provides the operator an optimization result telling them which power plants, wind turbines, and other energy assets need to adjust their output to prevent overloads in the transmission lines.

The tool shows what to change — but never why.

Operators verify and adjust these results under time pressure, with no tool support for the reasoning behind the results. They change the results using their experience and intuition built up over years.

8/10 shifts where operators change the optimization results
~20 min available to verify results — less than the tool itself is allocated

Direct quotes from operators

"...manchmal fehlt die Information, warum eine Lösung als optimal ausgewählt wurde."

The operator explicitly talks about the gap: no explanation on why the result was considered optimal.

Respondent 1 — Q19

"In einer durchschnittlichen Schicht hat man etwa 20 Minuten Zeit für die Plausibilisierung der Ergebnisse."

The operator talks about the time pressure to check result plausibility: roughly 20 minutes — already less time than the redispatch tools are allocated.

Respondent 3 — Q13

Methodology

We ran a survey of 23 questions with 7 participants, focused on understanding what tools they use, how confident they feel using them, how much they adjust results and why, and where they lose time.

The underlying thread across all questions: when do operators trust a result enough to accept it — and what would need to change for them to trust it faster and more reliably?

We also conducted observational research, sitting with one of the users for nearly 5 hours — though we weren't able to observe the pRD2 process directly due to access constraints.

Key insights

01

No reasoning support

Operators consistently flagged the absence of explanations. They know what to change, but not why the optimization chose a specific result — leaving them to rely entirely on personal experience.

02

Time pressure is critical

Operators have roughly 20 minutes per shift to verify results. This window is already shorter than the time the tools themselves are allocated — making every second of cognitive overhead count.

03

Low AI trust

Two respondents scored AI trust at 0 and 1 out of 10. A direct quote: "AI that cannot admit it doesn't know something is dangerous." Every response must state its limits.

Based on user feedback, the solution needed to do two things:

  1. Show the reasoning behind the optimization result
  2. Provide a confidence score and let users verify the reasoning

The core design challenge was information design: reasoning logic, confidence scores, and sources needed to be presented in a way that is immediately understandable under time pressure. An LLM-based chat interface lets operators ask follow-up questions without leaving the tool.

Scope constraint: users cannot activate, modify, or submit results through this tool — it is purely an explainability layer.

MVP feature list

  • Sensitivity display + plain language explanation — why specific assets (AOs) were selected, with suggestions for manual adjustments. Requested by 4 out of 7 respondents.
  • Ramp flag explanation — ramp constraints are the single most cited reason for mandatory manual adjustments every shift.
  • Mandatory confidence score — every AI response must state its limits and uncertainty level.

Nice to have

  • Data timestamp — operators need to know how up to date the data they're reviewing is.
  • Weather forecast — users compare current conditions to similar days from the past three months.
  • pRD1 vs pRD2 comparison — one respondent flagged inconsistent results between runs for the same CBCO as a recurring source of confusion.

Next project

Spotify Radar →