This application provides users (SODs - Superintendent of dispatch) an interface to interact with the Aircraft Recovery Optimization engine. From this app, users are able to set up "what if" problem scenarios that the engine will solve. Users can also enter their own aircraft scheduling solution to the problem that the engine will score and compare its own solutions. Users can then view and compare the aircraft scheduling solutions, select the one they like the most, and send it to the Aircraft Scheduling software application to be applied to the actual production flight schedule for the current day of operations.
1
Side navigation bar for different problem scenarios to interact with the aircraft recovery optimization engine
2
Enter aircraft scheduling solution area (similar to a shopping ordering step)
3
List of added aircraft scheduling solutions that will be submitted to the engine (equivalent to a shopping cart section)
New requested feature is to add a Global Protection which means the scenario will stay protected for the next few shifts across the system. This ensures that as the operation is turned over from users between shifts, a protection is not inadvertently omitted from an upcoming solution.
Once users add the scenario as a Global Protection, there will be a new Global Protections section created on the engine List. Users are able to remove the Global Protections to adjust the aircraft scheduling solution.
The Scenario Protections panel allows users to input a flight or tail for a specific date that is persisted through all the problem scenarios.
Example of when information are entered to active the action buttons
New section prompt for added Global Protections
To remove a Global Protection, a modal will prompt for additional confirmation.
If user clicks on the top button, it will remove the aircraft scheduling solution temporarily. In that case, after submitting the solution, users can see the score back from the engine and decide if it's the best one to run before applying to the actual production flight schedule.
The new feature of adding Global Protections, including the modal keeps a consistent work flow with the rest of the design which users are familiar with.
Multiple options of delete an aircraft scheduling solution is naturally confusing to users. There is a high risk of an "unhappy path" for users if we allow for a temporary deletion state.
Same flow to create a Global Protection. By introducing a kebab icon to consolidate the original modal flow.
Click the kebab icon to see more options from the dropdown menu.
It simplifies the flow for temporary disabled option, meanwhile, reserves enough real estate for upcoming features which will be implemented to the Global Protection.
The kebab icon is relatively new to users that requires higher learning curve. The feedback we got from users is that they are looking for a more obvious visual cue to distinguish the current status for each aircraft scheduling solution.
1
After consulting with Architects of how they structure the data, we decided to separate the flows for Global Protections and existing Scenario Protections by introducing a tabular navigation.
2
Instead of Bake List section, we have a Global Protections section to review at the bottom of the panel.
The trash icon will remove the Global Protection for good, for all users. To add it back the user will need to create a new one from this panel. This ensures less error validations will occur during the QA phase.
3
The Scenario Protection keeps the same functionality as the original with minor tweaks.
Example of new Bake List under a non Protection Scenario panel. By introducing checkable items, it brings more clarity to focus on the temporarily disabling feature to meet users' need.
If the user un-checks a Global Protection, it will inactivate it for that one aircraft schedule solution run. The tooltip prompt helps to explain to the user about what this functionality does.
We worked together with architects, developers, product owners, business managers and QAs in this process to optimize the current feature by preparing a logical design that met business value and development feasibility.
We worked closely with engineers to close the legacy gap in the design system between design and development each sprint. We also setup a strategy to standardize the design system going forward after this project ends.
