Problem Statement:

The problem defined by the product team for this leg of the feature was: Users need to be able to create “zones” throughout their airport in order to publish visual messages (ex. “Please do not leave your baggage unattended.”) to entire banks of singular displays in one click. Which, was simple enough… until it wasn’t. There were a lot of underlying problems to address within the feature requirements along the way. For example, one of the requirements was the capability to place zones within other zones along with singular displays. (Think of three displays above a single baggage claim carousel as one zone, then place that zone within a larger zone that encompasses baggage claim as a whole.) With that requirement in place, the potential for recursion within the system was very high. Thus, the problem I really focused on as the UX designer on the team was: “How might we keep the user informed of their actions so they don’t break the system by mistake?”.

Solution:

Simply put, the solution I chose to focus on was making sure the user had some kind of feedback every step of the way during their process of creating zones. It was very important that they were able to “follow the narrative” as I would put it in meetings. I am of the camp that humans are able to do complex things only if they’re able to wrap their mind around it narratively. “If I do (x), (y) will happen”. Making sure they had elements to visually aid them in connecting those dots while also keeping computing resources in check is where I landed on the true focus of this solution. In order to do that, I included heavy use of immediate changes when the user clicks on an element of the page (a dynamically changing visual "zone tree"), visual feedback when a zone is unavailable OR when the parent zone contains other zones as well as when they add or remove a zone, and plenty of tool-tips upon hover to help them understand what’s going on in front of them.

Users:

The users touching this potion of the product are typically internal integrators. When standing up this product at an airport, SITA sends integrators to install the system. This integrators are in charge of setting up zones and assigning displays and other zones to them. These folks make up the user pool I was able to learn from.

Roles and Responsibilities:

As the sole UX designer on this task, I held roles and responsibilities from every part of the UX spectrum. I researched the users, understood and empathized with them, designed the solution, and then added the colors and other fleshed out UI elements. What we were missing, (and miss still to this day) is a reliable way to test solutions with actual users. That is the one limb of the UX body of tasks SITA needs to work on at an organizational level.

• Requirement Workshop

At the beginning of this process, we engaged in an internal workshop where product, development, and UX all sat down and hashed out the big questions like “What is visual messaging?” and “What isn’t visual messaging?”. It was here where we decided on the requirements for the MVP for this new feature. It was all here where I got an insider look into the minds of the folks who would use it most, the integrators. The PO on the project was a former integrator and had a wealth of information and experience in using the legacy product. None of these stakeholders were thinking of the user all that much throughout our time in this workshop. That's where I came in! I spent a solid amount of time during this attempting to turn the ship in defining these requirements in a user centered way. For example, making sure to list out jobs-to-be-done and then making sure all of the solutions are phrased in a way that describes how a user is able to do that job. I wanted to make sure we were outcome focused.

• Stakeholder Interviews

During the workshop I made sure to carve out some time to take a deep dive into understanding the product at large with the folks that run, maintain, and build the product. These conversations were with Product, both PO and PM, development heads, integration, and sales. It was nice to get a wide breadth of perspectives on what we were looking to accomplish. Having a robust understanding like that means I can shave off some time-to-delivery by using that information as parameters for design choices.

In conclusion, this was a bear of a project. We were under the gun from product to have the feature defined, designed, and developed in a very short amount of time. I’m proud of the solution we came up with and the part I had in getting to that solution. I believe given the time AND resource constraints we had at the time we came up with the best possible solution to a very complex problem. With choices such as keeping everything to as few pages as possible, dynamically updated relationship trees, and immediate visual cues to let the user know what zones are related to what, I think we did a great job of helping them keep track of their own narrative when interacting with the product.

Lessons Learned:

1. You can’t think of absolutely everything

There is going to be some natural agility involved in these types of sprints. I am just one person and I can’t possibly think of every little thing in a short amount of time. Leaving room to be agile and answer questions on the fly is a great skill to have. It kept me on my toes and tested my intuition when it comes to design solutions.

2. When making task flows, it’s ok to make plenty of them.

I felt if I made only a few task flows I would convince the stakeholders that what we were designing was simple and I was doing my job affectively. Realistically, it was the lack of edge-case task flows that caused a lot of the ad-hoc design choices in development.

3. I really grew in my ability to be the voice for the users.

Many of the folks I work with aren’t used to thinking about them or about how much psychology affects the way we interact with technology. I was a broken record when reminding folks that “The narrative is what’s most important here” and in the past I would be self-conscious about being that repetitive. By the end of designing this feature I was proud of the steps I had taken in my negotiating/advocating skills.

Recommendations Moving Forward:

1. SITA desperately needs a way to get in touch with their users.

I can be as proud of a solution as I want to be but it doesn’t matter if I can’t test it with actual users. It could be the completely wrong thing and that’s a risk SITA takes with every single one of their products when they don’t allow UX to incorporate proper user testing. That's why I recommend getting some kind of testing in place. Once testing is in place, SITA will be able to make more informed calls about how to iterate on the product moving forward.

2. Process was incredibly sped up and I believe stones were unturned because of it.

The scrum team who works on this product runs 3 week sprints, all of this work occurred in 2 sprints. One for me to do all of the design work, and then another to oversee it coded into production. That is awfully fast. In a perfect world changing this process to include 2 sprints to do the design work, incorporating more testing to validate the choices made.