Product Site Map/Menu Interaction Design

Overview

These were two exercises I have strung together into one article for the sake of a cohesive narrative. It started an me trying to understand SITA IDS for cloud when I first was assigned to the team by building a site map for them (something the team did not have prior) and ended with me using that site map as a justification for making some menu changes within one of the clients in order to allow for future growth of the product as well as a more intuitive information architecture for our users.

Picture of street map

Problem Statement:

The problems I focused on for this exercise were:

  1. Internal Stakeholders need to have a holistic idea of their product in order to make informed decisions about product direction.

  2. Users need to be able to navigate the product intuitively.

Solution:

The solution for these two problems were as I alluded to above:

  1. Create a site map so internal stakeholders are able to conceptualize the product in its entirety in a single page.

  2. A more intentional menu structure with intuitive and consistent labeling.


Roles and Responsibilities:

As the closest person to an Information Architect the team had, I acted as one for this project. I also acted as a UI and Interaction designer as well. I took this idea from the backbone and skeleton stages to the finish line of adding the face and makeup.

Process

  1. Discovery/Research

  2. Empathize/Ideate

  3. Design/Deliver

Double Diamond Design diagram

Discovery/Research

  • Product Audit/Click Through

The first step in all of this was clicking around the current product and turning up every stone I could. I wanted to make sure I knew where every link, menu, and page took you. While I was doing this, I was taking notes of any time I ran into something that didn’t make sense. It was a very organic way of learning a product. The domain SITA operates in is fairly complex. While this product was put online to be the simplified and lighter weight version of a legacy display management and data engine product in the portfolio, it still has its fair share of complexity. It’s just the nature of the beast. Taking the time to go through it with a fine tooth comb was the only way to get hands-on experience with it.

Mouse cursor clicking
Microphone
  • Stakeholder Interviews

Once the click-through was finished, I sat down with a few stakeholders to follow up with questions I had gathered along the way. I also asked about the history of the product and how it came to be. There are often hidden technical details that inform design choices, I wanted to try and understand some of the genesis of those past choices so I can avoid making ill-informed suggestions and come up with solutions that include the technology already in place.

  • Best Practices Research

Finally, armed with hands-on experience and stakeholder information, I set out to brush up on some of the best practices in regards to menu design and information architecture. (I found this article from Nielsen/Norman particularly helpful.)

Now, each company is different and while I would love to be the savior of usability and have the power, negotiation skills, and user data to enact all of the items mentioned in that article, I am only so effective. With that in mind, this article acted more as a North Star. Something to aim for and attempt to navigate the ship knowing it was likely we’d go off course a bit. I very much had to repeat the mantra “Some is better than none” while working on this and many other SITA products.

Nielsen Norman Group Logo

Empathize/Ideate

  • Creating Site Map 1.0

Here in Figure 1 you can see the first go at making a map of the product. As you can see in the accompanying image, it’s pretty messy. There were some things I didn’t understand about the architecture of the site that caused some up-front issues in my initial drawing that I later fixed when finding out the different clients making up the product are independent from each other. (See figure 2). After having this first draft done, it was easy to see some of the initial issues the product had organizationally. The first I chose to focus on was cleaning up the menu in the Administration Client (The middle branch in figure 2.)

Site Map 1.0

There were some things I didn’t understand about the architecture of the site that caused some up-front issues in my initial drawing that I later fixed when finding out the different clients making up the product are independent from each other. (See figure 2).

Site Map 2.0

After having this first draft done, it was easy to see some where there were some opportunities to clean up the navigation and information architecture for the site. The first I chose to focus on was cleaning up/consolidating the menu in the Administration Client (The middle branch in figure 2).

  • Card Sorting

The activity I engaged in when looking to understand a solution to cleaning up the Admin menu was card sorting. It was a pretty straight forward endeavor. I started by taking the six menu items that already existed and asking various stakeholders to sort them in ways that made sense to them. Once I had a consensus about which groupings went where, I sat down and came up with appropriate titles for the groupings. Here’s what those look like.

Diagram of sorted and nested menu items
Tree test stock image
  • Tree Testing

Once the results from the card sorting were in place and the small site map or menu tree to visually represent the new structure was made it was time to internally test the group consensus with others. I tested it with folks around the office and other stakeholders who didn’t participate in the card sort. I made sure they were able to find the nested menu items in their new groupings without issue using a method similar to treejack. Good news: most passed with no issue meaning the new structure was validated enough to be used in the product. It was an imperfect method.. But it was the one I could do with the tools at my disposal. Like I usually say, “Some is better than none”.

Design/Deliver

  • Final Site Map

Now that I understood the problems in a more in-depth way, and had gone through some testing of solutions, it was time to make the changes to the site map I had created in the beginning of all of this. Here you can see the new version of the full site map. It’s a lot cleaner looking with paths to the various kinds of content that make a lot more sense. The menus are nested in a way that makes more sense and leaves room for growth of the product over time. (We also cleaned up the App Switcher paths as well but that's out of scope for this case study).

Final Site Map
  • Mock Ups

With the changes made to the site map, it was time to implement those changes to the UI. The backbone has been updated, now the face of the product needs to be updated to match its new posture. Below is the before screenshot. As you can see the menu is not nested in any way (just like the site map shows).

Original Menu Screenshot

Now, here are the updated map UIs. All of the nested elements have their own UIs as well. In this expanded view you can see all of the different elements for the various states they can be in. Highlighted, expanded, selected- everything's here.

New Menu UI Assets
  • Interaction Design

Something that needed to be thought of when it came to this new menu design were the interactive elements. We needed to decide how we handled hover states vs hard clicks when letting the user know there were nested menu items. After some internal testing and conversation we landed on hover states when using the product on a desktop. There are minor differences when the site is operating on an iPad but those use cases according to our users are few and far between. Here is a short GIF of the new interactions on the site.

Animated GIF of new menu w/interactions

Conclusion and Lessons Learned

In conclusion, this exercise was a really good start in getting the product's information architecture in shape. The product was stood up with little UX involvement and now the name of the game is slow but steady iterative improvements. I believe this solution satisfied a good amount of the wish list I set out to comply with from the Nielsen/Norman Group as well as meeting constraints of the product and development teams. It’s a successful compromise.

Lessons Learned:


  1. I found out this product, while web based, is not structured like websites I was used to.


I was (and still am) relatively new to computer science. I am a people person focusing on using those skills to help build more human based technology. My background is in those softer skills. In learning about this product I learned about solution architecture as a whole. This product is made up of three different clients strung together via an app switcher. Not unlike Office 365. I had been under the impression that it was one singular site. Learning that about the product opened the door to different solutions as well as new ways for me to think about building solutions in general. I am not perfect, nor am I an expert in the different ways to create technology.. But I’m growing.


  1. Half of UX work is communicating with stakeholders.


This is something I cognitively knew, but this was my first experiential learning moment with it. It’s a little multi-layered as well. Not only do you need to communicate with stakeholders in order to coordinate times for meetings and aligning goals, you need to be able to communicate “why” as well. That was the large lesson in making sure there was a site map I could pass around to the various stakeholders in the office. It was a deliverable that I could use to visually explain information architecture and menu/visual hierarchies to them. It’s about finding ways to get everyone on the same page and to gain buy-in for moving forward with UI changes.

Recommendations Moving Forward

My main recommendation moving forward is to rinse and repeat this process. Iterate on this and make more and more incremental changes that right the ship. This product (and the organization as a whole) is a large cruise ship. Making large turns towards having more user-centered products happens one degree at a time. As well as with other products and initiatives, I also recommend UX practitioners at SITA continue to push for more reliable means of user testing. Without them, all of these decisions are mildly arbitrary. We are making our best guesses and assumptions of what the users are looking for, but lack the all-too-important validation of those assumptions. I can write about righting the ship towards a user-centered future all I want… but without reliable user-testing methods and cadences we can only turn the ship so much.

Zone Management Mock Up Image

SITA IDS Visual Messaging: Zone Management


Like what you saw?

Check out these other case studies!

Persona Stock Image

Airside Optimizer: Persona Initiative