We Play Sport is a company I co-founded that allows people playing ball sports such as basketball, to record their matches using a smartphone. The footage is uploaded and then using AI, highlight videos are dynamically created along with interesting match data to be used for match analysis or shared on socials. We did a pre-seed raise and reached a monthly active users of 15k with an average in-app time of almost 10 minutes.
As co-founder of an early startup I did a bit of pretty much everything, (including code) but my main role was leading product and design.
⬆️ Increased success rate of recordings
🏃 Speeded up time to ‘go live’
🧠 More match footage data to train AI model
⬆️ Increased new user adoption
Achieve a 90%+ match recording success rate. A secondary goal was to improve the quality of recordings that were successful.
How I lead taking our MVP for recording matches and rapidly created a recording app that reduced failed recording attempts, speeded up ‘go live’ times, increased the amount of match footage our AI had to analyse ultimately increasing the likelihood of new user adoption
The problem with the current app was that it had many points of potential failure. Failed attempts included, lack of phone storage space, errors in iCloud links, people not having iCloud space. It also involves a lot of investment from the user before they see the value. The set-up takes time, but we found once people saw the results of their recording with the data and dynamic video collections we created for them, they would really engage and be motivated to go through that slight pain and record again.
Another side issue was when folks did take the time to record, sometimes the setup wasn’t right. Bad capture angles, not ideal cropping, not the right zoom which all meant the footage wasn’t great. Not the users fault - we only had an initial onboard chat then they were left alone so we needed to introduce more hand holding.
By looking at our data and talking to users, I began by creating a list of all the attempts to record and where and why they failed to begin categorising and work out where the major barriers were. At this stage we want to be as fast as possible so if we can get an idea of all issues we can possibly address some without the need to build something.
The ‘didn’t even attempt’ number was already pretty large but was also trending up, from user interviews we found we basically put too much load on the user...
There were also other factors around personal commitment, e.g. those that had found us or had an interest in the technology would have a higher tolerance for barriers, while others who hadn’t signed up personally but who’s federation or club had made an agreement they would participate needed a bit more convincing.
One of our biggest pain points was iCloud. It cost people money, took time to upload to it, took us time to download it, it then took us more time upload into our system and was just too fiddly with share links etc etc.
To by-pass this step for the user, I set up a week-long sprint to develop a quick upload system that went direct into our system; a user would still have to use the ios camera but then could go to a URL and simply upload the video from their phone directly to us so we save time downloading and re-uploading to get the matches live faster.
At this stage I also started thinking about a basic design library of components as wanted to be keeping UI pretty light in terms of time spent.
Positive -
Negative -
Next steps -
We had enough confidence at this stage with the amount of users we had (and to be honest with the amount of complaints about the process) we could justify spending time and diverting all team effort to build out a dedicated capture app.
The idea would be a focused app that allows....
We time boxed 3 week long sprints to build it during which I also designed the flow and basic UI. A particular challenge is how to guide someone through the two phone setup, so I worked on a better capture flow. We also had great ideas of device syncing (which we would go on to do later) but this was not an option for a 3 week sprint.
To further save the user time and effort, we began automatically populating the most likely game fixture based on the user’s email (we know who is connected which club) day and location. I also designed a way for users to create a new fixture to add to our system if needed so they were never blocked.
At this point I was sharing these basic flows with humans to see how they handled them and if it made sense. There was feedback around the initial call to action 'record match' - people were hesitant as though it would launch the camera at this point, when in fact the first step was to find the fixture, so we experimented with language. But other than that, tests were positive so we began building and any other issues we would test live at the matches.
This was another pain point for people and we needed to find a better way to guide users and give tips to reduce bad quality recordings. This part of the experience is hard to fake in Figma for testing so I set about taking all we had learnt about set up from being at the matches with users and put into a quick real build we could test live with real environments.
At this time, I also designed and updated the fixture list in a scalable way so we could easily tweak, add more states and other elements as things evolved. Again these were shown to humans and tweaked with feedback but as with all of this, I felt we could only get good trusted feedback from getting this into the situation it will be used in rather than faking it. We just didn't have time for lots of design iterations. I am a huge advocate for testing in the most real situation as possible - get out of Figma into build.
What we ended up building in the sprints was..
I also mapped out every event and flow for the devs to integrate Mixpanel so we could create reports and see where folks got stuck or things broke. We tested for a period over 3 weekends which was about 40ish matches.
Overall those that used the app over iCloud method had a more seamless experience. Being all in the one app experience meant we got the video footage pretty much instantly (when connection allowed) and most matches were live within 24 hours of it being recorded (before they 48+).
Now the process was a bit more self guided, we spoke to users less as the file upload was more efficient - but with this meant that the messaging we took for granted around telling users we have the files, they look good etc, we weren't doing this in the app so users felt in the dark about what was happening.
The two device flow was still a big thing for users, doing the set up twice felt fiddly and people were confused. Also we found that we would sometimes have issues where footage would
From our side the fixture selection was very helpful as it meant all video file matching was done for us.
38 matches possible - 100% were uploaded
29 (76%) successfully using the new app - 9 (24%) using MVP method
Those using the app - 100% were of good quality - aligned correctly etc so up significantly from 75% (this could be due to these being our 'best' users though)
Those using the app - 26 of 29 - (90%) - were live in under 24 hours (most in under 12)
So aim was to get to a 90% + success rate so we weren't there at this stage but there was a strong indicator it was a better process so we confident it was worth staying with this and iterating further (as time went on and we ironed bugs we did hit and get higher to 92%)
Quality was up and time to live was a huge win at this stage and just the process being less 'jump from one product to another' and also showed that some users could pick this up without a manual onboard which would be vital for a more organic growth to get better traction.
There was tons of things we learnt...
Give users more messaging about upload and success state and how long things take to go live and when they are live or if there are any issues and how to resolve.
Handling offline tweak
We found that users with terrible internet and no 4g signal upload streaming would not work didn't work. We didn't really have an offline mode so when connection was bad - we could 't call the fixture list or suggest fixtures. So I designed a quick fix to stop those users being blocked by being able to record with no connection.
Backend dashboard for eduMe allowing customers to manage learners and content
Building a flexible data system so content can be brought into a view depending on context.
