Jesse Bandfield
UX Designer
Next case study

Rapid Roster: Walk a Mile in a Coach’s Track Shoes 

DESIGNING A MOBILE APP FOR A MARKET I KNEW NOTHING ABOUT

Objective
Mobile App
Roles
Research | UX | UI | Branding
Tools
Figma | Whimsical | Pen and paper

See the prototype

 

The world of sports. Oftentimes you’re in (high school athlete, enthusiastic parent, overzealous fan) or you’re out (me). I played on the bowling team for a few years, but only for the social aspect and because it got me out of 8th period once every two weeks during the season. Schedules, workouts, rosters, bus times: all of this was foreign to me. 

When I had the opportunity to work with a middle school track coach to design an app that creates a roster and drives the admin processes for track and swim coaches, I had to rely purely on observation and learning in order to create a product that had value.

Problem

Track and swimming coaches of middle and high schools often do not have the administrative support they need to run a team well. This can sometimes mean the difference between a school having a track team or not. 

For every meet there are over a dozen events, rules and preferences that dictate which events each student can participate in. Parents scrutinize the coach’s decisions to make sure their kid is being treated fairly. Coaches desire to see students grow and reach their potential, and yet spend their limited time organizing and communicating. 

➢  Empathize

Listening

In an ideal world I would have visited track meets, ready to be a fly on the wall to absorb all I could of the people involved and their processes. Because the pandemic had canceled all middle school sporting events, I opted to instead meet remotely with coaches and listen to their experiences: Why were they coaches? What challenges did they meet? How do they currently solve those problems? I looked over their spreadsheets to peer into their world. Here are my main findings:

  1. Coaches want to see meets from two perspectives: fitting students into a specific event and choosing events for a specific student.
  2. There are a hodge-podge of systems in use across the country, from Fully Automated Timers at meets to websites like Athletic.net that coaches have to input meet results into. Not every school uses these.
  3. Coaches have to communicate A LOT. To students, to parents, host schools, and secretaries. Even the busses get reserved a year in advance.
“If the coach is personal, they’d go student by student to make sure John, for instance, was running a specific event. If they were trying to make sure all of their events were figured out or were more focused on stacking an event, they would look at it by event.”

What most surprised me was how there wasn’t complete consensus on details like whether all meets had the same order of events. Some school districts used a certain method of timing or communication while other schools did it differently. My designs needed to be cognizant of these differences, and be able to integrate with the variety of tools already in use.


➢  Define

Thinking (too) Big

To solve his problem, my stakeholder Nick envisioned an app that created a roster, and perhaps even held contact information and health conditions of the students. Through interviews I get a sense of the big picture: there is an entire array of tasks that coaches do and multiple end users who could benefit from this app. 

I wanted to design an app that would solve every problem for everyone.

Secondary research enlightened me to the world of Sports Management Apps. The best are feature-heavy and are an all-in-one platform for coaches to organize and communicate with teams, and for parents to connect with one another. The nimble disruptors had fewer features, yet still excelled in communication and understandability.

Shouldn’t this app also incorporate all communication from coaches to parents? The list of features to be designed kept growing as I discovered just what was needed to appease coaches, parents, and students. Following this rabbit trail turned out to be costly, unneeded exploration.


➢  Ideate

While creating my persona, I remembered something important: the coach was my key end user. 

Shawn mostly cares about connecting with his students and pushing them to be their best selves. After that, Shawn cares about staying organized and getting help with the roster. While communication is important, I learned in interviews that school districts usually have modes of communication between teachers and parents, and requiring everyone to download another app could be a hard sell.

How could I design a Minimum Viable Product that sped up the admin process so coaches could coach? 


I created a Task Map to reorient myself back to the core actions the coach needed to take. I realized that bigger wasn’t better, and adding robust two-way communication for parents would be a hindrance to getting this project off the ground. Coaches needed to create a roster that fulfilled technical requirements while still meeting personal goals. That action was my square one. Every other feature should support that goal.

Discovering Flows

Empowered by realigning with my MVP, I created some flows that helped me visualize the app’s structure. By drawing out a user flow, I documented the actions a coach would take and the questions they would ask themselves along the way.

Was the coach able to complete the task of creating and exporting a roster? What did they need along the way?

Answering these questions allowed me to see and document the necessary functions around the roster creation process. It feels similar to what I imagine archeology to be like: the deeper you dig, the more you uncover. The further I explored this flow, the more pages, functions, and actions I uncovered that would be needed. These discoveries all come together to form the bones of the app.


Piecing those discoveries together in a sitemap becomes the guide to my wireframes. What pages are necessary for coaches to perform vital actions? What needs to be on those pages? What links go in menus?

My biggest unearthing here was how to structure current and past students. For the app to have records of past meets and previous years it would need a database of those students and their times, yet including all current and past students on the homepage would clutter everything. I could imagine two scenarios:

  1. A homepage dropdown menu that would choose which year or team to display, compartmentalizing the whole app to just that team.
  2. A robust filtering system that would allow coaches to quickly and easily view only students they wanted to while providing access to all historical data anywhere throughout the app.

Because coaches would want to maintain access to all data, see previous meets and past records of workouts, I decided that it would be best to include a filter system while keeping all past data immediately available. Creating a sitemap allowed me to discover that this was a question worth asking, and then design an elegant solution with coaches from my interviews as my guiding light.


➢  Design

Designing for the Coach

A key finding drove my lo-fi wireframes: Coaches want to see meets from two perspectives. With so much data (upwards of 60 students, 12 events, multiple relay teams where order matters, personal records for every student for each event) how do I show only what is relevant to the coach when it makes sense? 

What does the coach need to know right now?

I devised a toggle system that could show the same information from two different perspectives. I also included some surprise and delight elements such as making absent students visible as the coach was making roster decisions.

The designs also have a robust filter system so coaches can pinpoint individuals or groups of students.

Designing for Accessibility

Being on the field or in the pool house on game day means that coaches need access to clear data quickly. On mobile with small screens this is especially tricky. These observations informed my designs because I believe accessibility is important. I incorporated a clear visual system that differentiates individual events from relays from field events and is repeated throughout the app. This system also works well for users who experience color blindness.

In order to make edits in an intuitive way on mobile, I did a deep dive into the use of gestures. By utilizing drag and drop, tapping to expand, and holding down on a student to open an edit console, the app allows for coaches to make powerful edits in the fastest way possible. 

➢  Test

See the prototype

Validating the Design

The ultimate test came when I began to test the first of my wireframes. Through usability testing I explored the following questions:

  1. Can coaches flawlessly make edits to the roster?
  2. Are the actions they need to take and data they need available to them when they need it?
  3. Is the structure intuitive to the way they already work?
  4. Does the app work equally well for track as well as swimming?

Because I wasn’t a coach, it was only during testing that I could discover how successful my designs were. A few things I heard during testing were:

“I like seeing absent students. That’s cool...if I knew they weren’t going to be there.”
“Love the PR times on the page. That’s super handy. If Joe runs a 15 second 100, I would swap him with someone who runs it in 13 seconds.”

The magic of testing, for me, is the inspiration that comes from listening to others. I can learn how to make better design choices because participants tell me what they need through their actions and ideas. Because I fully listen, the final product is better suited for the user, better meets their expectations, and even surprises and delights them with features they didn’t even realize they needed.

Takeaways

Have a guide.
Keeping the MVP front and center doesn’t restrict possibilities, but it does keep the project focused on what is most important to the business and to the end user.

Listen.
Use research and observations from customers to directly inform design. This will increase the chances of the final product connecting with the customer.

Keep it simple.
Thinking of when the app will be used, under what conditions, and what the user will want to see at that time both simplifies and strengthens the design. It balances organization and insight.

No items found.