Skip to content
Levityby Katie

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)
MxHub running on an iPad, showing Aircraft Details for tail 453SAe on a 40-minute turn. The left pane groups open issues — three unscheduled including a 3D Gasper Vent fault reported by crew via ACARS, one scheduled inspection, and four deferred MEL items — under a warning that they must be resolved by the 15:40 departure. The right pane opens the selected Gasper Vent fault: a Resolve action, the Boeing maintenance-manual troubleshooting steps, an assembly diagram and parts list, recent repair history from other stations, and the parts, tools and time required.
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.

A maintenance-control desk: three monitors showing a dense route map, a spreadsheet and a chart, a corded desk phone in the foreground, two keyboards, and a notepad with a pen.
A collage of the legacy tools: printed TRAX defect reports listing aircraft and reported discrepancies, a hand-annotated sheet of tail and serial numbers pinned to a board and marked “FAST INSTALLED”, the LineOps Line Maintenance Operations dashboard, and a Maintenance Edit dialog with radio buttons for category, source and type.

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.

Three members of the design team in high-visibility vests and face masks give thumbs-up on the floor of an Alaska Airlines maintenance hangar, with a 737 in Alaska livery parked behind them.
  • 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

Aerospace is deeply hierarchical, and technicians held back in group forums with Leads and senior stakeholders in the room. We moved to one-on-one sessions and interviews — building the anonymity and trust that honest feedback needed.

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.

A technician in a cap, glasses and an Alaska Airlines badge reaches up to a service panel on the forward fuselage of a parked aircraft, with the nose landing gear and a ground power cable beside him.
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

Nearly the entire user base is male, and colour vision deficiency affects roughly 1 in 12 men. The legacy tools signalled status with colour alone. In MxHub every colour is paired with an icon or a label, so no status depends on telling red from green.

Primary user persona

Portrait of the composite technician persona: a man in his fifties with short grey hair and a dark shirt, photographed in a maintenance hangar.

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.

A technician’s shift in three stages, comparing touchpoints, actions, user goals, problems, business goals and emotional experience.
PreparingAccomplishingClosing
Touchpoints
  • Desktop
  • iPad
  • iPad
  • Desktop
Actions
  • Starts shift in the office
  • Opens LineOps to view incoming aircraft and their maintenance work items
  • Prepares for work as needed: orders parts, gathers tools
  • Goes to the aircraft and takes out the paper logbook
  • Completes scheduled checks and routine items as needed
  • Troubleshoots unknown issues — searches manuals, calls Mx Control, sends photos and videos
  • Fixes or defers the issue
  • Fills out the logbook, places it back and returns to the office with a copy
  • Updates status of completed relevant checks in LineOps
  • Uses the copy of the logbook page to enter maintenance information into TRAX
User goals
  • Prioritise work
  • Be efficient by preparing as much as possible
  • Fix issues as quickly as possible
  • Ensure all safety procedures are followed
  • Keep clear, accurate records of all work done on every aircraft
Problems
  • Software is too slow and doesn't load
  • Repeatedly having to sign in to too many applications is time consuming and frustrating
  • Has to search through several manuals, which can take a long time to update
  • Poor connectivity out on the runway
  • No good way to communicate with Mx Control or share files
  • Redundancy — putting the same information in multiple places
  • A paper logbook can't export information, is wasteful, and if the user forgets to enter the logbook page they have to return to the office after leaving
Business goals
  • Provide up to date, accurate information
  • Prevent flight delays and minimise an aircraft's time out of service
  • Maintain accountability
  • Minimise liability
  • Gain insight into recurring problems
ExperienceImpatientFocused, frustratedBored, 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

See Staff Assignment in full

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

    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

Aircraft Details overview for tail 453SAe: an aircraft notes strip, then issues grouped as three unscheduled, one scheduled and four deferred, with a completed section below.

Split-screen

The same screen with the 3D Gasper Vent issue selected. The issue list stays on the left while the right pane shows the maintenance-manual procedure, an assembly diagram, recent repair history from other stations, parts and tools, and a comment thread.

Full-screen

The selected issue expanded to full width for focused work, with the issue list collapsed to a narrow rail of type badges down the left edge.
  • 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

The same screen with a scheduled oil service selected. Instead of troubleshooting steps, the right pane shows oil-amount entry fields for engine one, engine two and the APU, completed and resolved without leaving MxHub.
  • 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
A map of the United States with pins marking the beta cohort's stations: three across the Pacific Northwest, two in California, one in Arizona, and one in Alaska.
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

Every day at Seattle, Anchorage and the other hubs, each Lead printed the crew list and the aircraft list, and every technician on day and swing shift got a printed schedule — 14 to 24 handouts a shift. MxHub aimed to take paper out of the picture.
A photograph of the printed SEA Leads Worksheet: 93 numbered rows of inbound and outbound flight times, aircraft registrations and gates, hand-managed on paper. Crew name columns have been redacted.
SEA Leads Worksheet. Ninety-three rows, assigned by hand, every shift. Crew names redacted.

Before

Seattle, day and swing shift · 14 - 24 technicians

  1. 1Look up the staff sheetAlaska World, M&E resource planning, Seattle Line, the manpower spreadsheet
  2. 2PaperPrint it
  3. 3Assign on paperBy hand, numbered by day of week, junior to senior
  4. 4Build the Lead worksheetExport from LineOps, delete what isn't needed, fill in names
  5. 5Enter assignments into LineOps
  6. 6PaperPrint it again
  7. 7PaperHand out sheets
  8. Time per Lead, per shiftAbout 2 hours

In MxHub

Any station, any shift

  1. 1Set rosterWho's working is pulled in, ordered, and paired automatically
  2. 2Assign aircraftCertifications checked against each aircraft; override any pair
  3. 3Export and releaseOne export to LineOps, live on every iPad
  4. Time per Lead, per shiftUnder 5 minutes
  1. 1. Set RosterDrag technicians from Available, ordered by day-of-week. Pairs form automatically as Tech and Assistant.

    The Set Roster screen on desktop: an Available column of technicians on the left, dragged into day-of-week columns that pair each technician with an assistant.
  2. 2. Assign AircraftAircraft assigned to teams, chips pulled from the roster, amber rows flagging anything still unassigned.

    The Assign Aircraft screen on desktop: inbound aircraft listed against teams, with technician and assistant chips assigned to each and unassigned rows highlighted in amber.

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.

MxHub's Aircraft List on iPad with a per-aircraft chat open for tail 619AS, which is out of service. Mx Control asks for an update, a technician shares a photo of an engine, a coordinator offers to send a reference manual, and the technician replies that they need more time.

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.

The Figma variables panel showing the Semantic collection with Light and Dark columns. Each semantic token aliases a primitive: text/primary points to ios/light/label and ios/dark/label, text/brand points to brand/navy and brand/blue, and the status groups point to their own light and dark fills, texts and borders.

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:1
    Dark21.0:1
  • Text secondary

    Light5.2:1
    Dark7.3:1
  • Success

    Light5.3:1
    Dark7.7:1
  • Warning

    Light6.0:1
    Dark9.9:1
  • Critical

    Light6.5:1
    Dark10.0:1
  • Info

    Light6.4:1
    Dark9.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.

A Figma component sheet of custom MxHub components with their variants, each in its own labelled frame: issue-type badges for unscheduled, scheduled and MEL at two sizes; a light and dark mode switch; issue tags in four states; aircraft status labels for ETA, IN, ON, ETD, ADV, ETR, OTS and OUT; aircraft badges for ETOPS, E-OTS, E-Restricted, OTS and SWAP; an ACARS issue count; stepper steps in three states; and an aircraft status dropdown for pending, in work and complete.

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