I led the experience architecture for a complete redesign of MyGEAviation.com — GE Aviation’s primary customer portal for airline engine management. I helped transform a deeply fragmented set of disconnected tools into a flexible, role-aware platform that engineers at any airline, of any size, could actually use from day one.
My Role
Experience Architect
Collaborators
Product Managers
Engineering Teams
UX Designers
Researchers
Executive Stakeholders
Internal & External Users
Skills Used
Design Leadership
Strategic Planning
User Interviews
Whiteboarding
Wireframing
Prototyping
Usability Studies
Duration
1 Quarter
The Problem
A platform that did everything, and felt like it
Picture this: A flight is midway to Mexico. An on-call powerplant engineer gets a call: there’s an issue with one of the engines.
On that plane are real people: families, honeymooners, travelers who have been looking forward to this trip for months. The pilots need to know: do we keep going, or do we turn back?
The engineer’s job is to get to the right data, fast, and help make the best possible call. That is the weight of what powerplant engineers carry every day — responsible for everything touching a jet engine, from real-time troubleshooting at 30,000 feet, to tracking parts through a repair, to making sure the airline always has a spare engine ready so flights don’t get cancelled.
At large carriers like Delta or FedEx, specialists handle each of those areas. At smaller regional carriers, one or two engineers manage all of it for the whole airline — sometimes with nothing more than a whiteboard.
Before: day one
Before: after figuring it out
Left: what every new user saw. Right: what a power user eventually built, but only after significant trial and error, or help from a colleague.
The platform was built on a concept of “widgets,” full applications loaded inside modal windows, each owned by a different internal team, connected to virtually nothing else. No unified search. No shared notifications. No coherent mental model.
200,000 support requests per year, specifically about onboarding and account setup. Users weren’t tripping over edge cases. They couldn’t figure out how to get started.
The Approach
Research first, sprint second
Before sketching a single wireframe, our team traveled to Southwest Airlines in Dallas to observe powerplant engineers in their actual environment. What we saw reframed the entire problem.
Engineers didn’t think in terms of features. They think in workflows. An engine alert didn’t mean “go check the diagnostics widget.” It meant: check diagnostics, open a case, pull up technical documents, and potentially order a part, often in the same session, under time pressure. The platform didn’t support any of that continuity.
Field research — Southwest Airlines, Dallas TX
Observed engineers in their real environment. Discovered they think in workflows, not features.
10 user interviews — large and small carriers
Validated findings and sharpened the large vs. small airline distinction. Any solution had to flex across both.
Design sprint + hackathon
Rapid concept generation and cross-functional alignment. This is where the central design debate surfaced.
10 usability studies
Tested the strongest concepts with real users before committing to build.
How might we intuitively guide users to find the information they need quickly — on day one, and every day after?
The Key Decision
Customization vs. static templates
The central design debate wasn’t about visual style. It was architectural: how should users — across tens of thousands of accounts, dozens of job functions, and wildly different airline sizes — find their footing on a platform with dozens of features?
This wasn’t resolved in a single meeting. Winning it required building relationships across the org — finding allies who could advocate for the approach when I wasn’t in the room.
The best design argument in the room doesn’t win if you haven’t done the work outside of it, because you can’t build great software without great relationships.
The solution that shipped was a layered model: role-based starter layouts that teams could customize and share. Engineering constraints meant we trimmed the range of tile options in the final build, but the core principle held — teams own their defaults.
The Solution
Predefined layouts. User-owned customization. Global connectivity.
New users land on a layout selector that shows exactly which features are relevant to their role — with a plain-language description of what each layout includes before they commit.
A brand-new powerplant engineer picks “Technical Support” and has a relevant, working dashboard from the moment they log in. No blank canvas. No hunting. No call to the help desk.
Experienced users can modify, rearrange, and add tiles from there. Teams can build their own configurations and share them with colleagues or incoming team members. The “Start From Scratch” option exists for power users who want full control. Users can even create multiple dashboards to separate their different workflows.
Integrated global search and unified notifications tied the platform together for the first time. Features that previously existed in complete isolation could now surface related information across the product.
The Impact
Measurable results on day one
−40k
Support tickets eliminated per year
Users could set up their accounts and find their tools without calling for help — something that hadn’t been true since the platform launched.
−35%
Reduction in GE associate labor hours
Improved self-service meant engineers spent less time on hold and more time doing their jobs. GE associates spent less time answering the same onboarding questions.
Day 1
Productive from the start
New users could find and use the right tools without a tutorial, a phone call, or a colleague walking them through it. For a platform managing 45,000+ engines across the world’s airlines, that matters.