AI + AR Industrial Maintenance
Schneider Electric ·
B2B · AI · Enterprise UX
Product Design
Role
Senior Product Designer
Timeline
3 months
team
Product, Engineering, Research, Business, Developers, Product Owners
platform
Web
The Context
Industrial operators managing distributed water, power, and process plants often work across fragmented systems. In the scenario explored, an operator manages 1,200 water-treatment locations, with thousands of automation devices distributed across sites.
Maintenance teams were dealing with aging equipment, reactive failures, firmware and security issues, and limited visibility across geographically distributed assets. Maintenance assignments were also based largely on availability rather than relevant experience or workload.
The Problem
The core challenge was to create one continuous maintenance experience that could work for both strategic and operational users.
The interface needed to help users:
Understand the health of thousands of distributed devices.
Identify exactly where a problematic device was located.
Assign maintenance to the right person based on capacity and experience.
Bring firmware and security-policy maintenance into the same workflow.
Move from identifying a problem to taking action without switching between disconnected tools
My role
I translated a fragmented operational problem into a unified product experience spanning fleet monitoring, maintenance planning, security hygiene, physical wayfinding, and technician support.
Research & insights
The product exploration surfaced several structural pain points:
01 Maintenance was reactive.
Equipment failures triggered dispatches rather than enabling teams to proactively plan interventions.
02 Scale created visibility problems.
An operator responsible for 1,200 locations needed a way to understand portfolio-level risk without losing the ability to drill into an individual device.
03 Finding the physical asset was itself a problem.
Knowing a device ID or floor location wasn't enough for technicians unfamiliar with a plant.
04 Staffing was more complex than availability.
The best technician wasn't necessarily the person with the most free capacity; relevant experience mattered too.
05 Security and firmware lived in a separate mental model.
Security-policy expiry and firmware issues could fall through the gap between IT/OT responsibilities and day-to-day maintenance.
The Pain Points
Product opportunity
The opportunity was not to create another maintenance dashboard.
It was to design a continuous operational loop:
Detect → Understand → Locate → Assign → Fix → Maintain
That led to a unified experience where geographic risk, asset health, staffing, physical location, firmware and security could be connected rather than treated as separate workflows.
Design principles
1. One dataset, multiple ways of thinking
Directors think geographically; technicians think in terms of individual assets. The same underlying information should support both.
2. Turn alerts into actions
Every important alert should communicate the problem, its consequence and the next action.
3. Preserve context while drilling down
Country → plant → floor → device → physical asset should feel like one continuous zoom rather than separate applications.
4. Make expertise visible
Capacity alone isn't enough when assigning technical work.
5. Bring compliance into the operational workflow
Security and firmware maintenance should compete for attention alongside physical maintenance risk.
System / architecture
The experience follows a progressive spatial model:
Portfolio → Plant → Floor → Device → Physical asset
At the portfolio level, users see fleet health on a geospatial map.
At the plant level, an isometric floor plan exposes device locations.
At the device level, users see predicted maintenance needs, documentation and relevant actions.
Finally, a QR-triggered AR experience guides the technician to the physical device.
The broader maintenance system connects:
Fleet health + predictive risk + staffing + firmware + security + documentation + AR
into one operational loop.
Final experience
The final concept includes:
Geospatial fleet-health dashboard
Affected-plant list
Notifications
Maintenance planning and staffing
Capacity and experience matching
Firmware/security alerts
Plant floor-plan navigation
AR device wayfinding
Predictive maintenance countdowns
Contextual product manuals and video tutorials
The experience is designed to move a user from "something is wrong" → "I know what to do next."
Validation
We evaluated the concept through design exploration and stakeholder-focused product reasoning. Further validation would require usage analytics, time-to-resolution data, or a controlled pilot.
Impact
The demonstrated impact is primarily workflow consolidation.
The concept removes several tool switches across:
Map → asset register → security console → staffing spreadsheet → physical device search
and replaces them with a continuous workflow.
The portfolio explicitly notes that actual improvements to time-to-resolution or operational metrics would need to be validated through usage analytics, resolution logs or a controlled pilot.
Product USP
Most industrial maintenance software is strong at exactly one layer. A CMMS or EAM is strong at work orders, a condition-monitoring tool is strong at sensor health, an AR tool is strong at wayfinding, and each is weak at the seams between them, which is where time actually gets lost.
This product's unifying selling proposition is that it closes the full loop inside one interface: detect risk, see it on a map, physically locate the device, assign the right person, fix it, and keep firmware and security current, without a tool switch at any step. It is built specifically for distributed OT fleets, meaning many small, similar sites with thousands of automation devices, rather than for a single large facility, which is the harder and less-served case in industrial software.
The two features least likely to exist anywhere else in this category are the AR wayfinding to the physical device and the experience-matched staffing built into the assignment screen itself. Both solve problems most competing tools do not model at all, rather than doing an existing capability slightly better.
What I learned
Complex enterprise UX isn't about simplifying the system; it's about making the system's complexity legible at the moment a user needs to make a decision.
Key decisions
Decision: Map-first dashboard
Alternative: KPI wall or device list.
Why: Distributed operators need to understand where risk exists across the portfolio. The map establishes geography as the primary navigation model.
Decision: Map + affected-plant list
Alternative: Map-only experience.
Why: Some users scan geographically; others need a structured severity/action view. Both views represent the same dataset.
Decision: Experience-aware staffing
Alternative: Assign the next available technician.
Why: Capacity without relevant experience can create longer resolution times and unnecessary workload.
Decision: "Send Request" instead of forced assignment
Alternative: Disable overloaded technicians entirely.
Why: The system should discourage overloading without preventing a supervisor from making an informed exception.
Decision: Integrate firmware/security into maintenance
Alternative: Send users to a separate security console.
Why: Separating these risks creates another operational seam where issues can be missed.
Decision: AR wayfinding
Alternative: Static floor plans or device IDs.
Why: An unfamiliar technician needs to find the physical asset, not simply know its digital identifier.
