Aviation Engine Diagnostics Platform

Aircraft Engine Diagnostic Platform


With a growing number of more advanced engines coming online, a top aircraft engine supplier needed to revamp the aging data architecture they used to process flight reports for near real-time, in-flight engine diagnostics, a cornerstone of their Support Division. But to work with this new architecture, the engine supplier also needed a new application. One that would combine and improve on the functionality of three legacy tools, as well as, introduce new concepts and ways of interacting with flight data. I was tasked with leading the design effort.

Role: UX Design Lead

My Contribution:

  • User Research
  • Journey Maps
  • Task Analyses
  • Wireframes
  • Interactive Prototypes


My team and I set out to discover the full extent of our problem by first interviewing business stakeholders and SMEs familiar with both the new and legacy architecture. We then sat with our users to get their insights into the legacy tools and understand where and how they worked. It didn't take long to identify what they considered to be the most pressing issues. The support technicians wanted more visibility into "black box" components to improve troubleshooting and faster processing times for their massive data-sets. Support Leads wanted more robust testing capabilities and a way to monitor the entire system to track errors and better predict downtime.

Using the gathered insights along with several task analyses we'd conducted with users, we began to define the requirements for our solution using journey maps and UI screen flows to outline the needed functionality and then presented that information to the stakeholders and users. I made a mistake here by not getting the development team creating the new architecture involved in the review process, and instead, accepted the business stakeholders assumptions about the new architecture. I did eventually correct the mistake. More on that later.

With feedback from our users and SMEs, we further refined the UI flow diagrams and tied those directly to user stories. The design for our solution came next. Using our UI flow diagram as a sitemap, we created wireframes to visualize how the various components would appear on each screen. We went back to ours users with each "completed" screen to get their feedback. At this time, we also led design initiatives to generate more ideas: co-designs (with users), mob-designs (with other designers), and design sprints (with our stakeholders, SMEs, and developers). Trying out and testing those ideas those ideas allowed us to quickly iterate on the designs until the users and product owners agreed we'd hit the mark.

Mob Design Session
When tackling new or complex ideas, a design sprint or co-design offer a chance to collaborate ane ideate quickly.


Workflow Details

Our users need to understand the big picture when making changes or adding new components to the system. Being able to view and edit all of the various components of a workflow in one place increases users' understanding and confidence when using the app, reducing errors.


  • A treeview to visualize hierarchical relationships
  • Syntax-checking to reduce typing errors
  • Highlight changes so users can track their work
  • Type-ahead inputs for less-experienced users
  • Shorthand codes for more-experienced users

System Dashboard

Support leads and technicians alike want a more transparent system so they can better troubleshoot performance issues. They also need to see which reports are in the pipeline and where they're at in the process to ensure they have a comprehensive view of the data.


  • Customization for users with changing needs
  • More targeted and in-depth metrics
  • Filters to provide more precise data snapshots
  • Notify users of system updates or interruptions


To understand the effect of their changes, our users need to see trends over extended periods of time rather than single outcomes. We provided a "safe-space" where users could test their changes against up to six months of production data.


  • Test in a "safe" environment using real data
  • Real-time feedback to reduce users' concerns
  • Highlight changes so users can track their work
  • Data library allows users to store and reuse data
  • Custom treeview pattern improves functionality


As a designer, relationships are everything. Maintaining a good relationship with users is required and obvious, but having a good relationship with those who may seem tangential to the project at first can be just as important. It's only as your understanding grows that you see how others might be more connected than initially thought.

Given another chance, I would've pushed to get the team that built the new data architecture more involved earlier in our process. Although we spent considerable time developing an overview of the new architecture, we accepted too many of our stakeholders assumptions. I attempted to address this by pushing for and getting that team more involved. We soon had a few key members of the team attending our weekly reviews and sprint planning to ensure everyone was on the same page.

We experienced the importance of maintaining good relationships firsthand with our development team, who recognized some discrepancies between the data being returned and what we'd initially anticipated. Because we talked to them daily and made it clear we wanted their ideas and feedback, they didn't hesitate to point out these issues. We were then able to quickly revamp the designs using the the new information.