Role: Founder, Designer, Product Manager
The problem
The initial idea came from the demand I saw in my local soccer community. I’ve been playing since I hung up my ballet flats for sports at age 6, and still play on a few different adult rec teams. I’ve concluded that adults are busy, and it's hard to make it to a game every week on the same day. So, teams are consistently looking for subs when RSVPs are low. There are a lot of available players each day, and a lot of open spots on teams. For so long, these spots stayed open and these players remained available.
A solution
Scout aims to create matches on-demand based on skill level, location and availability. When you open the app, immediately you see a feed of games to browse. From there, the user can narrow their search with filters or post their own game. Once the user finds a game to join, they’ll send a request to the manager. My hypothesis is that mutual acceptance is important in finding the right subs for games. Once both parties confirm, the posted game will become inactive and direct communication will be offered via text.
This App Map outlines the different flows a user can take through the Scout experience and every page included in the app:
Notable Details
Filtering: The user can narrow the feed of games to their specifications by clicking the filter icon. I wanted to make this a quick interaction, so I used sliders with contextual feedback. Skill level is subjective, so I gave each of the 5 levels a name (Entry Level, Beginner, Intermediate, Advanced, Competitive) to make the meaning of each skill level more universal. Games are posted with one dedicated skill level, but I believe players should have the option to search within a range of skill levels.
The "Select a Game" flow:
Recycled Layouts: For the sake of consistency and engineering workload, I recycled as many layouts as possible. In this case, a user becomes familiar with posting a game. When they go back to edit a game, the layout is nearly identical.
Player and team feedback: Skill level feedback will be critical to Scout providing good matches. As with apps like Uber and Lyft, Scout forces users to rate the player or team they recently played with. New users initially set their own skill level, but once they hit a certain feedback threshold, their self-rating will be replaced with a user rating. In the future, new players may have a badge or different appearance to communicate that their skill level is self-rated. As for the etiquette rating, this helps us to keep players with good sportsmanship at the top of the list to be recruited. This feature was born out of years of mediating sportsmanship issues in our Facebook Group.
My process
My role on this project is broader than some of my professional Product Design work. I've done user research, pitched and worked on the idea at Startup Weekend, built a community of users ready to beta the app, and rallied an engineering team.
From a product perspective, I spent a lot of time working with friends to dream up the perfect future version of Scout. Understanding where I want the product to go (while leaving room for user data/feedback) helps me to make decisions on first steps. So began stripping back to the MVP (or MLP).
One thing is for sure: no other app is providing a service that matches players to games. So I decided that would be the focus, the rest would either supplement that, or wait for a future version.
A sketch of the MVP feature/flow map:
Minimum loveable product means we need to delight our users during our first at-bat. This feature is important to me because I believe it will impress our users and plant a seed for better matches long term. A closer look at the decision to rate players on two qualities:
An earlier iteration of the App Map with many unanswered questions jotted down during the exploration. Also, another shameless Swipies plug:
In keeping the MVP as lean as possible, we brainstormed back and forth on a few features we know we want to build up in the next release. Sketches below show the debate on how deep a manager can go to review the people who have requested to join their game, and how (or whether) those requests are grouped.
Tools
Sketch for wireframing and UI:
Principle for communicating interaction with engineering:
Next steps
Like anyone with an idea, I have so much I’d like to do with future features. My ideal next steps would be: in-app messaging and overall automation of the confirmation process, adding teams (that players can belong to and ratings can be associated with) and RSVPs to the app so everything is managed in one place, and allowing favoriting of players so that a manager can reach out to their own personal bench before going public with their game listing.
But first, we are developing on our beta and will react to the data we collect to influence our next release.