Boeing – MRO Mechanic App

MRO MECHANIC APP

Testing the Service Before Software

I conducted field research and ran a live analog service prototype on the maintenance floor, then translated what it proved into an approved product direction for a tablet-based mechanic application. The analog system is in daily use; the digital application is in development.

From Floor-Level Research to Product Definition

Maintenance work depended on a network of mechanics, floor managers, industrial engineers, parts teams, tooling personnel, trainers, quality teams, and technical specialists. The information connecting them was scattered across systems, conversations, and local workarounds.

I led the field research and product strategy needed to map that service, test a critical assistance workflow inside the facility, and convert the evidence into a prioritized product definition for the mechanic application.

MAPPED THE MAINTENANCE SERVICE

Connected the mechanic’s active task to the people, resources, information, and operational decisions required to keep work moving.

TESTED THE ASSISTANCE WORKFLOW

Introduced an analog request-and-routing model on the floor and refined it through observed operational use.

DEFINED THE PRODUCT REQUIREMENTS

Converted field evidence into prioritized capabilities, interaction requirements, operating rules, and system dependencies.

SECURED LEADERSHIP APPROVAL

Gained leadership sign-off and gave UX and development a prioritized foundation for detailed design.

Mapping the Maintenance Ecosystem

Aircraft maintenance is highly technical, but many operational delays began outside the task itself. A missing calibrated tool, unavailable part, unclear instruction, expired qualification, or unexpected aircraft condition could stop work immediately.

Mechanics then had to leave the task, reconstruct its context, and search through radio calls, messages, and informal relationships for the correct support group. Floor managers could see that work was slowing without consistently knowing what was blocked, who had accepted responsibility, or which delays created the greatest operational risk.

I conducted on-site job shadowing across structural, electronic, and other maintenance teams while following active work in safety gear. Because the facility’s existing maps did not represent the mechanic’s actual workflow, the majority of the final journey was reconstructed through direct observation on the floor.

The research traced work orders, priorities, task dependencies, parts, tools, personnel, qualifications, technical information, assistance requests, escalation paths, and status updates across teams and shifts.

TIME LOST BETWEEN TEAMS
Requests could pass through several conversations before reaching the group capable of resolving the issue.

LIMITED OWNERSHIP VISIBILITY
Mechanics could raise a problem without knowing whether it had been acknowledged, assigned, or escalated.

REACTIVE RESOURCE DISCOVERY
Missing parts, tools, personnel, and qualifications were often discovered after work had already begun.

FRAGMENTED OPERATIONAL AWARENESS
Supervisors, industrial engineers, and support teams held partial views of the same operation without a shared picture of active constraints.

HOW A DOCUMENTATION ISSUE BECAME AN OPERATIONAL DELAY
A mechanic finds installation guidance unclear or outdated and cannot continue. The issue is passed verbally to a floor manager, rewritten in a log, relayed to industrial engineering, and added to a backlog. The mechanic cannot see who owns the request or when it will return, while the aircraft continues to wait.

The delay is caused less by the technical question than by the absence of a visible routing and ownership model.

This floor-level view complemented the planning work shown in the MRO planning case. A scheduling decision could reshape a mechanic’s day, so both product directions needed to share the same task, resource, and disruption context.

Testing the Assistance Workflow Before Software

Assistance coordination emerged as the highest-risk workflow to test first. When a mechanic encountered a blocker, the request could pass through several conversations before reaching the correct specialist. Context was repeated, urgency was interpreted differently, and ownership was difficult to see.

I designed and introduced the Aircraft Operational Assistance Board as a live analog service prototype. Each request captured the aircraft, bay, work order, assistance category, priority, owner, status, time open, and escalation state.

The goal was not to design a permanent whiteboard. It was to test whether a shared request model could work in the real operating environment before the team committed to software.

WHAT THE BOARD STANDARDIZED

The board standardized the minimum information needed to understand, route, and manage each request:

Aircraft, maintenance bay, work order, and task context
Assistance category and required support group
Operational priority and time submitted
Responsible owner and current status
Escalation, next action, and resolution

A mechanic or floor representative could quickly record the issue. Managers could scan the floor, compare priorities, identify developing bottlenecks, and direct the appropriate person to respond.

WHAT LIVE USE ESTABLISHED

Observing the board in use produced evidence that wireframes alone could not provide:

Which task context mechanics considered essential
Which request categories matched real floor language
How urgency needed to be communicated
When ownership and escalation needed to become visible
Which information could eventually populate automatically

The intervention tested the operating model in the same environment where the digital experience would eventually be used.

WHAT CHANGED THROUGH LIVE USE
Not every concept survived contact with the floor. Mechanics stopped using the notes and context section of the board, so I removed it and gave the space to status. Task tracking remained confusing until it was simplified to only “started” and “completed.”

Those observed behaviors became requirements for the digital application rather than assumptions carried into it.

Turning Field Behavior Into App Requirements

The service prototype established a central product principle: information should remain attached to the work requiring action. A mechanic should not have to leave an active task, determine which organization owns the problem, and rebuild the aircraft, bay, and work-order context somewhere else.

I translated the observed workflow into a tablet-based product model that could travel with the mechanic and appear on shared workstation displays. The same task and assistance data could support individual work, floor coordination, shift handoffs, and role-specific operational views.

Execute the Task With Its Prerequisites Visible
Work priorities, dependencies, due times, instructions, revisions, diagrams, parts, tools, personnel, and qualifications would remain connected to the active task. Mechanics could see whether the work was ready before beginning.

Request Assistance Without Rebuilding Context
Support could be requested directly from the work order. Aircraft, bay, task, and mechanic context could populate automatically while routing, ownership, status, and escalation remained visible.

Coordinate the Same Operation Across Roles
The same task and assistance model could appear on the mechanic’s tablet, shared workstation displays, and role-specific views for floor managers, industrial engineers, parts teams, tooling, and technical specialists.

Together, these capabilities defined one operational experience organized around the mechanic’s active task—not a collection of disconnected applications.

Live Service Adoption and an Approved Digital Direction

WHAT I DELIVERED
By the end of my involvement, I had converted the field research and live service prototype into a prioritized product-definition package covering:

Primary users, roles, and permissions
Core maintenance and assistance workflows
Required aircraft, work-order, task, and resource context
Assistance categories, routing, ownership, status, and escalation
Documentation, qualification, and resource-visibility requirements
Dependencies, phased priorities, and areas requiring further validation

WHAT HAPPENED NEXT
Operational stakeholders and leadership reviewed the direction across the groups the application would affect. Leadership approved the foundation for detailed UX and development, giving the next team a field-tested workflow and prioritized requirements rather than an unranked feature list.

The analog assistance board was implemented and is in daily use. The digital application is in development at Boeing. My role concluded at the UX handoff: I owned the field research, service prototype, workflow testing, requirements framework, and prioritized product direction; the Principal UX Designer owns detailed interaction design and continued delivery.

Leadership Takeaway

DE-RISK THE SERVICE BEFORE THE INTERFACE

Rather than beginning with screens, I first made the cross-team service visible and tested its highest-risk workflow in the environment where it had to operate. That revealed which information, statuses, ownership rules, and escalation paths the application needed to preserve.

The result was more than a mechanic-interface concept. It was a field-tested operating model that leadership could approve and a delivery team could build against. When product risk sits across people and operations, prototype the service before refining the interface.

Common Questions

WHAT DID YOU OWN VERSUS THE PRINCIPAL UX DESIGNER?

I owned the on-site field research, mechanic journey, live assistance-board prototype, workflow testing, requirements framework, prioritization, and leadership handoff. The Principal UX Designer took ownership after that point for detailed interaction design and continued delivery.

WHAT WAS IMPLEMENTED, AND WHAT REMAINS IN DEVELOPMENT?

The analog Aircraft Operational Assistance Board was implemented and is in daily use. The tablet application direction was approved and is in development; the interface shown in this case represents the product direction at handoff, not a final production UI.

WHAT CHANGED AFTER OBSERVING THE BOARD IN USE?

The notes and context field was removed because mechanics stopped using it, and task tracking was simplified to “started” and “completed.” Those changes clarified which information the digital experience needed to preserve and which fields added unnecessary friction.

WHAT WOULD YOU VALIDATE NEXT IN THE DIGITAL APPLICATION?

I would test whether the digital experience preserves the speed and visibility that made the analog model work: time to raise a request, routing accuracy, clarity of ownership and status, usefulness of auto-populated context, and managers’ ability to identify aging or high-risk blockers without adding administrative work.

HOW WOULD YOU MEASURE IMPACT BEYOND ADOPTION?

I would track time from blocker identification to ownership, time to resolution, number of handoffs, age of open requests, recurring assistance categories, and time mechanics spend away from active work to locate support. These measures would show whether the product improves coordination rather than only digitizing the request.