Designing the Diagnostic Workflow: From Chaos to Clarity
Transforming fragmented power outage diagnostics into a unified, life-saving system for Entergy technicians
Scroll to explore
🎬 The Story
Watch the complete journey from problem discovery to final implementation and impact
From Chaos to Clarity: Transforming Power Outage Diagnostics
A comprehensive walkthrough of how I led the research, design, and testing of the Entergy Outage Investigator — reducing diagnostic time by 75% and dispatch errors by 50% through human-centered design.
🧠 Deep Dive
A comprehensive walkthrough of the research, insights, design decisions, and validation process that shaped this solution
Understanding the Problem
When I joined this project at Entergy, the stakes were immediately clear — this wasn’t just a data problem; it was a human problem. Every time a power outage occurred, real lives could hang in the balance.
Many of our customers rely on electricity for medical devices — I remember one technician telling me, “We’ve got customers with kids on breathing machines. When the power goes out, minutes matter.”
Yet, despite the urgency, diagnosing and restoring power was slow, fragmented, and often inaccurate.
Contextual Inquiry & Persona Development
How the System Worked
Power distribution started at a DLOC (Distribution Location). From there, power flowed to several transformers, and each transformer served multiple meters — those meters represented people’s homes, schools, and businesses.
In an ideal world, when a meter reported a voltage spike or outage, technicians would trace it directly back to the faulty transformer. But reality was far messier.
The Core Challenge
Some meters were connected to multiple transformers, creating diagnostic ambiguity. When a single meter triggered an alert — say, readings above a defined threshold for a specific duration — the system couldn’t tell which transformer was the source of the issue.
This uncertainty caused:
- Delays in restoration — multiple transformers had to be manually tested
- Increased truck rolls — technicians were dispatched to the wrong location
- High cognitive load — technicians juggled data across 3–4 disconnected legacy systems (OMS, GIS, MDMS, CRM)
- Lost confidence — both in the system and in the diagnosis process
There was a lot of data, but very little of it was actionable.
“The physical integrity challenge during transport became a critical discovery that shaped our solution strategy.”
A non-digital problem requiring a design-driven solution
Discovery and Research
To truly understand the problem, I led a comprehensive discovery process that blended user research, field observation, and system audits.
User Interviews
I conducted structured interviews with:
- 12 field technicians (senior and junior)
- 3 regional supervisors
- 1 data systems engineer from the analytics team
Each conversation focused on how technicians received outage alerts, what tools they used to diagnose, and where breakdowns occurred.
Patterns quickly emerged — technicians spent most of their time not fixing the issue, but figuring out where the issue was.
Each conversation focused on how technicians received outage alerts, what tools they used to diagnose, and where breakdowns occurred.
Patterns quickly emerged — technicians spent most of their time not fixing the issue, but figuring out where the issue was.
Contextual Observation
I shadowed technicians during live outage diagnostics — watching them toggle between OMS alerts, GIS maps, and meter data portals. I noticed recurring inefficiencies:
- Switching between tools led to data loss
- Cross-referencing transformers and meters was largely manual
- Junior technicians relied heavily on senior colleagues for interpretation
“The physical integrity challenge during transport became a critical discovery that shaped our solution strategy.”
— Field Technician
System Audit
Working with our data engineer, I mapped how each system contributed to the diagnostic process.
Each held vital information, but there was no unified interface connecting them. This disconnection created “blind spots” that delayed resolution.
Synthesis: Making Sense of the Chaos
After analyzing interview transcripts, field notes, and system workflows, I conducted affinity mapping to group related challenges and behaviors.
The Key Insight
“The real problem isn’t lack of data — it’s the lack of a logical path through the data.”
Technicians were thinking in phases, but the systems weren’t built that way. Their mental model of diagnosis was sequential — detect, analyze, test, verify, and then act — yet the software forced them to jump randomly between sources.
That insight became the foundation for a standardized diagnostic model.
Design Development: Creating the Five Phases
To define a structured approach, I led two co-creation workshops with technicians, supervisors, and product stakeholders. We mapped the natural flow of thought and grouped activities by intent rather than tool. This collaborative process produced the five phases of the diagnostic journey:
| Technician's Intent | Observed Behavior | Defined Design Phase |
|---|---|---|
|
“I see something’s wrong.” |
Checking OMS alerts, filtering data |
|
|
“What’s connected to this?” |
Opening GIS to see network layout |
|
|
“Which part is actually failing?” |
Comparing meters and transformer data |
|
|
“Am I confident this is correct?” |
Asking peers or validating readings |
|
|
“Okay, let’s fix it.” |
Creating and dispatching a work order |
The five phases weren’t arbitrary — they were grounded in technicians’ mental models and confirmed through follow-up journey mapping sessions.
Building the Solution
Phase 1: Detect: Identify Outage Patterns
We unified all alert data into a single dashboard that let technicians input a Meter ID or DLOC. The system automatically displayed connected transformers, historical spikes, and threshold violations — turning fragmented alerts into actionable context.
Phase 2: Analyze: Understand Topology & Causes
Using GIS data, we created a real-time topology visualization that showed the network from DLOC to transformer to meter. This replaced manual mapping, helping technicians instantly understand which assets were at risk.
Phase 3: Test: Compare Meters & Diagnose
We integrated an AI-powered diagnostic tool that compared load variance and outage frequency across connected transformers. The system highlighted the most probable source of failure — effectively guiding the technician’s decision-making.
Phase 4: Verify: Run Manual Procedures
If the system’s confidence was below a certain threshold, the UI prompted technicians with a guided manual checklist, ensuring every potential source was inspected methodically. This phase mirrored how experienced technicians validated findings, now built into the workflow.
Phase 5: Dispatch: Assign Truck Roll
Finally, we automated the dispatch process. Once the faulty transformer was identified, a single button generated a pre-filled work order, including fault location, cause summary, and investigation log — saving up to 20 minutes per case.
Stakeholder Engagement and Iteration
Throughout development, I facilitated biweekly stakeholder sessions with engineering, operations, and field leads. Each meeting focused on:
- Reviewing prototype usability feedback
- Validating data logic with technical teams
- Aligning workflow design with field protocols
These sessions ensured technical feasibility and maintained stakeholder trust.
Low-Fidelity Wireframes
Early-stage explorations of the five-phase diagnostic workflow
Design Vault
Explore the detailed design artifacts that brought this solution to life
Usability Testing: From Planning to Iteration
Once the initial prototype for the Entergy Outage Investigator was ready, I moved into the usability testing phase. The goal was to validate whether the five-phase workflow (Detect → Analyze → Test → Verify → Dispatch) aligned with how technicians actually thought, diagnosed, and worked in real conditions — and whether it truly reduced confusion and error.
1. Defining the Testing Objectives
Before any testing took place, I aligned with our project stakeholders — including the UX director, product owner, and field operations lead — to define clear testing goals.
Our objectives were to evaluate:
- Usability and learnability: Can both new and experienced technicians navigate the interface intuitively?
- Efficiency: Does the phased workflow reduce diagnostic time and cognitive load?
- Accuracy: Are users identifying the correct root cause faster and with greater confidence?
- Comprehension: Do the data visualizations (topology maps, diagnostics panel) clearly communicate relationships between meters and transformers?
2. Selecting Key Participants
Because this tool was designed for field technicians, dispatch coordinators, and regional supervisors, we needed test users who represented the full range of real-world skill levels and responsibilities.
Senior Technicians
10–20 years of experience, deep system knowledge, familiar with legacy tools
Junior Technicians
1–3 years of experience, frequent users of OMS and GIS
Dispatch Coordinators
Responsible for issuing and closing work orders
Regional Supervisor
Oversaw diagnostic and maintenance performance metrics
4. Designing Test Cases
The test cases were built around authentic outage scenarios, created with the help of the OMS data engineer to ensure technical accuracy. Each case reflected a real-world diagnostic challenge that our solution aimed to simplify.
| Test Case | Scenario Description | Primary Goal | Expected Outcome |
|---|---|---|---|
|
Single meter showing voltage spike above threshold for 5 mins |
Test Detect and Analyze phases |
User identifies connected transformer and visualizes topology |
|
|
Multi-transformer scenario: three meters reporting irregularities across overlapping circuits |
Test Analyze and Test phases |
User isolates the probable faulty transformer |
|
|
Ambiguous signal requiring manual validation |
Test Verify phase |
User follows guided steps and logs the finding correctly |
|
|
Confirmed failure requiring service order creation |
Test Dispatch phase |
User successfully creates a truck roll with all details populated |
5. Running the Test Sessions
Each session followed a consistent format:
Introduction & Consent (5 min)
I explained the goals, reassured participants that the tool was being tested, not them.
Scenario Walkthroughs (30–40 min)
Participants completed the assigned test cases while narrating their thought process.
Debrief Interview (10–15 min)
I asked open-ended questions about their impressions, confusion points, and satisfaction.
6. Collecting and Analyzing the Raw Data
After the sessions, we consolidated raw data from observation notes, screen recordings, time-on-task metrics,
participant quotes, and error frequency logs.
We categorized insights into three buckets:
Critical Issues
Blockers preventing completion (e.g., unclear button labels, broken flows)
Usability Friction
Blockers preventing completion (e.g., unclear button labels, broken flows)
Enhancement Opportunities
Non-blocking improvements that could elevate experience
7. Consolidating Findings and Presenting Results
I synthesized the results into a formal presentation deck using Miro and PowerPoint, then presented the findings to UX leadership, engineering leads, field operations supervisors, and product management team.
Finding 1: Phase Transition Ambiguity
Users didn’t always realize when they had moved from “Analyze” to “Test.”
→ Recommendation: Add a visible step indicator with active highlighting.
Finding 2: Diagnostic Result Interpretation
Some users misread “No clear fault identified.”
→ Recommendation: Clarify messaging with “No clear fault found — proceed to Verify phase.”
Finding 3: Dispatch Summary Overload
Too much information presented before final confirmation.
→ Recommendation: Collapse less relevant sections and make confirmation action clearer.
8. Updating the Wireframes
Based on the validated recommendations, I iterated on the low-fidelity wireframes and interactive prototype. Key changes included:
- Adding a phase progress bar across the top navigation
- Refining data visualization colors and legend clarity
- Implementing a simplified "Dispatch Summary" screen
- Enhancing error messaging with action-based suggestions
Outcome & Impact
The testing phase validated that the five-phase structure aligned seamlessly with technician workflows and cognitive models. By directly involving technicians, coordinators, and supervisors throughout the process, we didn’t just refine a design — we co-created a system that technicians trusted.
“Ultimately, the Entergy Outage Investigator moved forward with data-backed confidence: improved technician satisfaction and adoption readiness.”
This phase became the bridge between insight and implementation — ensuring every design decision was anchored in real-world performance and human experience.
🎨 Design DNA
The interface components and data visualizations that transformed complex system
data into clear diagnostic guidance
System Architecture
Mapping DLOC → Transformer → Meter relationships
Topology Visualization
Real-time network visualization from GIS data
Diagnostic Dashboard
Unified alert data with threshold violations
Phased Workflow UI
Five-phase progression with active step highlighting
AI Diagnostic Panel
Load variance comparison across transformers
Dispatch Summary
Pre-filled work order with fault details
Context Over Clutter
Unified 4 legacy systems into one logical interface
Guide, Don't Guess
AI-powered diagnostics reduced cognitive load for technicians
Built for Pressure
Designed for speed and accuracy during life-critical outages
🎨 My Role
As Lead UX Designer, I drove the project from discovery to launch — conducting research, facilitating workshops, designing interfaces, and validating solutions with real users
User Research & Discovery
Key Activities
- Led interviews with 12 field technicians and 3 supervisors
- Shadowed technicians during live outage diagnostics
- Conducted system audit of OMS, GIS, MDMS, and CRM
Tools Used
✨ Identified that the problem wasn't lack of data — it was lack of a logical path through it
Synthesis & Ideation
Key Activities
- Conducted affinity mapping to identify patterns
- Led 2 co-creation workshops with technicians and stakeholders
- Mapped technician mental models into sequential phases
Tools Used
✨ Defined the five-phase diagnostic model: Detect → Analyze → Test → Verify → Dispatch
Wireframing & Prototyping
Key Activities
- Created low-fidelity wireframes for each phase
- Designed topology visualization and diagnostic panel
- Built interactive prototypes for stakeholder validation
Tools Used
✨ Identified that the problem wasn't lack of data — it was lack of a logical path through it
Usability Testing
Key Activities
- Designed test cases mirroring real outage scenarios
- Facilitated sessions with 9 participants (technicians, coordinators, supervisors)
- Analyzed time-on-task, error rates, and completion metrics
Tools Used
✨ 100% task completion on critical flows, 72% average time reduction
Iteration & Refinement
Key Activities
- Synthesized testing insights into severity-ranked findings
- Updated wireframes based on validated recommendations
- Presented results to UX leadership and engineering
Tools Used
✨ Secured stakeholder sign-off on all high-priority recommendations
Stakeholder Engagement
Key Activities
- Facilitated biweekly sessions with engineering and operations
- Aligned workflow design with technical constraints
- Ensured data logic validated by technical teams
Tools Used
✨ Maintained stakeholder trust and technical feasibility throughout
🚀 Behind the Scenes
The research moments, workshop breakthroughs, and lessons that shaped this human-centered solution
In-Store Observations
21 hours observing customer and staff interactions
Card Sorting Session
Testing information architecture with 24 participants
Journey Mapping
Mapping 17 critical customer-staff handoff points
Wizard-of-Oz Testing
Simulating AI assistant with 32 participants
Design System Build
Creating 48 components and 12 page templates
Lessons Learned
Understand Mental Models
Technicians thought in phases — Detect, Analyze, Test, Verify, Dispatch. Aligning the interface with their cognitive flow was the key to adoption.
Co-Create with Users
The five-phase workflow wasn’t my idea — it emerged from workshops with the people who would use it daily. Their expertise shaped every decision.
Design for High Stakes
This wasn’t just data — it was life-critical infrastructure. Every minute saved in diagnosis could mean a child on a breathing machine gets power faster.
Validate with Real Scenarios
Usability testing with authentic outage cases revealed gaps our assumptions missed. Testing early and often built stakeholder confidence.
Reflection
“This project taught me that great UX design isn’t about adding intelligence — it’s about organizing it around human reasoning. By understanding how technicians think, work, and feel under pressure, I was able to design a framework that turned scattered data into actionable insight — delivering both efficiency and empathy.”