Context

Transitioning from legacy tools, where data entry was manual to new, automated software poses many challenges and data conflicts is one of the biggest.

Way2DiNav – which stood for „Way to digital navigation” helps Data Analysts supported smooth transition to a new way of working.

The problem

Data that was previous entered manually, was now flowing in from automated sources and Data Analysts needed to ensure that highest quality is retained, especially in safety critical data such as obstacles in aeronautical navigation.

Way2DiNav allowed to identify gaps, duplicates and other types of conflicts in data and report them, so that they are fixed at the source.

It quickly became apparent that there are conflicting needs between management and end users around the speed and quality of deliverables.

Working at today’s pace was not sustainable, especially with fast growing quantities of data, but lack of trust in current tools kept users double and triple checking everything to make sure no mistakes make it to production, jeopardising safety of flight, which each Data Analyst took very seriously.

Role

I was the only UX Designer working closely with an Aviation Data Subject Matter Expert, Product Manager and highly skilled end users.

What I did

Architected and designed the concept for a map based application where just the right amount of details needed to be shown at the specific zoom level.

Since I had never worked on GIS type software before, I needed to discover and understand how zooming, toolbars and navigating a map worked from the back end. How do I build the smooth experience I’m used to as a digital map user?

The part of the system I worked on focused on Obstacle Data. Quickly it became apparent, that we shouldn’t be focusing on obstacles – which was the initial idea – but on conflicts. The „Conflict” then because our focal point and allowed the system to be scalable to all types of data issues, going beyond obstacle data.

Navigating according to regulations

ICAO (International Civil Aviation Organisation) identifies different Obstacle Areas depending on the distance to an aerodrome and different rules apply to objects found in those areas. We agreed to design the navigation, or zoom levels, based on those rules.

On large areas, data conflicts were clustered together, but as you zoomed in (navigated) closer, more and more details were shown.

What was challenging, was the fact, that these areas, were inside other areas, so it was necessary to show different rules for displaying conflicts on the same page. On the image above, you see ICAO Area 1 and inside of it is ICAO Area 2d. In Area 1, individual conflicts are displayed in a visible grid, but in Area 2d (purple circle) there is no grid (it would have been in a different scale, not visible at this zoom level), and the conflicts are clustered, just showing the sum near the airport.

Zooming in more and more would show conflicts in data on much smaller areas, hence we had to think of a clever way how to display the relevant grids.

The shaded area would have a grid so small from this perspective, that it would make the image completely black.

Only when it made sense, and things were legible, the grid would reappear.

As you can see, on the Airport, the granularity at which Obstacles had to be captures was very precise, hence the conflicts in data had to reflect this precision.

Insights & Impact

Users still needed more assurance that the conflicts that the system identified were all of the conflicts, and that nothing was left out, and this finding was addressed as a separate project in the form of a report.

Assuming that the conflicts were indeed identified correctly, Data Analysts found the navigation intuitive and easy to use and appreciated that it correlated to their current processes and splitting work duties – which were broken down by airport and ICAO area.

They had no trouble using the grid and didn’t even notice that it wasn’t visible in certain views because it felt natural. „It’s not needed here” is what they would say.

What I’d Do Next

• Add a landing page where the user could select different types of data
• Embed a reporting system that would extract raw data from old and new source so that the user can look for conflicts themselves, in order to build more trust in the tool
• Add a workflow or task management module where users could select data sets to work on, so that 2 Analysts would not be working on the same data.
• Integrate with source tools, so that mistakes could be fixed directly from here.

---

This Case Study is just one of the many projects I’ve worked on over my 20+ years in software.

Reach out to me, if you’d like to learn how I can contribute to yours.