Want to keep reading?
The rest of this case study is private, but feel free to reach out to me at alexandr.shor03@gmail.com for the password
Our Impact
40
%
Decrease in Time Spent Logging new damage
3:48 Minutes -> 2:18 Minutes
85
%
Decrease in time spent Finding old damage
1:38 Minutes -> 15 seconds
16.6
Pt
Increase in System Usability Score
70.15 points -> 86.75 points
Key Problem
Mechanics are taking hours to find the damage
With over 2000 planes, Delta needs a system to keep track of a lot of damage. It does that through two tools- the Aircraft Damage File for storing damage info and the Logbook for mechanics to generally log their inspections. But Mechanics were complaining about issues with the current system. Particularly, when we asked mechanics what they needed, we heard:
"I want something where I can find the damage"
Participant #1 - Base Mechanic
Mechanics are struggling to find and log damage with a system that should be working. Why?
Discover
The Problem
3 key questions guided our interview
To build the right product, we needed to ask the right questions, and 3 key questions guided our process:
How do
Technicians find
Specifically, how do mechanics confirm that the damage they see on the plane is preexisting?
How do
Technicians Log
When mechanics do find new damage, what are they recording, and why are they recording what they record
How does
technology mediate
What technology are mechanics actually using? Where are its shortfalls
Key Findings
An unreliable, open-ended, and dependent tool stops work
From 4 contextual inquiries, 27 user interviews, 2 tool teardowns, and a competitive analysis, we discovered that the current application mechanics use fails in several critical ways when other tools don't
#1
Inputs are open-ended, so there's little standardization
Engineers look for. clear, well structured data. But the current system left many fields as just open textboxes. No structure and no standards means mechanics commit cognitive overload to writing "the right way".
#2
Critical visuals are optional, so they become ignored
Photos are an optional entry, and when mechanics are pressed for time, they often won't include photos of the actual damage.
#3
A general 3d diagram for too many different kinds of planes
The current system represents all planes with a generic 2d diagram of a plane, and mechanics select what section of the plane the damage occurs on- but this gives little to no clear info to mechanics about the concrete location of damage.
#4
Mechanics logging away from the plane
Rather than logging a damage instance next to the plane, mechanics instead have to navigate back to their desk, losing valuable time and potentially important info in between
#5
Too reliant on other tools
Mechanics have to move away from the tool in order to find and record relevant structure manual references. Additionally, they frequently have to use other devices to upload photos-an important point of friction.
Downstream issues
Issues with logging leads to valuable time lost finding critical damage, because…
Damage Exists Without Context
When mechanics are looking for damage, they are often missing critical visual context.
Information Can Be Inaccurate
Mechanics are too easily putting in the wrong info. A mechanic might spend hours looking for damage on the left side of a plane when the damage was actually on the right
Entries Are Left to Interpretation
Dozens of damages might be in the same area, and a mechanic may commonly mistake which entry goes with which incident
Our Challenge
How might we design an intuitive, scalable digital twin solution to improve delta's aircraft maintenance?
Ideate
The Solutions
Design Workshop
Designing For Mechanics by letting mechanics design
We had some ideas on what mechanics would want, but to make sure we’re delivering a quality product for our mechanics, we brought mechanics to the design table with some guided discussion using I like, I wish, and I wonder statements centered on a set of preliminary ideas.
3 clear ideas formed the backbone of our application
Guided by our results from the design workshop and a set of user needs and design requirements, we had 3 key concepts:
Centralized Info Linking
Give mechanics access to all relevant manuals from the app, so that it's easy to add them to damage entries
A Consistent 3d Model
Give mechanics access to a plane-accurate 3d model that they can easily operate
Clear Photo taking
Make photo taking mandatory, and provide space for mechanics to provide a clear up-close and clear general photo
Develop
The Prototype
A two-pronged approach to delivery
We knew that we wanted to develop couldn’t just be made as a prototype in Figma, so we took a dual approach- iterate in figma, and develop in an angular framework (with the help of Claude Code) to make our vision a testable reality
Lo Fidelity iteration
How do you balance a model with a log?
Through our lo fidelity, we wanted to try a number of different interfaces, to see how mechanics would want to interact with a 3d model. During this process, we found that mechanics preferred to access a general form first, and then fullscreening a digital model second.
Model First View
Introduce structure by setting concrete steps to the process
Expand Model View
Let mechanics access the model with a tap, since they would want to fullscreen it in any case
Accordion View
Introduce structure by setting concrete steps to the process
Balanced View
Half logging, half model. Filling out how mechanics want to
Mid Fidelity Iteration
Revising the input
In our Mid fidelity, we began to add in clearer data points and refining our design using a pre-existing design system at Delta. However, I soon discovered a very pertinent issue regarding how damage location is recorded:
In mid-fi, entries are poorly structured…
When mechanics indicate the Frame And Stringer (important plane coordinates), the current design is just an open textbox, which begs the question…
“What's stopping me from putting in junk data right now?”
User Comment
Hi Fidelity Iteration
Making sure we model for the user
From high fidelity testing, we discovered our users were frequently getting lost with the model, and weren't clearly understanding how to save a new mark on the model.
Our Problem: From our evaluation we discovered that mechanics had a hard time recognizing how to save their work once they complete adding a location
"Okay…now how do I get out of here…?"
User Comment
Our Solution: Not only did we provide more crisp instruction on navigating the interface, but we also provided more apparent CTA to save the system
Final Product
Mechanics now log easily in a
centralized system…
…And Find Damage in Seconds
Our System Delivers
Faster Damage Referencing
For Mechanics
Cleaner Data
For Analysts and Engineers
More Accurate Logging
For All Users
Evaluate
Product Success
We tested our final system with our end users
Participants
Across Line and Base Maintenance Teams.
Task Based Scenarios
Between-Subjects, randomized tasks for both logging and finding damage
Tested Systems
Comparing our system to multiple preexisting Delta systems for Aircraft Maintenance
Our Impact
40
%
Decrease in Time Spent Logging new damage
3:48 Minutes -> 2:18 Minutes
85
%
Decrease in time spent Finding old damage
1:38 Minutes -> 15 seconds
16.6
Pt
Increase in System Usability Score
70.15 points -> 86.75 points
Reflections
For the Future
Learn the why behind the what: It would be incredible easy to just put together everything mechanics asked of us, but by understanding why they were asking us for things, we went one step further and built a solution that truly met their needs.
Meet your user where they’re at: Only by bringing mechanics to the design table were we able to truly learn how they operated, and what they would be looking in a solution to their problem
Unique tools produce unique solutions: With a large background in 2d ux design, I was operating on a lot of assumptions when I made my Figma prototype. By using Claude Code and Microsoft Copilot, I not only brought my designs to life, but also understood more accurately what worked and what didn't.