
Alaska Airlines · End-to-end design · iOS
MxHub — empowering aircraft technicians and automating maintenance for Alaska Airlines.
Solo product designer leading research, strategy, and end-to-end design on a 2-year MVP to consolidate legacy systems into a cohesive platform.
Explore the prototype(opens in a new tab)
- Role
- Sr Product Designer (solo)
- Team
- 1 designer · 5 eng · 1 PM
- Dates
- Nov 2021 - Jun 2023
- Platforms
- iPad-first · Desktop added
Problem
A fragmented, manual workflow with very little margin for error.
Tedious, redundant tasks across shifts and stations. Legacy tools on the path to being decommissioned. Nothing was automated. And with many long-tenured technicians nearing retirement, onboarding new hires to non-intuitive systems would be painful and time-consuming.
Solution
One integrated system, built for intuitive design and automation.
MxHub — an iPad-first system absorbing legacy tools into one framework. By the end of the MVP it carried the full functionality of Mobile Oil, LineOps, and the paper Staff Assignment ritual, with the maintenance manuals and aircraft history alongside them.
Impact at a glance
- Business cost saved
$5.9M
Estimated from testing and use: ~45,000 labour hours saved a year, plus fewer delays from faster troubleshooting.
- Faster workflows
24×
Most visibly in Staff Assignment — 2 hours to under 5 minutes per shift.
- User satisfaction
78%
CSAT score from user surveys.
Environment & problem space
Understanding the problem.
Various stations, shifts, tools, workflows, climates, and requirements. All of it needed one system that could adapt to each — without ever trading away efficiency or reliability. MxHub had to run alongside the tools it was replacing, absorbing them one at a time.


Why it mattered
A delay costs money. A missed defect costs more.
Maintenance & Engineering had been neglected for decades. Coordinators worked from desktop dashboards. Technicians worked on the ramp — with clipboards, paper, and a walk back inside every time they needed an aircraft's history.
Every aircraft on the ground has a meter running. The longer a technician spent hunting for information and troubleshooting, the longer it sat — upsetting passengers, frustrating technicians and crews, and costing the company. And every defect is part of a regulated safety record: miss one and the consequences can be fatal.
Tools & processes
Workflows scattered across tools
No shared data layer, and no shared vocabulary. Every tool had its own login, its own load time, and its own update cycle. The same work looked different in each one, and which channel carried it — screen, radio, paper — changed by station and by shift.
Locations & climate
14 stations, every climate
14 stations across the network, from Anchorage to Honolulu, each with its own workflows, team sizes, and capabilities. The same UI had to work in -40°F winter gloves, in 120°F summer glare, and over whatever connectivity the ramp happened to offer.
Shifts & stakeholders
Thousands of workers, no single view
Three daily shifts of technicians, plus Leads coordinating the floor and Mx Control dispatching from a central operations hub — across two carriers, Alaska and Horizon, each with its own systems and certification rules. Every role worked in different tools and needed different things at handoff, so miscommunication was baked into the workflow.
Challenges & constraints
Union rules, long habits, a hard deadline
Union agreements governed how work could be assigned, and to whom. Many technicians were long-tenured, with mental models built over years around the paper process. And the legacy tools were sunsetting in under 12 months — there was no option to iterate indefinitely.
Tool sprawl · 16 systems a technician touched in a day
A fragmented ecosystem of tools and workflows.
Device type
- Desktop
- iPad / mobile
- Web
- Paper
- Voice
- Aircraft datalink
- LineOpsIncoming aircraft + maintenance work per tail. A web app that ran on desktop and iPad — the primary surface for coordinators, Leads and technicians.WebDesktopiPad / mobile
- AirExpertHorizon's MX queue, on desktop and mobile. Used in parallel with LineOps; data didn't sync.DesktopiPad / mobile
- Aircraft HistoryPer-tail record of past issues + mods. Read-only; updates lagged TRAX.Web
- Mobile OilAn entire app whose only job was capturing oil amounts.iPad / mobile
- TRAXSystem of record. Every defect, fix, and sign-off had to land here.Web
- Paper LogbookTravelled with the aircraft. Each shift's notes hand-written.Paper
- AMMAircraft Maintenance Manual. Searched by ATA chapter.Web
- FIMFault Isolation Manual. Cross-referenced with AMM by hand.Web
- GreenlightQX / Horizon cert validation. Only for QX aircraft.Web
- Staff WorksheetLead's daily printout. Hand-marked. 2-hour “craft time” ritual.Paper
- Crew boardRoster on the wall. Updated by hand at every shift change.Paper
- Cert databasePer-tech certifications. Pulled manually for every assignment.Web
- RadioRamp comms. Channels varied by station and shift.Voice
- PhoneMx Control by phone. Single-threaded; lost when the tech walked away.Voice
- ACARSFlight-deck datalink. Crew typed a fault on the aircraft keypad and it landed in LineOps — as a message, not an open defect.Datalink
- EmailDocuments, escalations, sign-off PDFs. Where things went to wait.Web
Research
Understanding our users.
To build a comprehensive solution, I first had to understand the pain points and complexity of aircraft maintenance, and the stakeholders who keep it running. That meant collecting a lot of data: shadowing technicians and Leads at various stations, conducting interviews, sending out surveys and working with beta users — and mapping every supporting tool to find the systemic gaps, redundancies and opportunities.

Behavioural observation
Shadowed techs, Leads, and Mx Control across shifts and stations.
Interviews
One-on-one with techs, Leads, Mx Control, Engineering, and Parts.
Anonymous surveys
Anonymous, so technicians could answer honestly without being identified.
Competitive analysis
AirExpert (Horizon's tool) and task-management apps that informed the IA.
One adjustment we made
The workarounds
Key pain points, and the workarounds they created.
Each one cost time, added another place to make a mistake, and had to be learned by every new hire.
Fake “unscheduled MX” entries as shift notes
No field existed for shift-to-shift notes, so techs filed non-defects in TRAX for the next shift to read. Real defects mixed with shift gossip in Mx Control's queue.
The same defect entered three times
Open it in LineOps. Write it in the paper logbook. Transcribe it into TRAX at end of shift. One chance per system to fat-finger the tail number.
A roster that broke the moment anything changed
The crew board lived on the wall and was re-printed by hand at every shift change. Certifications came from three separate sources — per tech, every assignment.
People
One primary user. Many stakeholders.
The primary users were aircraft technicians on the tarmac — and, often, the Leads coordinating them. But Maintenance & Engineering is a tightly interconnected ecosystem: every role relies on the others, each working in a different workflow, on an overlapping set of tools.

- Technicians using MxHub daily
- 1,000+
- Identify as male
- ~95%
- Majority tenure on the job
- 20+ yrs
- Typical age of the population
- 50+
What the demographics changed
Primary user persona

Eric Gregson
- Age
- 54
- Seniority
- 24 years
- Title
- Aircraft Technician
- Priority
- Safety
An experienced aircraft mechanic, Eric takes pride in his work and puts safety above all else. He feels pressured by management to work quickly, and is sometimes frustrated by the constant communication across different channels. He's open to new tools if they're easy to use — but prefers old solutions and pen and paper.
| Preparing | Accomplishing | Closing | |
|---|---|---|---|
| Touchpoints |
|
|
|
| Actions |
|
|
|
| User goals |
|
|
|
| Problems |
|
|
|
| Business goals |
|
|
|
| Experience | Impatient | Focused, frustrated | Bored, obligated |
Why safety is the priority. Safety here is personal liability. A technician signs off on work that keeps an aircraft in the air, and can be held accountable if it is wrong.
Secondary user — the Lead.
Plans the day's work before techs arrive on the floor. Assigns aircraft based on certifications, work-week, and unit. Manages shift handoffs and escalates what can't be resolved on the floor.
Desktop tier — Staff Assignment and Aircraft List
Our other stakeholders.
Mx Control
Ultimate authority on MX
The technician's main resource when troubleshooting stalls, and the approval on the fix.
Parts Department
Inventory, stock, tooling
The source of the tools, parts and equipment a fix depends on.
Flight Crew
Cabin + cockpit, departure-side
Usually the first to report an unscheduled fault, and the most exposed to the delay that follows.
Gate Agents · Customer Service
Passenger experience
Where a delay turns into a customer problem — the bridge between maintenance and users.
Station Manager
Station-level oversight
The aggregate picture — how many aircraft are out of service, and where the bottlenecks are.
Air Traffic Control
Downstream operations
Delays, gate changes and aircraft swaps, which ripple through the rest of the day's schedule.
Information architecture
Matching the structure to the workflow.
Rather than mimic the existing systems, we emulated the IA of task-management software. Every piece of data connects first to the issue, then to the aircraft — so each tool folds into the technician's existing workflow instead of becoming a separate step.
MxHub
Sidebar
Single sign-on: MxHub is the gate to every tool a technician uses — one login, no re-authenticating on the ramp.
- Aircraft History
- Green Light
- ITS Service Desk
- Kronos
- LineOps - ASPending removal
- Line Mtx Workload
- Manuals
- Mobile OilPending removal
- MOD Status
- Staff Assignment
Alaska internal
- Alaska World
- Outlook
Screen 1
Aircraft list
- ETA · ETD
- ETOPS tag
- Ground time
- Gate and status
- Mx issue count, by type
Screen 2
Aircraft details
Every issue on the tail:
- Category
- Description
- Manual reference
- Reported by
- Status and due time
- Unscheduled
- Scheduled
- Deferred (MEL)
- Complete
Screen 3
Issue details
Where the work happens:
- Manual reference and guidelines
- History
- Troubleshooting
- Photos and videos
- Comments, tagging and @mentions
- Resolution steps
- Logging the resolution
The solution
Empowering technicians on the tarmac.
MxHub sought to integrate and automate technicians' workflow — improving efficiency, minimizing delays, addressing pain points, and creating an intuitive experience for future hires. This MVP laid the groundwork for a larger, more comprehensive system.

The technician flow, clickable — Aircraft List through to a resolved issue.
Open in Figma instead(opens in a new tab)Step 1
Aircraft List
The tech's morning queue. Issue counts, gate, ETD and status pills readable in one scan.
1— jump to Sidebar menu with single sign-on2— jump to Responsive grid built for iOS Dynamic Type3— jump to Personalised saved filters- 1
Sidebar menu with single sign-on
Fingerprint into MxHub, then one tap to any other tool — no re-authentication, no password resets. As MxHub absorbed each legacy tool, its sidebar item retired with it.
- 2
Responsive grid built for iOS Dynamic Type
With the population skewing 50+, large-text support was a layout requirement rather than an afterthought. The grid was tested at the largest setting first.
- 3
Personalised saved filters
Each user pinned the filters matching their work — My Assigned, All Station, ETOPS, or a custom combination. The list adapts to whoever opens it.
Step 2
Aircraft Details
An aircraft-level overview that did not exist before MxHub — every issue on the tail, prioritised, with troubleshooting on the same surface. Three states support the work: overview, split-screen with an issue selected, and full-screen for focused work.
Overview

Split-screen

Full-screen

Every issue on one screen, ranked
LineOps gave a lineup you clicked into one issue at a time — no overview, no hierarchy. This shows every issue on the tail at once, ordered by what blocks the next departure.
Split-screen, borrowed from email
See the whole list while working a single issue — the pattern people already know from mail and task apps. It also reflows better at large text sizes than a nested drill-down would.
The manual comes to the issue
Relevant maintenance-manual sections are pulled in by ATA chapter — no separate app, no searching. Photos, attachments, comments and @mentions all attach to that issue.
Step 3
Resolve issues
Every issue has to be resolved for an aircraft to keep flying. An unscheduled issue is either fixed quickly, deferred to be fixed later, or — worst case — the aircraft is taken out of service (OTS). Every resolution, fixed or deferred, needs a sign-off and a record.
Bringing resolution into MxHub made redundant steps, and whole pieces of software like Mobile Oil and the paper logbook, unnecessary. The technician signs off once: TRAX takes the permanent record, LineOps takes the status, and Aircraft History reflects it downstream.
Oil service

- Resolve
Resolution form, tailored to the issue type and recorded to history
TRAXLineOpsAircraft HistoryE-Logbook - Defer
MEL category, remaining days and Mx comments
MEL deferred list - Escalate
Aircraft put on OTS, with troubleshooting continued
Mx Control thread
Validation
How we tested what we built.
- An advocate user group gave rapid feedback in Teams
- Prototype testing across roles and stations
- Early testers became champions for adoption

- SUS rating out of 100 — Grade B
- 76.38
- CSAT rating out of 100 — “Good”
- 78.3
Two measures, deliberately: SUS scores usability, CSAT scores satisfaction. The 78% in the opening is this CSAT figure.
Automating staff assignment
From 2 hours to 5 minutes.
For team Leads, staff assignment was a tedious, manual process — especially at larger stations during busy shifts. Aircraft had to be assigned to teams of technicians based on seniority, qualifications, the day of the week and some preferences. That meant inputting into multiple spreadsheets, highlighting printouts, and checking qualifications in systems that didn't update or communicate with each other — a ritual Leads referred to as “craft time.”
The paper trail

Before
Seattle, day and swing shift · 14 - 24 technicians
- 1Look up the staff sheetAlaska World, M&E resource planning, Seattle Line, the manpower spreadsheet
- 2PaperPrint it
- 3Assign on paperBy hand, numbered by day of week, junior to senior
- 4Build the Lead worksheetExport from LineOps, delete what isn't needed, fill in names
- 5Enter assignments into LineOps
- 6PaperPrint it again
- 7PaperHand out sheets
- Time per Lead, per shiftAbout 2 hours
In MxHub
Any station, any shift
- 1Set rosterWho's working is pulled in, ordered, and paired automatically
- 2Assign aircraftCertifications checked against each aircraft; override any pair
- 3Export and releaseOne export to LineOps, live on every iPad
- Time per Lead, per shiftUnder 5 minutes
1. Set RosterDrag technicians from Available, ordered by day-of-week. Pairs form automatically as Tech and Assistant.

2. Assign AircraftAircraft assigned to teams, chips pulled from the roster, amber rows flagging anything still unassigned.

The chat feature · a lesson learned
Advocating for users, speaking to stakeholders.
After discovery we had a plan: an IA modelled on task management, validated with the beta cohort. Then we were asked to add a per-aircraft chat. I pushed back, citing the user research. The chat went forward.
It shipped, and the MVP timeline slipped across the board. Technicians refused to use it, and it emerged that Mx Control's software could not receive what the chat sent. We reverted to the original plan — but it had cost trust and valuable time and money.

The case I made
Users won't adopt this. Troubleshooting in a chat raises compliance risk on a regulated record. It adds a notification channel without removing one. And a thread anchored to the aircraft is the wrong mental model when troubleshooting is issue-specific.
The case it needed
This is twelve developer-weeks against this quarter's roadmap, and it delays the work already committed. We also haven't confirmed Mx Control will use it, or that their system can receive what we send.
Design system
Blending iOS foundations with Alaska's branding
As an iPad-first product, we used a foundation of iOS native patterns aligned to the iOS Human Interface Guidelines, and used SF Pro and SF Symbols to support Dynamic Type and hardware settings, while layering on Alaska's themes.

One system, two modes.
The system leverages Figma variables: a base layer of primitives, with semantic tokens layered on top to support light and dark mode.


Text primary
Light21.0:1Dark21.0:1Text secondary
Light5.2:1Dark7.3:1Success
Light5.3:1Dark7.7:1Warning
Light6.0:1Dark9.9:1Critical
Light6.5:1Dark10.0:1Info
Light6.4:1Dark9.8:1
surface/primary surface/secondary surface/brand border/separator border/default border/strong
Type
The SF Pro ramp, carried as tokens so Dynamic Type scales and adjusts for accessibility settings on devices.
- Title 2 · Emphasized22 / 28 · Bold
- Headline17 / 22 · Semibold
- Body17 / 22 · Regular
- Callout16 / 21 · Regular
- Subheadline15 / 20 · Regular
- Footnote13 / 18 · Regular
- Caption 2 · Emphasized11 / 13 · Semibold
Spacing & radius
An 8px grid base throughout, with a 44pt minimum touch target on iPad — adhering to iOS patterns and HIG practice.
- 4
- 8
- 12
- 16
- 20
- Minimum touch target on iPad — sized for gloves
- 44pt
- Minimum target on desktop, where a cursor is available
- 32pt
Components, built to adapt
Components were built atomically. We used iOS library components where they were relevant, but the majority were custom-built to support our use cases and our users. All of them are based on variables and modes, with accessibility built in — keeping Dynamic Type, hardware accessibility settings, and usability best practice in mind.

Reflections
What we did, and what I'd do differently.
In the end, we built a robust MVP in just 18 months — one that replaced several legacy tools and improved accessibility and automation across a complex system. Looking back, here's what I learned, and where MxHub could go next.
Lessons learned
- Advocate with business risks, not just user experience.Name the assumptions, ask for validation, and keep challenging the request.
- Honest feedback needs a safe channel.In a hierarchy, group forums went quiet — one-on-ones and anonymity got real answers.
- Design for the hardest case, then check it scales down.What worked for a 24-person Seattle swing shift also had to work for a station of two or three.
- Adoption comes from familiar patterns and early champions.Task-management patterns and beta testers turned advocates helped long-tenured technicians take to MxHub.
Future development
- Continue to build out a more comprehensive experience
- Use AI to pull only relevant manual information
- Absorb more of the existing tools
- Create and integrate the E-Logbook