Table of Contents
Digital Transformation
Table of Contents
Overview
Project Summary
NEO Scheduling is a mission-critical enterprise application used to coordinate maintenance tasks and workforce allocation across a fleet of nuclear power plants. While the core platform managed the "happy path" of scheduling, high-stakes adjustments—known as Change Requests—remained a manual, paper-based bottleneck that introduced significant operational risk.
The Problem
Before this project, any schedule change requiring high-level authorization triggered a grueling manual process. Schedulers had to physically fill out paper forms with data already existing in our system, scan them, and email them to off-site managers. Junior schedulers often didn't realize that a change required approval and, compounding on this, leadership didn't have any visibility into change request data.
The Solution
We designed an integrated, end-to-end digital workflow that automated the Change Request process. This integrated smart triggers that automatically flagged when a change request was needed, automated data entry for change request forms, a scalable notifications framework, and an analytics dashboard for schedulers and leadership.
Results
My Role
Lead UX Designer
Launch Date
Q1 2025
Who We Helped
Directly:
Work Week Managers
Scheduling Coordinators
Site Scheduling Managers
Indirectly:
Work Supervisors
Plant Managers
Final Designs
High-Fidelity Designs
Change Requests Dashboard
Change Request Details
Calendar with Notifications
Update Roles & Permissions
Change Request Form
Annotated Wireframes
Placing a Change Request
Reviewing a Change Request
Deep Dive: Process & Insights
Exploring the Problem Space
Even though the basics of the change request process were known and established, we made sure to fully explore the problem space to ensure the quality of our digital solution.
The Fundamentals of Nuclear Scheduling
The Timeline: T-Weeks & The Schedule Freeze
Nuclear scheduling is managed through T-Weeks—a relative countdown to the Week of Execution (T-0).
T-0 to T-3 (The Schedule Freeze):
A critical buffer window where no changes should be made to ensure plant safety.
T-4 to T-9 (Core Scheduling):
The primary window for Work Week Coordinators to assign shifts and personnel.
T-10 to T-16 (Resource Loading):
High-level planning where tasks are bundled and assigned to specific work weeks based on resource availability.
The "Guardrail": What is a Change Request?
A Change Request is a digital safety gate. It prevents unauthorized changes to the schedule that could lead to operational risks. Common triggers include:
Scope Freeze Violations:
Moving a task into or out of the T-3 window.
Hold Codes:
Attempting to schedule a task while a hold condition - such as a "Material Hold" (missing parts)- is active.
Specialized Assets:
Moving tasks flagged for Weather Preparedness (e.g., hurricane or blizzard prep), which require expert engineering sign-off.
User Research & Discovery
The "Paper Trail" Audit
To truly understand the friction, I role-played the current process by manually filling out the physical paper forms. This "day-in-the-life" exercise highlighted the extreme redundancy: users were hand-copying data that already existed in our digital ecosystem.
Persona-Specific Workshops & Interviews
We conducted segmented workshops and deep-dive interviews with Work Week Coordinators, Managers, and Fleet Leadership.
Co-Design Workshops:
We used whiteboarding sessions to let users visualize their own "ideal" digital touchpoints. This helped us understand where the Change Request felt like a hurdle versus a necessary safeguard.
Mental Model Interviews:
Instead of forcing a new workflow, we identified the "prevailing strategies" users already used to navigate the manual system. Our goal was to digitize their existing intuition to ensure high adoption and minimal retraining.
Research Synthesis: Balancing Efficiency with Oversight
The research revealed a significant gap between how different personas viewed the change request process. While everyone agreed the paper system was broken, their "ideal" digital replacement varied based on their specific responsibilities.
Defining Solutions
User Flows
The Initiation (Requester)
This flow handles the "moment of discovery." When a scheduler attempts a change that violates a system rule (like a scope freeze), the app automatically triggers the Change Request modal. They key logic is that the system determines if a request is even needed. If not, the change is saved instantly, maintaining high efficiency for "safe" edits.
The Revision (Requester)
This is the most complex flow, containing multiple logic gates. The manager reviews the request reason, resource impact, and scheduling priority. The manager faces a few key decisions: they can can Approve (automatically updating the schedule), or Reject (notifying the requester with a reason). Escalations, where the change request requires a higher level of authority, are automated by the system, and still require a manager's review before being passed along to a higher-level approver.
Second-Level Review (Fleet Management)
For high-impact changes (e.g., weather preparedness), this flow provides a streamlined path for executive-level users. It focuses on final sign-off and ensures that once approved, the change is propagated through the entire NEO ecosystem immediately.
Sketching and Wireframing
The transition from user flows to interface design began with a period of rapid, divergent sketching. Because the Work Week Managers had such diverse mental models for how they wanted to review requests, I used low-stakes paper sketching to explore multiple layout concepts before committing to digital pixels.
The Convergent Process
As the fidelity of the designs increased, the number of features decreased. We used the previously established User Flows as a strict "logic filter":
Sketches:
High volume of ideas, focusing on different entry points (dashboards vs. flyouts).
Wireframes:
Mapping the successful paths from our user flows into structured layouts.
High-Fidelity Prototype:
One unified, "NEO-compliant" interface that satisfied all technical and user requirements.
Sketches
High-Fidelity Prototype
The Final Designs
Usability Testing
The Testing Protocol
We designed persona-specific scenarios based on the user flows:
Coordinators:
Initiating a request via a schedule change, editing a pending request, and identifying CR status within the task flyout.
Managers:
Reviewing and responding to requests via the dashboard and notification system.
Fleet Leadership:
Performing second-level reviews and analyzing high-level metrics.
Key Findings and Pivots
Link to work week instead of tasks:
We had assumed that managers would want to be able to quickly link to affected tasks based on info from the initial workshop. However, they actually needed a link to the work week to see the larger context of the schedule change.
Add optional note for approvals:
Managers requested the ability to leave optional approval notes to give additional context to the requester.
Make entry point more visible for requesters:
Requesters loved the automation but needed more explicit signaling for the beginning of the change request.
Harmonizing jargon:
Users noticed that some phrasing didn't match fleet vocabulary, so we replaced generic terms with nuclear maintenance jargon.
High-Fidelity Design
Our final, high-fidelity designs were handed off to engineering to develop into new features in the application.
Individual Change Request
The Change Request provides a guardrail against high-risk updates to the nuclear maintenance schedule.
Change Request Detail Screen
The reviewer has access to an extensive details screen that they can use to approve change requests.
Change Requests Dashboard
The Change Requests Dashboard shows in-depth change request metrics and also serves as a management system for pending change requests.
Roles & Permissions
Scheduling Management has control over different requester and approver roles.
Results & Lessons Learned
Results & Business Impact
The NEO Ecosystem Contribution
The impact of this project extended beyond the Scheduling app. We developed a Universal Notification System that was subsequently adopted as a core component of the NEO Design System, providing a standardized communication framework for all future applications in the ecosystem.
Data-Driven Leadership
Digitization unlocked the ability to funnel real-time data into a custom Power BI Dashboard. For the first time, fleet leadership could track the volume and root causes of change requests over months and years, allowing for long-term process optimization and resource planning.
Key Performance Indicators (KPIs)
The shift from paper to digital resulted in drastic improvements across every measurable metric:
Total Cycle Time:
The average time to complete a request dropped to 1/10th of the previous duration.
Initiation Speed:
Schedulers now initiate requests in under 5% of the time it previously took to fill out paper forms.
Review Efficiency:
Manager review time was cut by 50%.
Reliability:
Zero change requests were "lost" or missed after implementation.
Outlier Reduction:
Requests taking longer than a week were reduced by 90%.
User Sentiment & Satisfaction
Beyond the hard numbers, we saw a significant lift in how users felt about the platform. Quarterly tracking showed a noticeable boost in both System Usability Scale (SUS) and Net Promoter Scores (NPS) across all three primary personas.
Reflections & Lessons Learned
The Power of Design Autonomy
Early in the project, the Product Owner went on extended medical leave. Without a direct line to business requirements, I had to act independently. I pivoted to intensive primary research—extracting the "missing" paper forms directly from users and facilitating my own workshops to define the business logic.
The Lesson: Designers must be comfortable acting as pseudo-Product Managers—making high-stakes decisions, documenting their rationale, and standing by those choices when stakeholders return.
User Flows as a "North Star"
In a complex ecosystem, it is easy to "drop the ball" on a specific user interaction. I used the user flows as a strict compliance checklist throughout the project.
The Lesson: Beyond just a design tool, user flows are a roadmap for test plans and a safeguard against feature creep. If a design didn't align with the "North Star" flow, it was cut.
Value Frequency Over Duration
I learned that three 15-minute "micro-syncs" with users are often more valuable than one 60-minute formal review.
The Lesson: Constant, low-friction touchpoints build trust and allow for course correction before hours are wasted on the wrong path. Users are the final authority on success; the earlier they see a wireframe, the safer the final build will be.
Solving for the "1% Scenarios"
Midway through high-fidelity prototyping, we realized we needed a dedicated "Edge Case Audit." We brainstormed and designed for unlikely but critical scenarios such as: What if an unauthorized user attempts to edit a task while a Change Request is pending? What if two users initiate a request for the same task simultaneously?
The Lesson: Developers will eventually ask these questions. Preempting them with an "Edge Case Matrix" during the design handoff ensures a smoother build and prevents last-minute logic gaps.
Social