While foosball matches are played by 2 or 4 players on opposing teams, mastery of specific techniques requires hours of independent practice. Training sessions are most effective when they are directed at specific skills and when the player knows how to correctly perform the skills being practiced. Unfocused training sessions do little to improve player performance, and practicing skills incorrectly can reinforce poor technique and increase the risk of repetitive motion injuries.
I was approached by an International Foosball Promotions (IFP) tour player to design a mobile app to facilitate foosball training and skill acquisition. I worked with 2 developers and stakeholder on research & product strategy, information architecture, interaction design, UX design, UI design, and visual brand direction.
We worked on a suite of apps for competitive foosball players, including two published apps to track foosball tournament scores and rankings, for Apple iOS and Android:
There are very few (well, one) foosball training apps currently available, so I began research exploration of foosball training resources, sports training mobile apps, and apps with features relevant to our product.
I interviewed several competitive foosball players to better understand practice habits. Patterns emerged pointing to 3 primary practice assistance areas to target with the app:
Combining stakeholder objectives with player insights, I arrived at 4 key areas to address in the app design:
Because Slingshot is an app based on executing drills, we needed to include a library of the included drills that could interface with the backend database. At first glance, the list of drills was intimidatingly long, so I devised a clear organization of drill categories and drill variation modifiers that would not overwhelm our users. These categorizations and modifications will be also used on the back end to randomize drills into workouts using a weighted distribution formula.
My goal for initial sketches was to define critical screens & develop a general design organization.
As I worked on the screen sketches & information architecture, my developer began creating the underlying structure of the app, providing an early interactive prototype to test potential flows and points of interaction.
With a complete set of wireframes in place, we were ready to start testing our flows through foosball drills & workouts, from choosing the task in the dashboard through setting it up and running through the execution screens. Our test participants yielded great insights on app functionality, which we used to iterate and improve app functionality:
During our testing sessions, we used a combination of an interactive prototype created in Invision, which reflected the actual layout of the screens, and a coded prototype, which better reflected the screen functionality. This combination of testing revealed design issues that either method alone would not have uncovered. For example, we were able to tell from the coded prototype that some transition between "start drill" and drill execution would be necessary, and decided to include a voice "3, 2, 1" prompt upon execution screen loading. We also ended up questioning the usefulness of the hamburger menu, and decided to use a global bottom navigation instead.
While we will ultimately build the Slingshot app for both iOS and Android, we decided to focus MVP development on the Android platform, so we followed Material Design style guidelines. The simplicity of this style also keeps the focus on the function and interactions with the app (although we did intersperse some personality to the experience!).
Even before the MVP release, this app has been through a lot of iterations based on initial feedback. Two changes in particular were based on important lessons:
1. SimplicityOur initial flow through a workout started with a screen of each drill presented in a card format. Each drill began with an instruction screen, moved to the drill execution screen, and ended with a summary screen, before returning to the main workout screen of drill cards. This meant a lot of button presses to move to the next screen. We simplified this process so that as you move through the workout, the completed drills are presented in "done" format on the same screen, making it easier to see progress while reducing button presses.
2. EngagementKeeping users engaged with the app throughout the workout is important. Unlike the other drills, which kept the player engaged throughout the drill, our "untimed repetitions" drill type asked players to go do the drill, then come back when they were done. It was hard to keep track of the number of reps completed, and tended to either fizzle out or stray into unfocused practice. We considered adding a "shot" button to hit after each execution, but that would be an impractical solution.
Our first inclination was to just take out this last metric. We have some cool ideas for how to re-incorporate it in future iterations, but we're not quite there yet (more on that below). But we still felt that there was a good case for this type of drill, as these straight repetitions are what build the muscle memory that is critical for player development. So we decided to ask players to perform the skill for a length of time instead of number of repetitions, which allows us to maintain engagement throughout the drill and draw them back to the workout once the time period is over.
Uniquely foosballWe're currently working on AI-based counting of foosball shots, using a sensor inside the goal box, or voice-activated shot counting. We'd ultimately like to implement a shot-counting solution that takes advantage of audio-feedback that is unique to foosball: the distinctive "plink" noise made by a foosball hitting the back of the goal box. As with voice-activated AI, this solution may not be practically feasible with the current generation of technology, but we are continuing to work towards some form of AI-assisted repetition counting!