Eastnine
A MARKETPLACE APPROACH TO THE FITNESS INDUSTRY
The fitness industry is saturated. People also don’t have enough knowledge or motivation to stick to more than one product, but they do appreciate people behind fitness.
Fitness influencers and personal trainers can attract and retain people thanks to their human touch.
Eastnine mission is to build the markeplace of fitness to allow trainers to earn from their community.
Trainers faced multiple issues, from not knowing how to build a community to being able to manage their business remotely because of COVID-19.
Eastnine listened to them to build the perfect platform for trainers and users.
As a first step to build the best platform for trainers was to understand their current way of working, their struggles and their needs. With the team we set up a first round of introductionary interviews with Eastnine trainers. At this stage we kept it quite generic, in order not to bias their responses and get a real sense of their perspective.
Here are some of the questions we prepared:
“How do you approach remote training?”
“ How do you promote your content?”
“ How do you build your community? Do you do any promoting?”
“ How do you track payments and clients?”
“ Which tools do you use for your business?”
“ Is there a specific step in your process that you wish would be better?”
We used Notion to organise all our research. We created a page for each trainer and added our findings.
From the first interview we started to see some pattern and common pain points:
Trainers have to use multiple platforms, like spreadsheets for payment, whatsapp for communications and Zoom for delivering the content.
In addition to the confusion of using different platform, the trainers also struggled with the manual labour involved into the process, which sometimes made also things uncomfortable (for example having to directly approach a trainer to say you don’t want to renew the subscription)
Another pain point we heard about was the impossibility to clearly monitor the growth of their business and their offers.
All in one
These points validated our idea of the need of a platform that would include all the tools needed to record, publish, promote and monitor content.
A unique platform would reduce massively the friction and would also make it easier for users to access and control their subscriptions.
The product needs to be simple
With the whole COVID-19 situation, a lot of trainer had to re-invent themselves and their ways of working. Lots of them complained about how all the tools created to simplified their life would actually create more barriers. This told us that we needed to listen to our trainers even more, in order to build the perfect tool for them.
After the first round of interviews we started including the rest of the team. We worked in sprints, and the first day of sprint was sharing our findings with the team using digital post-its on a Miro board. We opened the floor for questions, and when we didn’t know the answer, we added the question for future interviews.
After bringing everyone up to speed on what we know so far, we started to trying to define a scope of work for the first iteration and which strategy would be the best and fastest approach for building a new product.
We took in consideration where the majority of struggles were into the trainers’ workflow and what we could build in a reasonably time, so we could test it with them as soon as possible.
We decided to start from the Information Architecture – to give us a first idea of how all the pieces would fit together. This gave the design a good view of the holistc product and allowed us to break down the work into sprints. For this part we started very broadly to decide, on a high level, how content would be store, how trainers would access each section of the app and how users would do the same. As we went along with this process we asked ourself questions like “What’s the difference between trainers and users? If there are any” “What would a trainer see?” “What would a user see?” “How would users discover a trainer?”
As the second day of the sprint we involved the team in a skecth exercise. We asked everyone to come up with as many sketches as they wanted regarding the reasearch we layed out on the Miro Board.
The response was amazing and it also meant that we had very different views on the same feature or section of the app. Including the whole team had a great impact for the design team because we were able to see things from a different perspective and discuss the sketches, not only from a design or UI point of view, but also from the point of view of a developer or a marketer.
We collected al the sketches in the same miro board we used to showcase our finding on the frist day of sprint and we proceed to discuss each idea and add to them or discuss why they weren’t feasable for the sprint or if they could easily fit into it.
After having reviewed all the sketches we decided that for the first sprint we would focus on the upload process. To this point the upload process was very manual and it included a google form, lots of interactions between trainers and people at Eastnine.
Translating the upload process into the app would benefit both the existing app as well as the future one, so it seemed to everyone the most valuable option.
Insights from the Sketch day
YOUR TEAM IS EXTREMELY VALUABLE
People in the team outside the design squad were a bit hesitant wheter they would be able to sketch and actually add value to the sprint work. We reassuared and explained that the sketches were not the important part and we were more interested in ideas and the whole team had fantastic ideas. What also helped was writing down the concept alongside the sketch.
Defying a sprint scope of work is hard
When designign a complete new product is always tough deciding where to start, expecially if the product is big and the time is limited. What really helped us was to compare the value and the time to build a feature.
It also pushed us a lot that the first feature we decided to focus on would greatly benefit existing trainer on Eastnine.
Design
For the third day of Sprint we had a first stab at the screens design. We obviously did some competitor research lookinf at other markeplaces, platforms for creators and fitness apps.
We then used the Google form that was been used by trainers to upload content as a blueprint for the form. We discussed which fields were more important, which fields needed some adjustment since the interacation between trainers and Community managers at Eastnine would not be part of the process anymore.
During the design part we had lots of questions like “how long does it usually take for a video to upload to our platform?” “Which equipements should we include? Or would this be a free text field?” “How do we manage the upload process? Do we allow the user to keep using the app or do we block the process? Which are the technical implications?”
To anser these and other questions we kept in touch with the development team the whol time, so we could solve one bits at the time and keep designing.
For the Design we used Figma, to allow the rest of the team member to comment direcly on the screens and give feedback in real time.
Figma allowed us to get enough feedback to smoothly tranistion to the nest phase of the Sprint: wireframing and prototyping. The aim is to create a complete enough prototype to test with our users. Whie doing this, we also contacted some trainers to start setting up interview slots. We tested the first prototype with 10 trainers, some were used to the Google form, while others were new joiners to Eastnine and didn’t have a chance to experience it.
For the prototype we also included some other screens to collected reactions and feelings around other features like messages, explore and settings. During this first phase we only focused on one kind of user: trainers.
We used Zoom for all the interviews asking the trainers to share their screen after sending them a link to the Figma prototype. We took notes during the interviews and also asked the member of the team not in the interview to go over and add notes so we could have different pairs of ears on the same feedback.
To collect all the feedback we used Miro – We took screenshots of each screen and created a board with them and with colour coded post-its where we could write down our notes and place them on the relevant screen the feedback was referring to. This was great for enabling collaboration and flexibility (part of the team worked on a different time zone). It also allowed us to see where the majority of feedback was and where we should focus our effort for the next iteration.
We clearly saw from the beginning there were some issues:
- We tried to incorporate lives and on demand content, but the wording was for the most part just confusing.
- Feedback around messaging was mostly positive, with some concern about it becoming too overwhelming if every user were allowed to message trainers.
- No one had a distinctive idea of how Explore and Home would work and how they’d differ.
- Most of the trainer were impressed by the easy access to stats and revenue.
- The content upload flow was easy enough to allow every trainer to finish it up in a reasonably quickly manner.
Other than the Miro board we also created a Google presenation collecting the highlights for each screen so we could present our findings to the broader team and also as a tidier way to document our research.
After this we reconvened and tweaked the initial design, taking off everything that was too confusing. We discussed with the development team to see how much of the design they were able to build in their next Sprint. We striped out the live/on demand section since we didn’t have the ability to live record any session yet. We also eliminated the time display field since every trainer we talked to thought they could edit it, and because this was not the case, it created unecessary friction.
Develop
We created a new Figma file to document each Sprint. For Each Sprint we created a new page so we could link specific screens to the iOS developers.
Using the existing design system we proceed to define the final UI of the screens, the interactions, the baheviour and rules for each component.
To define all the interactions and bahviours we wrote test cases in the assigned Jira ticket. This is always quite a boring and sometime confusing part of the job, but I’ve found that addign a simple table to the ticket, with 4 coloumns for GIVEN, WHEN, THEN, STATUS made the whole process more enjoyable and easier. It is also a great way for designers and developers to collaborate, as the table can be edit quite easily in case of last minute change: which are not unsual in an agile team.
The developers can also change the status on the specific test cases so everyone knows where they are blocked and why.
Working this way also allowed us to clearly define a MVP for the public launch, which also allowed the whole team to have a good vision of nest steps and overall direction.
After the design was implemented we tested internally using testflight, logging bugs and letting the developers know if there were missing or wrong parts, for example one of the icon wasn’t rendering correctly, but with some collaboration between the team we managed to fix it quickly.
For the next round of testing we involved some of the trainer we spoke with and instruct them, using a page in Notion, on how to create an account on Testflight and how to log into the app to start testing. We set up accounts for them, connected to their existing ID into the current app, so they could, publish their content directly into their live profile on Eastnine.
We also set up a Whatsapp group to make communications easier and quicker. We also used this group to collect quick feedback from the traines and send them small A/B tests that we wanted to check.
Conclusion
All the trainers included in the test started using the Markeplace to upload their content which was successfully available on the existing Eastnine app.