How do you handle information architecture in an Agile project?

Just-in-time iteration for the navigation of a mine information management system

How do you handle information architecture in an Agile project?

BACKGROUND

When the Mines Digital Services team began a multi-year project to create a new mine information management system for the Ministry of Energy, Mines and Petroleum Resources, there was a lot of uncertainty. Multiple aging information systems were in use across various silos in the Ministry, and a new system was needed to bring all of the information about a single mine into one place. 

A development team was contracted to work alongside government staff (including myself). The team was charged with building a prototype in a couple of months, and if that was successful, a second team would be engaged to scale up and quickly build out a range of features. As the UX Design lead, I was responsible for overall design direction, collaborating on product strategy, and supporting the second development team once it was procured.

PROCESS

Traditional information architecture methods can be difficult to deploy on an Agile project because information architecture is usually based in the organization of a fixed set of known options. However, with the MDS project (as with many Agile projects), priorities frequently shifted and pivoted. Early on, we attempted to make some guesses at where the system was going and made a Do-Go Map, but we quickly realized that we couldn’t guess at what was coming next farther out than a month or two.

The first development team settled on a tab pattern for the prototype to serve as the navigation for a single mine’s record. Since the project was based on the concept of “mines at the center,” the foundation of the system was built around foregrounding the key information about a mine and linking it with associated pertinent data (e.g. its permits, inspections, the tenures it sits on, etc.) The team chose the tab pattern for the initial prototype, with the key or “tombstone” data displayed persistently at the top of the screen.

Screenshot of Core mine management software, showing old tab-based navigation design.

Old tab navigation, showing Tailings tab. Top card area with map shows “tombstone” data and persists across all tabs.

 

As additional features brought in new types of information, tabs were added to the mine’s record. However, at a certain point, we realized we were going to run out of room for new tabs, and through additional user research, we learned that it would be possible to group items we’d placed on different tabs. Once a clearer roadmap for future features was established, I assisted the UX researcher with developing a cardsort activity with Ministry staff to figure out the best groupings and labels for the navigation. Once I had a reasonable idea of how many groupings there would be, I experimented with a few different ways of re-imagining the navigation and display on the mine record. 

I ultimately arrived at two possible designs. Both designs did away with the persistent tombstone data, as user feedback indicated that this wasn’t necessary and they wanted more screen space for the main substance of the tab data. 

The first option presented the menu items via a vertical sidebar, which allowed for easy scanning of the items:

Screenshot of option 2 for new navigation design, showing a vertical sidebar on the left side of the page

First option for new navigation – a vertical sidebar

 

The second option was a horizontal, secondary navigation bar that could distinguish itself from a site-wide navigation through placement and styling. The triangular shape at the top of the secondary navigation bar is meant to indicate a relationship between the mine name and the options presented in the menu.

Screenshot of option 2 for new navigation design, showing a horizontal submenu under the mine name.

Second option for new navigation – horizontal submenu

ANALYSIS & OUTCOMES

Although neither of the designs offered great possibilities for scaling down to mobile, this wasn’t a deal-breaker, as the vast majority of users worked in the software via a desktop or laptop computer. In the end, the second option was selected because a sidebar would take up valuable horizontal space, and we were already struggling with accommodating multicolumn tables in many areas. 

While this design will work for Core for the next little while, if the system continues to grow with functionalities from different areas, or if usability on mobile becomes more important, the information architecture will need to be iterated once again.