An old system to maintain navigational data for aviation.
The system needed to be rebuilt as the technology was obsolete and support was becoming a real issue. Along with recreating the system in a modern stack, it was decided to fix usability issues.
I was the only UX designer working alongside a Business Analyst, a Product Owner and a Solution Architect. I was also conducting research by watching users work, conducting individual interview and focus workshops.
Governance
Before jumping into design, I created governance policies. A meeting cadence, project goals and dissemination of design decisions.
Initial architecture
The old system was architected based on the business process. The subsequent steps created the primary navigation, but, in different order.
The process was: Maintain data (create, update, delete) -> Verify -> Use (read).
The Map was always visible, even if users were working on data that did not require geographical positioning, and a left hand tree of objects (entities) displayed elements belonging to both the Read module (Entities) and Maintenance (Projects).
In the end, it was cumbersome to use, there was not enough real estate for the data heavy content and a large portion of the screen was not used much of the time.
In the end, when new properties were added as the product evolved, while others became obsolete, hence disabled, more and more tabs appeared that users had to switch looking for the fields they needed.
I redesigned the structure to reflect the domain rather than the business process by grouping Maintenance and Verification activities under Projects and Read became Entities, which was a library of all published navigational objects that would later make it onto charts and navigation software.
The Map view was moved under a separate tab, available on demand and introduced a new section – the Notes – as research showed this is a major pain point today as maintaining notes is not only a frequent task, it also requires a lot of space, which was not available. Users escaped to running two instance of the tool side by side in order to compare changes in text or copied notes to an external tool, so they could be easily compared.
The initial version of the redesigned view looked like this.
If the user was authorised to make changes to an Entity, I made the Update button available at all times, to remove friction, however, this did not simply change the view from Read to Edit. It triggered an entire Maintenance workflow by creating or selecting a Maintenance Project, creating a new version of the Entity and switching to Projects on the primary navigation.
The challenge was „where do we draw the line?” as the Entities were deeply interconnected and related to each other, modifying one, could easily start bleeding into another one.
For example, the Lightning was a separate Entity from an Airport. We had to work out general rules each time and we did workshops and collaborative design for such details.
The map was now only available when position related data was being amended. Seeing where the coordinates actually point at was a critical visual cue for the Specialists as it was very easy for a typo, but if the entity depiction appeared in a whole different part of the world, they could quickly spot it.
One of the first major pain points that became apparent from the very beginning was maintaining notes related with an Entity.
Notes was a free text related with a navigational object. It was unstructured, which over time became a major drawback, so different types of notes were introduced, this added complexity because not all types belonged to all entities, and this was something that users had to remember.
Inspired by software development environments and tracking changes during merges, I introduced a similar view, where the user could select a previous version of the same note, see exactly where the current version differed and act on it.
This was particularly useful when verifying changes. Before, all the Verifier could see was that the note had changed.
This is how far I made it on this project. I also created a road map with proposals for future changes and a deployment strategy of the „Strangler fig”, which was particularly tricky as the legacy tool had many interdependencies and no clear boundaries, however, I was not a part of that undertaking anymore.