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.

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.

How might we intuitively guide users to find the information they need quickly — on day one, and every day after?

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.

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.