Problem Statement:

Users need a way to navigate the product, customize their menus based on their subscription level, and access the other faces of the product if they have permission to do so.

Solution:

This solution comes in three parts.

1. A parking lot for all of the potential menu items any given customer could have based on their subscription model called “The App Manager”.

2. A context switching menu that allows permitted users to switch between the front-of-house operational context to the back-of-house administrative and configurative contexts..

3. A menu structure consistent with the rest of SITAs product lines.

Role, Responsibility, Time, and Constraints:

My role during this was that of an entire team. From research, to ideation, to delivery I covered the whole spectrum. I had about 2 sprints to make it happen and was in contact with the solutions architect the most during the process. Given his status in the company as well as his wealth of knowledge within the domain of engineering he was able to stand in for development as a stakeholder. Other than his occasional input throughout the process, all of the other responsibilities you see below were mine to complete. As for other miscellaneous constraints, I was told our smallest form factor for this product was going to be tablet sized. I designed tablet views first as mobile first is the industry standard. What you’ll be seeing here is for the tablet. Desktop will be expanded based on the viewport.

• Generative User Research

SITA’s UX maturity is not where it could be. We rely pretty heavily on our product owners to act as the actual liaison between UX and the User. So my research phase consisted of second hand internet research where I infiltrated Reddit groups, watched vlogs, and scoured LinkedIn/Job Descriptions in order to gain an understanding of the types of folks who would use our products. I'm grateful for the kindness of strangers on the internet who had some conversations with me and helped me understand their roles. It's not a perfect method, but it's what I could manage at the time without dedicated resources.

• Personas

Since this was the first part of the product we looked at that affected every single kind of user that is going to use this, it felt important to get the personas locked in. I took all of the findings from my guerrilla user research sessions and consolidated it into something presentable to the Product and Sales teams. With that, I ran a couple more of the Persona Initiatives with the team (as well as just making some on my own for the sake of time) and ended up with the final personas the team references to this day.

As you can gather from the cards, despite the users inhabiting very different parts of the airport, most if not all were used to products like Microsoft Office. With that knowledge, I felt it was important to remain consistent with 365 to a degree so it feels subconsciously comfortable for these users. This was the main takeaway for this solution from this user research.

• Site Map

Once the user research was in place, it was time to use that info to build out the site map. This site map is not the final site map by any means. It’s the structure the team is shooting for and will fill out over time. One of the main challenges this product is facing is the feeling that the team is paving the road as they’re driving it. This site map is very representative of that. It was the best way to explain to the team the decision to have different contexts for different user types. There is no need for an operational baggage handler to see the back-of-house sides of the product and this map was the best way to explain it at the time.

• Sketching

After my flows are drawn out, cleaned up, and validated by a stakeholder or two, it’s time for the spaghetti stage. Gonna throw it at the wall and see what sticks. For a lot of these I like to take the approach of “Whose line is it anyway?” and say it’s all made up and the points don’t matter. It’s a time to get the bad ideas out and zero in on the good ones. Below you can see the smattering of ideas I threw together on a Miro board.

It's funny, looking at it from this view you can totally see where I was reminded about tablets. That was an important reminder because I ended up finalizing my sketches in the tablet view only. I even moved on to fully mock up my final designs for the tablet viewport only too. Below are those final sketches that got approved by the team and signaled my direction moving into the hi-fidelity mock up phase.

• Final Mock Ups

Time to move some pixels around and make them pretty. Below are the final screenshots. I’ll post a link to the XD prototype as well but it was for presentational purposes only. The needs of the dev team and the constraints laid before me didn’t warrant in-depth clickable prototyping at this time. As you can see, the navigation is alive and well, it includes the “App Manager” as well as the “Switch Menus” button signifying the opportunity to switch user contexts without using that specific language. Literally no one would know what that means.

There are some other solutions that were agreed upon outside of the scope of this case study you can see here as well. Solutions such as a page with sub-pages look like, what kind of "nudge" we want to use when SITA offers a product the customer doesn't subscribe to, and a very basic idea what the KPI dashboard could look like.

In conclusion, I think this was a very decent first effort. Is it UX at the pinnacle I know it could be? No. SITA is still growing into its practice of UX and I’m grateful to be a part of that. It’s not perfect but neither am I and I appreciate the opportunity to grow with the company in that way. It’s a start though. I know for a fact this is the most intense UX interaction a product has had at this company in a long time. So, for a first iteration we can use to finally get into real user testing? Solid.

Lessons Learned:

1. There is a reason UX Writing is a Profession.

One of the hardest things I had to do during this was come up with a naming convention for the context switching portion of this solution. It’s still not perfect. It needs work. “Switch Menus” was a hail mary at the buzzer before I demoed it. When testing is done and it goes into production I’m hoping we can come up with a better name for that.

2. Mobile First is an important practice.

You learn these practices in your courses but sometimes they just don’t click until they’re put into practice. Up until this product I was mostly designing for desktop only and got into the bad habit of instantly opening up an XD file and dropping a desktop frame on the artboard and calling it a day. This was a good reminder that it’s important to design for your smallest form factor first. If it looks good on a tablet, it’s only going to get easier to make it look good on a desktop. Limited real estate forces you to get creative.

Recommendations Moving Forward

1. Revisit "Switch Menus"

This is low hanging fruit. Get some testing done, get some UX writing involved and let’s make sure that doesn’t get into production. While I haven't come up with a better naming convention than that, I know there is one out there that falls into line better with "App Manager".

2. Follow through with testing.

This product has the golden opportunity to be a pioneer in UX within SITA. It’s brand new and that is the absolute best time to apply all of the shiny and clever UX concepts. Now’s the time to take mock-ups like this and iterate on them with actual user feedback.