06 · Case Study
Breaking Down Silos to Unlock Expert Support
A grounded aircraft in Buffalo. The mechanic who could diagnose it sitting in San Francisco. The gap used to be filled with phone calls, text threads, and forwarded photos — communication that left no audit trail in a regulated industry where every part touched gets documented. As Lead Product Designer I designed the permission architecture that let remote expertise into the ticket without taking ownership away from the mechanic standing next to the plane.
The problem
Tickets only allowed access for mechanics at the aircraft’s active location, blocking help from qualified teammates at other bases within the same airline. When teams got stuck on complex issues, they relied on phone calls and texts that didn’t preserve context inside the ticket. Management lost visibility into who contributed to critical decisions.
The downstream effect was slower troubleshooting, repeated diagnostic work, and inconsistent documentation that created compliance risk. Aircraft sat grounded longer while local teams waited for expertise that already existed elsewhere in the network. Every delay cascaded into readiness problems, schedule disruptions, and safety concerns.
The solution
I designed a permission-based access model that brings expert input into the ticket itself, improving decision quality while keeping every update traceable. The ticket header surfaces aircraft tail number, current status, location, and ownership so remote helpers orient quickly. Permission cues (read only, comment, limited actions) appear directly in the UI to reduce mistakes. Official work logs stay separate from troubleshooting discussion, keeping the repair record clean for audit compliance while enabling fast collaboration. The design shows who contributed, from where, and how that input influenced the repair timeline.
Granular permission controls
Mechanics can access tickets across locations within the same airline, with clear indicators showing whether they can read, comment, or take limited actions. Ownership stays with the local mechanic on the aircraft. The four access levels are visible up front so collaboration scales without accidental ownership transfers or compliance gaps.
Instant context for remote helpers
Ticket headers show aircraft tail number, current status, location, and ownership upfront. A remote mechanic opening the ticket from another base can orient in one glance and start contributing accurate guidance without digging through history, prior work logs, or status fields scattered across the page.
Structured conversation architecture
Official work logs stay separate from troubleshooting discussion. The audit trail captures parts requests, file uploads, assignment changes, and sign-offs. Everything compliance needs, kept immutable and attributable. The discussion lane runs alongside it with questions, hunches, photos, and prior-fix references. Both visible. Neither gets in the other’s way.
Research & approach
- 01 Interviewed mechanics and maintenance managers across multiple airline locations to understand how they collaborate when repairs get complicated. Recruited both heavy ticket users and those who relied on phone calls. The phone-call users were the real signal. Their off-platform work was where the audit trail was bleeding.
- 02 Mapped the common moments where teams felt blocked, documenting the exact artifacts they shared outside the system: photos, maintenance history, prior fixes. That artifact inventory became the requirements list for what remote helpers needed to see and contribute.
- 03 Identified three critical findings: remote expertise often decides the next diagnostic step, off-platform communication breaks the repair narrative, and access needs guardrails to protect ownership and prevent accidental changes. Each finding pointed at a distinct design lever.
- 04 Designed a permission-based model granting limited cross-location access within the same airline, letting remote mechanics review context and contribute without taking ownership. The four access levels (read only, comment, limited actions, owner) map directly to the three findings: surface context, capture contributions, preserve accountability.
- 05 Ran usability tests with mechanics and managers on realistic tasks: requesting help, joining a ticket from another location, adding guidance, identifying ownership. Iterated until access levels and permissions were immediately clear from the UI. Not training-required. Glanceable.
This feature turned our best mechanics into a shared resource across the whole network. We’re solving problems faster because expertise isn’t trapped by location anymore.
Director of Maintenance Operations · Regional Airline
Team & leadership impact
- Led
- UX and UI design for the cross-base access initiative as Lead Product Designer
- Partnered with
- Maintenance managers, field technicians, and engineering on the permissions model, the audit-trail architecture, and the rollout
The lasting contribution was the framing. AirExpert tickets stopped being location-bound containers and became permissioned, network-aware artifacts. That shift gave product a vocabulary for collaboration that the rest of the platform could build on, and it gave Customer Service a clean answer for “why can’t my team at ORD help with the BUF ticket” that didn’t require a workaround.
What I’d do differently
We launched with four access levels, which was one or two more than the testing actually supported. Mechanics moved between “read” and “comment” fluidly. The distinction added cognitive overhead without changing behavior. If I were running it back I’d ship three levels (read, contribute, own), measure adoption, and add granularity only if the data demanded it. Permission systems accumulate. Subtracting after launch is much harder than adding.
Tickets stopped being location-bound containers. They became permissioned, network-aware artifacts — with the audit trail every aviation regulator still needs to read.