When we’re deciding what belongs in Aerlattice, we come back to the person reviewing a flight request. They need to understand the proposed route, see the problems it creates, and decide whether a change would make it workable.
That sequence gives us a practical way to judge the product. A feature should help someone complete one of those steps or understand the result more clearly.
Keep the reasoning close to the plan
Aerlattice places the route, its timing and the findings from a check in the same workspace. If two flights conflict, the useful information is where they overlap and when. The next step is to examine a different route, departure time or channel assignment.
We want someone to be able to follow that reasoning without reconstructing it from several separate screens. Review notes and saved decisions help preserve the explanation after the discussion has moved on.
A change also needs a fresh check. A route that worked before an edit may have a different effect afterwards, so the review has to stay attached to the version being considered.
Make offline work part of the design
The core planning workflow runs locally. Plans, checks, decisions and recordings stay in the desktop workspace, which can be backed up as a whole.
This shapes the product from the beginning: the user should know what information is available and be able to continue working without an internet connection. Optional connected features, such as the external aircraft layer, have their own limits.
Leave room to learn
The current application is a demonstrator. Its exercises let us examine the workflow, but they don’t establish how well it will work for an operational team.
The next questions are about use: can people understand a finding, compare the options and recover from a mistake? Answering those questions through representative studies is part of the work still ahead.
