- Service Design Leadership
- Operational Research
- Operating Model Strategy
- Product Definition
- Concept Evaluation
TRANSFORMING AIRCRAFT MRO PLANNING
Leadership expected 8–12 role-specific applications for a newly expanded military aircraft-maintenance facility. The Principal UX Designer recognized that digitizing each role separately could reproduce the same operational silos and brought me in to reframe the problem through service design.
I led the research synthesis, field discovery, five-day workshop, and definition of the industrial-engineering operating model. I then partnered with the Principal UX Designer to translate that model into a clickable planning concept.
The result was not production software. It was a shared operating model, a rapid product concept, and early user evidence that clarified the next research, data, feasibility, and product-development decisions.
A New Facility, an Old Operating Model
The facility move created a rare opportunity to reconsider how maintenance planning worked. Instead, many practices from the previous location had carried forward: disconnected systems, manual reconciliation, unclear information ownership, and teams independently solving related problems.
Industrial engineers sat at the center of this complexity. They coordinated long-range planning, work packages, resources, approvals, active disruptions, and downstream schedule effects—often by assembling information from multiple tools, reports, and people.
ROLE
Lead Service Designer / Research Lead
FOCUS
MRO planning, industrial engineering, operating-model definition, and product direction
METHODS
Artifact review, interviews, job shadowing, systems mapping, workshop facilitation, journey mapping, and concept evaluation
TEAM
Industrial engineers, operational leaders, Principal UX Designer, maintenance, data, and technical stakeholders
Reframing 8–12 Apps into One Operating Model
Leadership expected 8–12 separate applications for different operational roles. The existing evidence showed that many of those concepts depended on the same users, information, workflows, and decisions. Building each interface independently risked creating a digital version of the same operational silos.
I reviewed more than 50 artifacts, interviewed six industrial engineers across three facilities, spoke with leadership, observed the MRO environment, reviewed current tools, and job-shadowed planning activities. I organized that evidence into a research inventory, stakeholder model, input/output dependency map, current-state journey, and shared systems view.
FROM SCREENS TO SYSTEMS
I used the synthesis to connect roles, planning stages, dependencies, exceptions, and information flows. Repeated findings were checked with users; contradictions and unsupported assumptions became targeted research questions. The result was the first consolidated view of how planning moved across people, systems, data, and organizational boundaries.
The problem was not missing research. It was the lack of one operating model teams could use to make product decisions.
The synthesis exposed repeated capability needs, overlapping initiatives, unsupported assumptions, and dependencies no individual team could see alone. It gave leadership a stronger foundation for prioritization, roadmap discussions, and future product work.
Long Term Planning as the Product Foundation
I mapped the planning journey from program trigger through pre-planning, work-package creation, operational handoff, schedule-change management, and post-program analysis. Industrial engineers coordinated work that could begin months before an aircraft arrived, assembling capacity, staffing, parts, tooling, approvals, and schedule data across disconnected systems.
The journey made the operating model visible: where information was reconstructed manually, where ownership broke down, and where digital support could improve both deliberate planning and disruption response.
DELIBERATE PLANNING
Long-range work involving scope, capacity, staffing, resources, sequencing, validation, and approvals—often beginning months before active maintenance.
DISRUPTION MANAGEMENT
Time-sensitive work involving defects, unavailable resources, changing priorities, and downstream schedule effects during active maintenance.
The highest-leverage decision was to organize the product around long-range planning, not the daily fires.
Months before arrival, industrial engineers determine whether the facility can accept a contract based on capacity, staffing, parts, tooling, and qualifications. Strengthening that foundation allows disruptions to be handled as exceptions within a stable planning model rather than becoming the product’s organizing principle.
MANUAL RECONSTRUCTION
Planners repeatedly copied, exported, checked, and reconciled the same information across systems before they could make a decision.
LATE CONSTRAINT VISIBILITY
Capacity, staffing, tooling, parts, and qualification risks often became visible only after they had already constrained a plan.
HIDDEN DEPENDENCIES AND OWNERSHIP
Inputs, approvals, and downstream effects were distributed across teams, making responsibility and schedule impact difficult to see.
Translating the Operating Model into Product Direction
Each proposed feature and screen was tied to an operational need. The concept was structured around the questions industrial engineers needed to answer, the decisions they needed to make, and the evidence required to act—not around a generic dashboard pattern.
During the workshop, I converted the journey into high-level capabilities, workflows, information architecture, data needs, and low-fidelity screens. I then partnered with the Principal UX Designer to build a clickable concept in approximately four hours using the existing enterprise design system.
A SHARED PLANNING HUB
The proposed experience was a desktop-first planning hub layered across existing MRO systems. It brought together the information industrial engineers needed to plan, monitor, and respond without forcing them to reconstruct the operating picture manually.
The concept was not positioned as production-ready software. It was a decision artifact used to evaluate the workflow, information model, product capabilities, and value of continued development.
- View assigned aircraft, programs, milestones, and work packages.
- Monitor readiness, forward risk, and facility capacity.
- Connect schedules, work orders, milestones, approvals, and dependencies.
- Surface disruptions and compare response scenarios.
- Verify information sources, ownership, and update status.
- Coordinate follow-up actions while reducing duplicate searching and reconciliation.
The proposed scope began with an internal tool for industrial engineers, with a deliberate path to adjacent operational roles and, longer term, a customer-facing offering. The strategy was intentionally incremental: validate one role and operating model before funding a broader product.
Evaluating the Product Model
After the on-site sprint, I developed a linear prototype walkthrough around a realistic planning disruption. The experience guided users from an initial alert through information review, dependency analysis, response options, and follow-up.
We conducted four moderated remote sessions with industrial engineers and planning leaders from different facilities and experience levels. I facilitated each session while the Principal UX Designer documented feedback and design implications. The sessions supported the credibility of the end-to-end journey and primary information categories while identifying changes to screen density, widget hierarchy, and the separation of current status from forward risk.
This was early concept evaluation, not a production usability study. It established enough confidence to continue while clarifying the next research, data, and feasibility questions.
What the Work Enabled
The engagement replaced an app-by-app brief with a shared operating model that operational teams, UX, and leadership could use to evaluate future product work. It connected fragmented research, exposed overlapping initiatives, and established a clearer basis for feasibility assessment, prioritization, and continued development.
The final readout secured leadership support to continue with a shared industrial-engineering planning concept rather than proceed immediately with separate role-
My strongest contribution was maintaining continuity across the work: reconstructing the evidence, defining the planning model, facilitating the strategic reframe, and keeping interface decisions tied to operational needs.
SHARED OPERATING MODEL
Roles, workflows, dependencies, information sources, and decisions were documented as one connected system.
REDUCED PRODUCT FRAGMENTATION
Overlapping app concepts were reframed around shared capabilities before teams invested in separate interfaces.
CREDIBLE PRODUCT DIRECTION
The operating model was translated into capabilities, workflows, and a clickable concept that users could evaluate.
CLEARER NEXT DECISIONS
Leadership received a foundation for continued research, feasibility assessment, prioritization, and product development.
COMMON QUESTIONS
I led the research, synthesis, field discovery, workshop, and definition of the current-state operating model. The Principal UX Designer owned the interface design; we partnered closely when translating the model into the clickable concept. I was not the Principal UX Designer on this engagement.
The engagement delivered a consolidated evidence base, stakeholder and dependency models, a current-state journey, a shared operating model, low-fidelity workflows, a clickable concept, and four moderated concept-evaluation sessions. It did not deliver production software or a deployed operating model.
The organization initially prioritized active disruptions. Interviews, artifact review, job shadowing, and journey mapping showed that many downstream problems originated months earlier, when capacity, staffing, parts, tooling, and qualification constraints were assessed. That evidence led us to model long-range planning as the foundation and disruption response as an exception flow within it.
Six industrial engineers were not treated as a statistically representative sample. They provided role depth across three facilities, and their input was triangulated with more than 50 artifacts, current tools, job shadowing, leadership input, and follow-up concept evaluation. A subsequent phase would need broader coverage across adjacent roles and facilities.
This case focuses on reconstructing the planning operating model and using it to define product direction for industrial engineers. The MRO Mechanic App case focuses on frontline maintenance execution, floor visibility, and the day-to-day workflow of mechanics and support teams.
Specific product details, stakeholder names, and implementation details are confidential. This case study focuses on the service design approach, artifact types, and strategic value of the work.
RECOMMENDED NEXT CASE STUDIES →
Continue from operating-model strategy into frontline workflow design and broader enterprise alignment.
© 2026 Harsh Kumar. Some project details have been generalized or redacted to protect confidential information.
