Consider a planner who needs to move a departure time. The edit itself is small, but it may change how the flight fits around another aircraft or an airspace restriction. The software needs to help them follow that change through to a new review.
This is the kind of interaction we focus on in Aerlattice. Drawing a route is one part of the job. Understanding what happens after an edit is just as important.
Keep the current request easy to follow
A reviewer needs to know which aircraft, route and time window they’re looking at. When a check finds a problem, its location and timing should be clear enough to connect back to the request.
Alternatives need the same context. Moving a flight later may resolve one conflict while creating another. Showing what changed helps the reviewer make a considered choice without having to remember every detail of the previous version.
In Aerlattice, accepted revisions stay fixed until an explicit replacement decision. That gives the review a stable reference while someone explores another option.
Make changing your mind manageable
People need to revise plans. A useful workflow allows a proposed replacement to remain a draft while it is checked and discussed. It should be clear which version is accepted and which is still being considered.
The same applies when returning to an earlier decision. Plans, assessments and review notes stay together in the local workspace so the reasoning can be revisited.
Find out where people struggle
We can describe these design choices and show them in the demonstrator. Whether they make the work easier needs to be tested with representative users.
We want to understand where someone loses context, which warnings are difficult to interpret, and what it takes to recover after a change. Those observations will tell us more about usability than the number of features on a screen.
