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. 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.
My role
As the government’s Senior UX Designer on the project, I was the UX design lead. I was responsible for overall design direction, collaborating on product strategy, and serving as the dedicated UX/UI designer on the second development team. I frequently collaborated with the project’s UX researcher and product owner on identifying business needs, defining research questions and study instruments, interpreting research results, and determining implementation priorities.
Problem
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 (like many Agile projects) priorities often shifted and pivoted. As a result, at times the product was a bundle of thin MVP versions of many different and sometimes unrelated features.
After the product team grew, new features were being added quickly, and stuck on to an information architecture and navigation system that was originally devised for a small prototype. We realized that we needed to think holistically about the information and navigation design, and create something that had more structure but that could also allow the product to grow.
Process
At this point in the project, we were continually identifying new business needs and features we’d need to support them. We knew that we needed two different levels of navigation: a system-wide navigation to search and browse across all mines in the province, and an in-record system to organize all of the information related to a single mine. Since the project was based on the concept of “mines at the center,” the system was built around foregrounding the key information about a mine and linking it with associated data (e.g. its permits, inspections, the tenures it sits on, etc.) For navigating the single-mine record, the team chose a tab pattern from a React component library, with the key or “tombstone” data displayed persistently at the top of the screen.
The in-record tab navigation appears a third of the way down the page, with the Tailings tab selected. The top card area with the map shows “tombstone” data and is always present, no matter which tab you’re on.
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 card sort activity with Ministry staff to find out how they would group and label information for the navigation. After the UX researcher had carried out the card sorts, we discussed the results and he started working on tree testing a potential structure with users. Once I had a reasonable idea of how many groupings there might be, I experimented with a few different ways of re-imagining the navigation and display for the mine record.
While I tried out a number of variations, I ultimately arrived at two options to mock up in Figma. 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 “meat” of the page.
The first option presented the menu items via a vertical sidebar, which allowed for easy scanning of the items:
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.
Second option for new navigation – horizontal submenu
Analysis
While neither of the designs offered great possibilities for scaling down to mobile, this wasn’t a deal-breaker, as the majority of users worked in the software via a desktop or laptop computer. Although the vertical sidebar was a pattern that was used in other applications in the sector, the design team (the team’s product leadership and UXers) ultimately chose the second option. This made sense for the application, as a sidebar would take up valuable horizontal space, and we were already struggling with room for large multi-column tables in many areas.
Outcomes
I provided the team with a series of detailed Figma mock-ups for the new navigation. The implementation of my design took place after I had left the project, so I wasn’t able to contribute to how it was carried out.
Implemented version of my navigation design. Note that the triangular shape above the menu was omitted and there is extra (unintentional) white space between the mine name and the navigation bar.
A few minor changes were made to simplify the implementation, and some visual polish was sacrificed in the trade-off. I was glad to see that the design has continued to work for the product as it has grown over the two years since I made it. Although there haven’t been any formal usability tests done post-implementation, the Product Owner reported positive anecdotal feedback on it. However, in general I would like to see government Agile teams take the time to do post-release usability testing instead of hurrying on to the next feature.
While this design should continue to work for the foreseeable future, if use on mobile devices becomes more important, the design will need to be reconsidered. It will also be important to review the information architecture periodically to see if it still makes sense with the product’s growing range of features and functions.
