Weight & balance is a specific and mandatory procedure in any airline and airport operation. The company had no existing software solution, so we aimed to fill a product gap and fix the pain points that our competitor solution was offering or introducing into a standardized procedure.
Since most of the market was using either console-based solutions or pen and paper procedures, we were aiming at a digital product that is failsafe, sustainable, and automated.
We built a live working demo for an extremely complicated solution, with actual data of real flights, and no back-end, in less than half year, with a team of five people.
I joined as a lead Product designer in a team that I started. We got a domain expert onboard, a DB, a mathematician, and a front-end, which formed the core product team to shape a working product prototype with accurate actual data — end-to-end weight and balance process.
Sure we had a 150 people developers team overseas, but no one had the weight and balance expertise, and no one was in charge of the product except the core team.
A main pain point for the Airline was missing a proprietary solution for weight and balance, having a substantial gap in offering and completeness of the software suite we were marketing.
Using competitor's solution was patching the airline need but offered several downsides. A few of the downsides considered were an extremely long and costly learning curve, no overall view and understanding of the weight and balance process, high costs and maintenance, non-proprietary, so it was a solution while hurting the software suite overall.
Training people into weight and balance take just way too long and requires senior supervision, not to mention the regulatory chains and risks involved.
Having an extremely short timeline of just a few months to demonstrate a project of such complexity, we decided to build a live working demo with actual data, real flights, and no back-end.
I started by having regular stakeholder meetings to understand the business gaps, evaluate the product, and split modules into correct revenue pillars.
By driving the design thinking sessions with stakeholders and senior leadership, we identified ways to structure the product to build a highly modular solution that drives impact and is cost-effective for our clients. At the same time, I aimed to maximize effectiveness and simplify the life of our users, automate the whole process, and make sure we design our product to cover all business needs of an airline or airport.
After clearly articulating how our solution impacts every operational aspect of an airline or airport, we proceed to define the primary personas for our product.
The stakeholders' conversations started before, continued on their respective pillars, and formed the product ownership.
Based on the discoveries meetings, we started planning discovery meetings with users we identified on their respective pillars - airline flights admin, cargo admin, cargo user, load controller, chief load controller, pilot, operational, etc.
While doing this, in parallel, we started deconstructing and analyzing the competition, researching the features they offer, how we can outsmart the offering, and adding more value for the user.
Since we knew the linear weight and balance process, we already had the personas, and we started interviewing people– it came naturally to build up the user journey and different lifecycles of the process.
Wireframes started very early, and we used them the first time to paper prototype right in the discovery phase. It took some ideation and iterations, but we felt confident that we responded to the right needs.
So we moved the paper prototypes into digital wireframes to get a sense of the estate and ensure we could scale to various devices.
Keeping in mind that the product could change quite a bit during the feedback and iterations and a very short timeline,
I decided on a different design strategy - BUILDING IT LIVE!
The wireframes were prototyped straight into the front-end code to test and simulate properly on devices like desktops and tablets.
Since we grew wireframes into the code and kept adding details, it was a breeze to flesh the design out on top of our foundation.
Same as with the wireframes, the design kept growing and adding consistency and detail on top of the features until we got a solid interface to sustain and build differentiators for our products.
While in the beginning, we were aiming to reduce the learning curve and give better visibility over the process - now we stretched up to autoload aircrafts entirely automatic and error-free. And it all happened live, under our eyes.
Copyright © Supraelastic. All rights reserved.
Any material on this website, concepts, copy, and work, are the property of supraelastic, or supraelastic's clients.