A case study on information architecture and navigation design
A leader in the Governance, Risk Management, and Compliance space - known for their consulting business - this company wanted to take their existing software to the next level. To do so they launched the “Alloy” project, so-called because we took two data-heavy software applications and combined them into one unified platform.
Role: UX designer, UI designer
Challenges: How do we find commonalities between the two applications in order to decrease redundancies in features and functionalities? How do we structure a clear and straight-forward navigation? How do we do large back-to-back redesigns without being jarring to the users?
The two applications have very similar user bases. While we conducted extensive research for the first application, we did not have nearly as much research for the second. We conducted user and stake holder interviews in order to get a better understanding of use cases, pain points, and future goals of the second application.
Stake holder take-aways
Cordium wanted to be perceived as a tech-forward company, not just a consulting company that happened to have software
Scalability needed to be a primary focus to account for large future features
Overall, users felt the system was useful but clunky to use
A lack of search functionality made wading through large amounts of data very cumbersome
The filtering system was unorganized and not ideal causing users to reorganize their exports to have their needs met
The data is incredibly dense but not laid out in a user-friendly manner
Users wished the system automated basic functionality
Users needed to trust the system because any errors would mean the blame fell directly on the employee
After Synthesizing the data, we updated our the initial personas to be more reflective of Alloy.
Nigel was the main persona we focused on for our initial designs. Because Nigel represented a COO working at a smaller company and performing many roles, his needs encompassed most user stories.
Once we new which user to focus on, we needed to get clarity on how Nigel felt when interacting with out system. We used the research we gathered from user interviews and insights from our customer service team's experience in order to map out the pain and pleasure points. We discovered that the set up flow was a large issue for Nigel. The majority of his journey was tolerable, allowing for large areas of improvement.
Before we could start designing individual features, we needed to focus on the information architecture. We took a look at the existing site maps for the two applications and iterated different ways of merging the systems. We needed to make sure that the navigation was laid out in a clear and concise manner, while keeping future scalability in mind.
While the site maps for both systems were large, the second application’s was confusing as well. Many of the pages linked to each other in a circular manner that left the user feeling disoriented.
We explored many options for both the employee and admin navigation. We needed to keep the navigation intuitive and simple, while still allowing for the complexity of the system.
We realized there were two main sections Alloy would have: "My Program" and "Activity and Reporting". Essentially, the sections were broken down into "do the work" and "view the work".
"My Program" contains task and plans. Basically, anything that a user is required to "do" in the system is located here. Since Pilot is a task-based system, we would be keeping the core Pilot features here. All Compliance ELF tasks were modified to fit into the existing task model.
"Activity and Reporting"contains all of the user generated data that the system logs, listed in various table grids. This section is a "read-only" section, where an admin can do activities such as running reports, viewing employee data, or looking for flagged items of interest.
billing page iteration
Once we new where the information would live, we had to design the navigation structure. We explored both a side navigation and a top navigation.
The goals we kept in mind were
Create an extensible nav that could support future solutions
Promote task focus via simplified hierarchy
Support multiple user roles with varying tasks and needs
Reuse common functionality across user roles
Leverage functionality from the first application
Web-first but mobile aware
Provides plenty of horizontal real-estate for the core functionality
FAB allows common action items to always be accessible
Navigation is similar in feeling to existing navigation- allowing users a sense of familiarity
Navigation hierarchy was focused
Scalability was limited to to space limitations
Has clear primary and secondary navigation
Menu could slide in to allow for more workspace
Menu is scalable for future features
Main nav is hidden and users need to rely on icons to navigate
Extra clicks are required to access navigation
Users cannot see where they are in the system at a glance if menu is closed
1/4 of the potential workspace is taken up by the menu
Ultimately we decided on a top navigation design. The deciding factor was familiarity for the user: because we had released a full redesign a month prior, that included a brand new navigation structure with a top nav, we did not want to frustrate the users by making them re-learn a brand new system for the second time in such a short window.