Opfyx
Partnering with an aviation startup to help build the future of aviation. Designs that touched everything from raw sensor data to the pitches aimed at winning new business.
Role
Senior Product Designer
Type
Aviation Ops
Early-stage Startup
SaaS
Timeline
7 Months (2026)
The Problem
An early-stage aviation ops startup needed to both win new enterprise clients through strong RFP-ready product work, and mature a core platform inherited from a previous design team.
What I Did
Took over design end-to-end. Core flows like navigation, authentication, and chat, plus a real-time ops dashboard that meant learning aircraft turnaround operations from scratch to design it well.
Result
Most designed features shipped, including AI-assisted flight and aircraft popups. The engagement wrapped due to Opfyx's funding timing, not performance.
I joined Opfyx as a contractor, taking over design from a previous studio at a startup building tools for the whole aviation ecosystem: airlines, airports, ground handlers. Most of my work was feature by feature, some entirely new, some optimizing what existed. The biggest and most complex piece was the supervisor control dashboard and alerts system, built from nothing but a list of requirements.
Turning field notes into something buildable
I worked from requirements gathered directly from airport staff by our CTO, then turned that raw list of needs and issues into something actionable, clarifying ambiguous requirements, grouping related pain points, and shaping loose notes into real information architecture. There was no existing dashboard to react to. This was built from scratch.
Building for data you don't know yet
The dashboard started with a single use case, Janitorial, but the team decided early to make the system scalable to future ones like Maintenance, without knowing what those future data types would look like. That forced a three-level structure: a Group (like a check-in area) containing Assets (like a bathroom) containing Sensors, where every sensor could report data differently. The real challenge was building a genuinely reusable table that could display whatever came in without needing a redesign every time a new use case or sensor type got added.
Alerts that resolve themselves
Alerts needed two states: severity (high or medium) and read/unread. The twist was that an alert doesn't get resolved by a person marking it done, it gets resolved by a new sensor reading. That meant designing around something unusual: telling apart "I've seen this" from "this is actually fixed," when resolution isn't a user action at all. Getting that balance right mattered a lot, given how fast-moving and high-pressure the intended users' days already were.
Beyond the dashboard, a huge amount of day-to-day coordination happened in chat, so messaging got just as much design attention, down to voice notes and quick reactions.
Navigation went through several rounds of iteration, and so did AOG (Aircraft on ground, the industry term for a plane that can't fly) reporting. Giving ground teams a fast, clear way to flag and track an AOG mattered just as much as anything on the main dashboard, since a grounded aircraft is exactly the kind of problem people need to report and follow up on fast.
Task management needed the same clarity as the dashboards: always answering one question fast, what do I need to do right now?
Even at the level of a single flight, the same at-a-glance clarity had to hold up.
Beneath all of it sat a harder structural problem: allocating limited resources, gates, staff, equipment, across a system that never fully stops moving. The same reusable-table thinking from the dashboard carried through here too.
Where it landed
Most of what shipped is still in use today. And because Opfyx works across multiple operators, the system had to flex: the white-labelled views shown here are proof the structure holds up across different brands, not just one. The engagement wrapped when Opfyx paused external design work for funding reasons, not performance.