Project Summary
Problem
40+ athletes
to manage with little to no assistance
4-6 hrs
per week coaches spend planning team workouts
4+ tools
coaches switch between to keep track of everything
Solution
SOLO is a mobile application designed to centralize everything teams need to win. Managing athletes, creating personalized workouts, and recording performance data–all without dropping the baton.
My Role
This was completed as my senior capstone project. My team worked with an external partner, a former athlete, to address issues that most track and field teams face.
We were given the remains of broken code and an unintuitive design. We decided to start on a clean slate to design and develop a prototype that would exceed our partner's expectations.
The Product
Most of my team was in unknown territory.
We had very little experience with track and field, including the different events, how athletes train, or what their coaches go through. The most understanding my team members had was from being on a soccer team or running leisurely.
So we did some research.
We connected with two track and field coaches: one coaches high school, and the other coaches college. After talking with them about their experiences, we realized different levels have different needs, but across the board, there were some problems both coaches shared.
I wrote questions to learn more about these coaches' experiences, and we came up with task scenarios to test their experience navigating the original design.
Usability Testing
Competitive Analysis
Once we were familiar with the project,
we had more questions than ever.
At this point, we'd met with our partner multiple times to discuss her requirements for this product. By the end of this timeline, she expected a fully working MVP.
We realized she was looking for three main features:
- Coaches creating a workout
- Coaches starting and ending a workout
- Coaches and athletes viewing data from completed workouts
Compiling the stakeholder requirements and our findings from our user interviews, my team and I brainstormed a few designs. I combined all of our ideas into finalized sketches.
Rough sketches of our redesign
Then, we moved from the drawing board to the computer. As we began finalizing our changes, we came across several challenges where we had to implement value-based design decisions.
Low-fi Wireframes
We put training in the spotlight.
The home page should include the most important information for the user. It provides a quick way for users to access what they need most, and it’s the first page presented to them when they open the app. So we had to ask ourselves, “What is the main purpose of this app?”
Training, of course! We’re helping coaches worry less about data entry so they can spend more time focusing on their athletes.
Before
- List of athletes
- Prioritizes team roster
- Quick action: adding an athlete
After
.svg)
- List of workouts
- Prioritizes training
- Quick action: creating or starting a workout
We simplified the process.
The previous design incorporated multiple screens, requiring coaches to travel back and forth as they build a workout. This relies heavily on memory recall, a weakness for most users.
We resolved this by consolidating everything onto one page. We spoke with coaches to learn how they create workouts, and we included everything they need to plan effective workouts for each group.
Before
.svg)
.svg)
- Initial page with date picker
- Pop up windows to add a drill
- Requires more memory to remember previous selections
After
- All input is on one page
- Collapsible sections give users control over their view
- Added feature to view previous workouts
- Coaches we interviewed like to review how their athletes trained in the past
Data entry needs to keep up with the athletes.
SOLO originally relied on voice input for coaches to enter data. The coach says an athlete’s name as they cross the finish line, and the app records the time. This raised questions of reliability. What if multiple athletes have the same name? Background noise and human speaking error will also cause problems.
We decided not to reinvent the wheel. Instead, we incorporated our findings from our competitor analysis. We implemented timers’ “stop” and “lap” buttons because this would maintain consistency and familiarity for track and field users. Buttons also decrease cognitive tasks for coaches since they can tap once to recordtimes and assign them to athletes later.
Before
.svg)
- Unreliable voice input
- Confusing display of
workout items - Carousel of pages for
each active workout makes it difficult to navigate between workouts
After
.svg)
.svg)
- List of today's workouts
- Simple button design to record times
- Improved visual organization
Incomplete, but a good start.
Scope creep is definitely real. There were still many features to improve and much more testing to be conducted, but by Sprint #11, it was time to move on.
At this point, my role began to transition from a UX Designer to a UX Developer. I moved on from Figma to VSCode, and we broke down our backlog tasks to individual components.
Side note: my team and I chose the Ionic framework to develop with, but as we began expanding the design, we realized we were quite limited by its selection of components. We began looking into alternatives and found that React Native may be of greater benefit, so we decided to transition to this new platform. It costed us a few story points, but looking at it from a long-term perspective, we felt it was valuable.
Our Jira Board
Looking back, we've come a long way.
Adjusting to the agile sprint process was initially difficult. We felt way over our heads when we began to tackle this project. Jira was a mystery, backlog items were untouched, and we weren't sure how to measure our progress.
At this point, my role began to transition from a UX Designer to a UX Developer. I moved on from Figma to VSCode, and we broke down our backlog tasks to individual components.
Side note: my team and I chose the Ionic framework to develop with, but as we began expanding the design, we realized we were quite limited by its selection of components. We began looking into alternatives and found that React Native may be of greater benefit, so we decided to transition to this new platform. It costed us a few story points, but looking at it from a long-term perspective, we felt it was valuable.
There's still more work to be done.
The main feature our product still lacks is data visualization. We put this on hold once we realized scope creep stole much of our time. We declared building and starting workouts were the most essential features of our app, so we prioritized those first.
It would also be nice to understand more of our target audience. I attempted to contact UCI's track and field team in order to conduct some field studies of their practices. I reached out to the coach, messaged several student athletes, and even stopped by the field to try to catch them at their practice. With a lack of response and external circumstances, our timeline quickly passed from the research phase to the development phase. And so, we moved on.
Everything I'd learned in the last four years was on the table.
This project challenged me to go beyond my lectures and textbooks, applying design principles in a real-world setting. The product requirements were no longer scripted, but I had a real client to consider and please. There were no assignment deadlines to keep track of, but my team and I had to manage our project timeline to meet our client's deadlines. Our design decisions were not guided by a professor, but rather we utilized design tools like testing and interviews to dig deeper into our user's needs.
The aspect that stretched me the most was the niche target audience. Not only were coach users difficult to get in contact with, but there were very few applications on the market to find inspiration from. While familiar designs are useful for creating intuitive designs, there aren't many apps that offer what SOLO does. So, we were left to reinvent the wheel.
I put into practice the main design principle I'd been learning in my graphic design position. I looked at interfaces that complete similar tasks for inspiration, but I explored outside the box to create innovative designs that fit our niche.
Overall, I learned how to work as a UX Developer, not just a student, and I grew as a team player. I'm better at communicating, designing, developing, and managing a longer-term project. This project, though challenging, was rewarding in the end.
