Weight and 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 what was about to become the core team of five. We also got a domain expert, a database expert, a mathematician, and a front-end.
The core product team was empowered to shape a working POC 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.
The main pain point for the Airline was missing a proprietary solution for weight and balance, withg a substantial gap in offering and completeness of the software suite we were marketing.
Using a competitor's solution was patching the airline's 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, and non-proprietary, so it was a solution while hurting the rest of our 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 JOURNEYS, FEATURES & PROCESSES
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 aimed to reduce the learning curve and give better visibility over the process - now we stretched up to autoload the aircraft entirely automatic and error-free.
And it all happened live, under our eyes.