Persona Initiative

Overview

The UX practice team has been working on getting a library of personas for a while at SITA. The goal was to have a revolving list of user personas to pull from when creating, adding to, or iterating upon products across the portfolios. As the designated UX Designer on the team it was up to me to look at the users for Airside Optimizer and contribute to the growing cache of them across the organization.

Persona Stock Image
Persona Stock Image

Problem Statement:

Beside the obvious problem of “We don’t have personas of our users”, I also decided to take a look at another not-so-obvious problem: “We don’t have full buy-in to the idea of user personas”. That lack of buy in comes from a few factors; 1. Team members are unaware of the practice. 2. Team members are left out of the conversation when personas are made. 3. Team members don’t care.

Solution:

My solutions to these factors causing the problem can all be funneled into this statement: “Hands on experience is the best teacher”. While I know UXers can be seen as pious when evangelizing our craft... I’ve found it’s not as annoying to engage with folks in learning if you make it interactive and team based. No one wants to be shown a slide deck and talked at in a learning environment. With that in mind, I took an activity like building out a persona and turned it into a collaborative team activity and invited my SCRUM team to join. By the end of it, not only did we have a fully fleshed out persona, but we also had team buy-in and interest because suddenly they had skin in the game.

Process

  1. Researching

  2. Empathizing

  3. Designing

Stock infographic of a cycle

Researching

  • Stakeholder Interviews

With the complex nature of this product, there are a lot of different kinds of users who will be looking at and touching this product. I started with interviewing the acting Product Manager for some insights into who to start with. As the domain expert he has a wealth of information about the different jobs within an airport environment.

Broad user breakdown matrix

The result of this conversation was a large, semi-organized MIRO board full of different matrixes describing the different roles around the airport who would be using this product. After this interview, the group of users I chose to focus on first were Air Traffic Controllers (specifically apron controllers- a more euro-centric position within ATC). Given how the interview uncovered the amount they use and look at the product, they seemed like a good place to start.

Detailed User breakdown matrixes
  • Reddit Survey

After getting some background from the Product Manager, it was time to drill into what kind of people Air Traffic Controllers are. Since my connection to actual users is severely limited at SITA… I had to take matters into my own hands for this portion. I ended up infiltrating the Air Traffic Control subreddit and asking them to fill out a survey. This survey was by no means expansive, but it helped me get some demographic information as well as some habitual information about them. Information like where they’re located, how old they are, what kind of tools they’re used to seeing at work, what kind of tools/products they used at home, and what kind of education/how many years of experience they have. All important information when trying to understand a group of people. These were the topics that were going to provide me with the best shot at empathizing with the users effectively.

Survey results screenshot

Snapshot of Reddit Survey Results (Google Form)

Empathizing

  • Team Activity

Once the data was in place, it was time to get the team together and aggregate it all. This part could easily have been done by myself, but that’s not the point! The point was to bring the greater team into the fold and get their input. I had developers, risk management, and product management involved in this activity so the most of my bases were covered from the different departments touching the product. Together we looked at the accrued data as well as the results from the stakeholder interview and put the pieces together. I also took a moment to explain my thinking as to why it was beneficial for them to be there.

Infographic image

Infographic of *why* I was involving the broader team.

Group Activity Miro board

MIRO from the Group Activity

Then, I used a template I found online and set up a MIRO board where we could all have post-it notes to fill in the blanks. The point of this activity was to take the data we had and fill out the more psychological aspects of the persona. For example, if they work a lot of hours should the photo in the persona be of someone who is tired? What from this data is going to inform the look and feel of this fictional person we’re using to represent this whole group? The point of this activity was to get the greater team to think about humanizing this group of users. It was to help them make the leap from data, numbers, and hearsay to: “These people are real”.

Designing

  • Final Product

With the activity done and the data in place, it was time for me to design the actual personal deliverable that would live in the groups teams site. It was the last piece of the puzzle. One final at-a-glance piece of information that encapsulated all of that effort and profiled the user group in question. Here is the image of that persona. If I had my way, this and other personas made after the fact would be hanging by everyone’s desk as a reminder of who we’re building this for. It’s so easy to get lost in the technical side of things. This, and the activity it came from are meant to be reminders that humans use our products.

Image of final persona with details

Final Persona

Final Thoughts and Lessons Learned

  • Conclusion

In conclusion, while it was a higher effort method of making a persona, I think it was worth it to get the team on the same page and better invested in the human side of software development. It was touted as a creative and unique experience from those who participated. "SITA has never seen anything like this before" was a quote I received from the lead developer on the project. It even earned me a by-name shoutout from the head UX Designer for the company on a global staff call to the 5000 employees across the globe.

It was difficult to get time in everyone’s schedule to get the activity going and there was still some hesitancy when it came to buy-in, but I believe if I were to iterate on the process I would smooth out some of the more rocky parts of the process and that bar-to-entrance for buy in would be a little lower.


  • Lessons Learned

As mentioned above, there were some rocky moments in the group activity. The lessons I learned along the way were:

  1. Taking a template from the internet was helpful in getting the activity off the ground, but there is room for improvement.

There are better fields we could have filled in than the ones provided by the template. In future sessions I will be taking a harder look at those fields and tailor them to the group I’m working with and the kind of user we’re looking to flesh out.

  1. Refining what I’m looking for out the team will go a long way.

Now that I have some experience with the activity, I have a more refined idea of what I’m actually looking for when I engage the team. I mentioned it above in the paragraph about the activity, but I really just want them to make the leap in humanizing the users they’re building products for. With that in mind, I think I could tailor the activity in and of itself into something that pushes that agenda a little harder.

Tablet with Airside Optimizer Mock Up

Airside Optimizer: Product Navigation

Like what you've been reading?

Check out these other pages!

Flight Information Display Photo

SITA Information Display Systems