Edited Image 2015-6-15-14_9_16.jpg

ALLOY

A case study on information architecture and navigation design

Overview

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? 

 

Research

Artboard 2 Copy.png

Interviews

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 

User take-aways

  • 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

Artboard 2.png
 

Personas

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.    

 
 

USER JOURNEY

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. 

Nigel - Becomes Compliant + Ongoing Compliance.png

NAVIGATION DESIGN

Information Architecture 

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.

Exploration 

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.

INSIGHT

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

Navigation Layout

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

 

Top Navigation

Pros

  • Provides plenty of horizontal real-estate for the core functionality

  • Feels Modern

  • 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

Cons

  • Scalability was limited to to space limitations  

Side Navigation 

Pros

  • Feels modern

  • Has clear primary and secondary navigation

  • Menu could slide in to allow for more workspace

  • Menu is scalable for future features 

Cons

  • Sliding Menu

    •  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

  • Locked Menu

    • 1/4 of the potential workspace is taken up by the menu


RESULTS

Top Navigation

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.