Trackmeet

Placing out of access Airmen with unclassified opportunities…

and more!

Results

  • 5 Personas

    Of our 15 user interviews, we synthesized 5 main personas.

  • 100+ Mockups

    Every interaction, documented.

  • Airman Placed

    After launch, Airmen were able to find jobs without bureaucratic hassle.

Background

From August of 2020 to May of 2022 I was a Product Designer on Team Cylon, which is an Air Force start-up exploratory effort. We chose to create Trackmeet to reduce the amount of communication barriers that existed between Airmen who were waiting for their clearance and unclassified opportunities. Before Trackmeet, Airmen would have to jump through many hoops to get an opportunity that would develop themselves professionally. We aimed to create a job board where Airmen could view and apply to opportunities easily.

Finding Our Problem

 

Team Cylon was in a precarious situation after being spun up. With no real direction from stakeholders, save for “innovate”, we had to find our own problem to solve. We brainstormed a lot of ideas, and from there chose the three most voted on groups of ideas, “Tasker Process”, “‘Simple’ Problems” (think day pass tracker, personnel tracker etc.), and “Standardized resource information”. Of these, Tasker process had the most votes and seemed to be the most feasible with highest return in terms of user gain.

Discovery & Framing

After finding our problem, it was time to explore the problem space. We started out with assumptions that would later be validated through user interviews.

 

After conducting user interviews we synthesized
our collected data

I know many people who feel like their leadership has forgotten that they aren’t doing anything. They fall off the radar. This doesn’t really bother me.
— an interviewed airman
primary user data synthesized.png

As you can see, we wanted to focus our development efforts on the out of access Airmen (red) more than anything, we wanted to make sure they were being taken care of and getting into jobs that they wanted without any opportunities getting lost.

How might we…

We then led a how might we session with the entire team to discuss common problems, technology feasibility, and user buy in

Our ideas ranged from simple granular fixes to Air Force culture/processes

To more complex processes that would require software to implement

Personas

After our exploration, we decided to create 5 personas in total, however we focused our app’s development on two key users, the Airmen applying for listings and the opportunity holders themselves.

We coined the Airmen as Cizaronni, given that without opportunities they most likely would be sitting in an office waiting for their clearance.

The opportunity holders we called Jim Epps, noting that the two main out of access employers were the on base gym and the Epes dental clinic.

These two personas really drove our development process and all our features were catered to their needs and pains.

 

Design Studios

 Over the course of development, we ran multiple design studios, some with just the design team and some with all of Team Cylon, to gauge how we wanted our app to look and feel. With the design team, we were focusing primarily on reducing barriers of entry/use and with the entire team we were scoping out technological capabilities for overall functionalities.

Our first design studio agenda

This was with all our disciplines, designers, developers, and managers

A software developer’s input

 
 

A product manger’s input

 

A designer’s input

 

A designer’s input


We also ran a design studio on how we wanted Trackmeet to feel overall.

These were our final choices

Our finals ultimately guided us in the direction of how we wanted to design our app.

Components (v1)

 I don’t have a lot of examples, since we were mainly using components in Figma and when we updated them, they updated globally. But suffice to say, our app looked pretty bland. I say this from my current view point, in the moment I probably would have said it’s fine. Below, I’ll go into direct feedback that we got while testing our design iterations, and in Components (v2) I go into how we solved user’s barriers.

Interviews/Validation

 Throughout the course of our development, we made sure to schedule user interviews often to validate our designs. One major change we made was from a light theme to a darker theme. We received constant feedback that the aesthetics of the app looked bland. To mitigate this, we decided to shift from a light mode to a dark mode as shown below.

We also received feedback that our hamburger menu was hard to navigate, so we changed the layout of the navbar to make the options more readily available, reducing the barriers to navigation. Since there were only four options, we were able to remove the hamburger menu.

Components (v2)

Once we had validation that our application needed a paint job, the only thing we really needed to do was change the palette around to fit our new sleek dark theme:

We also received feedback that our hamburger menu was hard to navigate, so we changed the layout of the navbar to make the options more readily available, reducing the barriers to navigation. Since there were only four options, we were able to remove the hamburger menu.

Lessons Learned

 I would say one of the biggest lessons I learned on this project was to not deviate from pre-made components. We (Design team) tried our best to justify every design decision (e.g. “Skill tags will be easy! They’re just bootstrap pills” or “the listing needs to look this way because it looks that way on other sites”). But in actuality, all this did was compound the amount of work on software engineers and make it so they spent more time styling, and our PMs spent more time rejecting stories for styles not matching up perfectly. At times, it felt like engineers were at the beck and call of the design team, when we should have been collaborating to find better, less style heavy solutions.

In my next project, if at all feasible, I think I’m going to stick to simple components without a ton of styling, blocking things out in a way that makes sense, while also using methods that have been proven already to be effective ways of displaying information.

Key Takeaways:


  • Style less.

  • Research more.

  • Ask, “Has this problem been solved? Could it have been solved leaner?”

Conclusion

 Trackmeet was a great application to work on, it was the first project that the Team worked on that provided value to the Wing. That being said, I wish that we had the manning and continuity to be able to push the application faster, but in the military manning is never promised. That just has to be worked around.