programming aircraft sensors

✧

programming aircraft sensors ✧

B2B

Aerospace

Supporting the rapid reprogramming of jet sensors to maintain mission-capable aircraft.

I designed a suite of applications to support the programming of different jet sensor capabilities, prioritizing efficiency, ensuring data accuracy and accountability, and facilitating cross-team communication.

To be able to create complex, technical designs for highly sensitive, confidential information, I received Secret Clearance and spoke to 36 users from several international defense organizations.

Timeframe

Completed over 26 months in 10-week design cycles

*Note: Due to the confidential nature of this work, I cannot share full screens or workflows. All confidential information has been obscured, and the colors and styles have been altered.

Defense

My Role

Principal UX Designer with oversight from a Senior Designer & rendering by a Visual Designer

SaaS

Government

The Problem

  • Design a robust interface that enables rapid reprogramming to support maintained, mission-capable warfighters.

  • Reduce the learning curve by creating an expert system, not a system for experts.

  • The client company aims to revolutionize jet sensor programming with the goal of a 24-hour turnaround on a process that currently takes months.

  • Improved cross-team communication to guarantee data assurance and streamline the entire process.

The solution

  • Create a dynamic visual language to show high-level progress and status information at a glance.

  • Support decision-making and highlight complex data relationships by bringing together and visualizing what has only ever been done in the user’s head.

  • Provide data assurance and accountability by bringing together data from the currently disjointed, unconnected data sources into one centralized database with in-depth version history information.

  • Boost efficiency by allowing users to re-use proven, field-tested solutions in a maintained template library.

my approach

This 2+ year-long project was executed in phases—each application was iteratively designed and tested over an average of 10 weeks.

While the timeline and methodologies varied based on the unique needs of the application being developed, I followed a user-centered design process that included:

  • Discovery (2 weeks)

  • Ideation (1 week)

  • Initial Designs (3 weeks)

  • User Testing (2 weeks)

  • Design Iteration and Documentation (2 weeks)

10

Integrated Applications Created

11

Rounds of User Testing

4

International Organizations Represented

36

Users Participated in User Testing

Discovery phase

Having a full picture of the current system, data, and user needs is essential for us to design a flexible framework that could move beyond individual applications and scale to meet the needs of the system as a whole.

Our first Discovery phase was comprehensive and included two in-depth co-creation activities where we investigated user roles, workflows, customer organizations, and the scope of the project with several high-ranking stakeholders.

Our subsequent Discovery phases typically involved reviewing technical documentation and user stories provided by the client and conducting interviews with Subject Matter Experts (SMEs).

During the Discovery phase, we defined…

  • (A) Navigation model

  • (B) Object-Action relationships

  • (C) Experience maps/User workflows

  • Tool Requirements, such as:

    • User roles and their needs/perspectives for the tool

    • Contextual info on how the tool fits into the framework and tool ecosystem

    • Known opportunities — user pain points, system inefficiencies

    • Key tasks to be accomplished — user objectives and tradeoffs

    • Taxonomy of all system objects and data relationships relevant to the tool

(B)

(C)

(A)

Ideation & initial designs

We broke the goals and problems down into smaller parts, ensuring that each solution is focused on a single task, problem, or behavior. This enabled us to come up with a variety of approaches to address the same issue, ranging from conventional to unconventional ideas.

We identified several concept tensions and clustered ideas near the aligning tension value. For example, we might explore Guided vs. Flexible or Standardized vs. Customizable concept tensions.

We combined elements to define 2-3 opposing concepts to facilitate discussions about design tradeoffs during weekly tag-ups with our clients, identifying which concept or individual elements resonate with them.

evaluate designs with user testing

To gain insight into how to make the product more effective, we conducted both in-person and remote user testing.

  • Research methods varied depending on the client’s limitations and the application being developed.

  • After testing was completed, we analyzed our findings and generated insights and design implications to be included in the next round of design iterations.

design iteration & documentation

After several rounds of client feedback and design refinement, the designs were rendered by our visual designer to align with the desired look and feel of the product.

  • I presented the final product to key stakeholders, alongside thorough documentation of the framework and functionality, a prototype walk-through video, and digital assets for a successful hand-off.

key features & functionality

a complex framework evolution

Throughout the project, our understanding of the system and users became sharper and more nuanced, and as a result, the initial framework evolved to match our understanding.

For example, the visual language evolved from solely focusing on sensor-level status and progress information to include another layer of complexity in communicating the testing performance status.

  • During user testing, we found that users preferred to see red, yellow, and green as progress indicators rather than performance because many programmed components do not have a performance goal.

After we spoke to users from different international organizations, we learned that they conceptualized their work much differently.

  • While one organization thought of their work in terms of flights, another framed their work in terms of geographical areas.

  • As a result, we updated the navigation structure to be more flexible and allow users to change the focus between flight-based and area-based navigation.

At several points, our framework fundamentally changed after learning more about the system as we spoke to more users about our designs.

  • For example, our initial understanding was that several applications programmed different sensor capabilities with one central tool to track component progress and status.

  • However, we discovered that there is another layer in the navigation structure where designer tools bring together data across applications to help users weigh tradeoffs and make more optimized decisions.

This example of the visual language has been stripped of identifying information, and all fonts and colors have been altered.

dynamic table functionality for mass amounts of data

One of the most challenging constraints was finding a way to highlight key information and support decision-making while simultaneously appeasing the users’ request to see all data at once.

  • The user needs to be able to quickly navigate through 40+ columns and compare relevant information across many sensors. However, each user has their own way of approaching their work and cares about different details, meaning there is no universally important data.

The Solution:

Each row can be expanded to show the user all of the details for a single sensor at once.

  • In this expanded view of sensor details, the user can pin a field to lock the corresponding column in place, keeping the pinned column visible on the left side of the table as the user scrolls horizontally.

Additionally, the detail panel acts as in-table navigation.

  • Clicking on a field within the expanded row allows the user to filter by the field value, select all rows with the same field value, hide the field column, or jump to the corresponding column within the table without having to manually find it using the horizontal scroll.

There was a big demand from users to cut down on the number of clicks it takes to accomplish their goals and reuse trusted elements whenever possible.

  • One way we supported that was by allowing users to save sort, filter, and data grouping settings for quick access during their workflow.

  • Users can customize saved views for their personal use or share them with team members for more efficient collaboration and training.

This table design highlights object status on the left and relevant actions on the right, with the large amount of data associated with each object in a horizontal scroll, with in-table navigation and table customization available.

making critical changes with a sandbox feature

Mirroring the concept commonly used in software development, the Sandbox feature allows users to make changes at a higher level and preview any potential downstream effects before committing.

After speaking to users, we found that they did not like having to open a secondary feature, with one user stating “When I open the designer application, I want it to act like a sandbox.”

To shift the focus of the page and allow users to actively make sensor design decisions, some sandbox behaviors were incorporated into the rest of the applications, with all changes and potential consequences captured in a side panel that can be collapsed and accessed as needed.

defining system-wide variables to auto-populate reports

To be able to automate report generation and maintain a database of report templates that adapt to ever-changing variables in the field, I created a secondary variable database feature where users can define variables and set parameters in great detail.

These variables can be called on later to auto-populate values, tables, and calculations in report templates so that users do not have to manually record calculations and values from other areas of the system.

  • There are several types of variables that can be created for different types of data: Team metrics, Lists, and Single value variables. Selecting the variable type determines the fields and parameters below.

  • Table columns can be hidden and reordered, sort and filter settings can be defined, and users can create a variable based on saved views.

After selecting the type of variable at the top, they can customize the variable parameters below and see a preview at the bottom.

“we’ve taken a crack at this exact problem and our solution looked terrible… this looks infinitely better than what we cooked up.”

— Client feedback on the variable database that feeds into the Report Generation tool

Biggest Challenges

Complex engineering concepts, obscured by several layers of abstraction

While we went through the lengthy process of Secret Clearance approval, we were severely limited in what we were allowed to see. All materials had to be unclassified, which proved difficult when we needed to understand the “Why?” and “How?” of the user’s decision-making process.

Our limited access to realistic data and full technical details forced us to be more creative with how we came to an understanding of the user and system needs and the way we developed solutions to meet those needs.

Research constraints

Our ability to interact with users and gain their feedback was severely limited due to security concerns and user scheduling availability. As a result, we were unable to record research sessions for playback and analysis after the fact, so the note-taker had to maintain diligent and comprehensive notes.

We also ran into a problem with the lack of realistic data — some participants could not ignore the inaccurate placeholder data, framing their feedback around the fields and values rather than the overall workflow and framework.

Vastly different user organizations

Bridging the gap between international customer organizations proved challenging, as I was required to design for user needs, processes, policies, and mental models that are vastly different and often directly contradict each other.

However, I am grateful that this challenge forced me to think outside of the box and design a system that is flexible enough to meet the needs of every user without compromising performance.

Evolution of my role and responsibilities

This project was a fantastic growth opportunity as I evolved in my role from supporting designer to design lead, taking on more responsibilities like scheduling and project management, client communication, planning and leading user research sessions, system-level thinking, framework development, and direction-setting for a long-term contract.

impact of designs

  • We created a solid foundation on which our client can base their evolving product. Our fortified framework and solutions not only meet their current needs but will scale to meet their needs far into the future.

  • Our designs support decision-making by allowing users to investigate complex data relationships in dynamic visualizations, which provides confidence and accountability for processes that have only ever been done in the users’ heads.

  • By facilitating cross-team collaboration and template database management, we streamlined user workflows and cut down the time it takes to program aircraft sensors from several weeks to 48 hours, which is crucial for reacting to intel updates and maintaining mission-capable aircraft.