overview
At a deep-tech startup specializing in quantum-inspired optimization algorithms, a robust mathematical engine for aircraft crew assignment had been developed. My role as a Product Design intern was to translate this engine into a user-centric interface during a 16-week sprint.
I worked along a team of 3 application developers, and the software team to design an interface that translated a heavy constraints based system to an intuitive UI for future aviation planners.
// brainstorming & wireframing
design sketches
Before moving into high-fidelity designs, I did a deep dive into domain & used sketching to map out the core logic of the optimization interface. These early explorations focused on how to translate complex algorithmic outputs into a human-readable format.
// early discovery
Open Questions i Explored
Early discovery surfaced questions that shaped the design direction. These came from cross-functional discussions with domain experts & application developers.
to allow editing after the optimizer has run?
Should we allow users to edit inputs within the execution view after the optimizer has run?
Allow manual service assignment to crew?
My idea was to let planners "lock" a specific service to a crew member and re-run the optimizer around it. This would be critical for edge cases — a service that keeps going unassigned due to impossible constraint combinations.
What level of Granularity?
Intraday (08:00 / 10:00 / 12:00...) vs date-level (1 Jan / 2 Jan / 3 Jan...). Similarly, should the Gantt show crew group vs service, or individual crew member vs service?
to show high-level metrics?
Should we surface cost efficiency %, overworked crew count (with warning indicators), underutilized crew count for the airline?
fine-tune optimization via sliders?
We explored allowing users to adjust priorities — cost-efficiency, crew utilisation (overtime etc.), and other soft constraints — using sliders, letting them steer the optimizer toward different tradeoffs before re-running.
Show a crew × service legality matrix?
A grid with Crew ID vs Service ID showing legal/illegal status for each pairing - helping planners understand why certain assignments can't happen before running the optimizer.
what details to show for a crew?
Ideated: Crew ID, Service ID, duty period, legality status, violation level, home base, etc.
What We Cut & Why
These features generated significant design exploration but were ultimately scoped out of the V1 release. The decisions were influenced by product strategy & current development constraints rather than user needs, each feature remains on the roadmap for future releases.
// problem framing
design goal
Provide planners a clear picture of what the optimizer produced, surface violations immediately, and provide information to fix & re-run while simultaneously avoiding data that adds noise without actionability in V1 release.
// planning view
final solution
The execution page brings together the optimizer output, violations summary, suggestions to fix, and the Gantt chart with appropriate filters in a single cohesive view. Crew member details can be viewed upon clicking.
key impact
Our solution was aimed to reduce the cognitive load and time required for crew scheduling by automating decision-making using quantum inspired algorithms.
In a typical scheduling scenario involving 40–50 crew members, this could significantly reduce manual assignment time and improve turnaround time during high-pressure operations.
As this was a V1 release, post-launch metrics were not available.
key learnings
This project taught me the importance of messy and imperfect wireframes. Features that I deemed essential in one session were cut in the next due to infeasibility or product strategy. Questions emerged that would have never surfaced in the abstract. Those early conversations and rough sketches saved significant rework later.
This project taught me the importance of messy and imperfect wireframes. Features that I deemed essential in one session were cut in the next due to infeasibility or product strategy. Questions emerged that would have never surfaced in the abstract. Those early conversations and rough sketches saved significant rework later.