It all started with a 2 page project brief on what our team of 3 needs to deliver in 2 weeks, to our client Tough Mudder (“TM”).
“Know thy self, know thy enemy. A thousand battles, a thousand victories” — Sun Tze
Understanding the team
It was the first time our team of 3 were working together. We spent some time understanding each other. With these information, we set up our team’s ground rules, e.g. unavailable timings after hours, mode of communication, splitting of work, etc. With better understanding, we would be a step closer to success.
From the brief. Develop an app that facilitates team training and builds team camaraderie to strengthen Tough Mudder teams, so as to encourage repeat participants and increase participants’ loyalty to Tough Mudder races.
Competitive / Comparative Analysis
Understanding our competitors
We read up about TM, and some of its competitors, i.e. Spartan, Rat Race, Badass Dash and Muddy Race. Most of these events were not available in SG, except Spartan. The challenge was starting to look TOUGH.
“When the going gets tough, the tough gets going.”
Of the 4 competitors, TM and Rat Race offered team events, whereas Spartan, Muddy Race and Badass Dash offered individual events. Spartan was the only one which had a mobile training app.
The TM registration process required the participant to sign up as a team, and provide all participants’ information at sign up. This led to a very long and tedious registration process. Race Race also required the participant to sign up as a team, however, the team mates details could be provided at a later date until two weeks prior the event.
Tough Mudder had a collection of motivational and training videos posted on their website.
Rat Race provided detailed write ups on proposed training exercises that could be done, however, the last update was in 2014.
Spartan had the most amount of training related information available on their website. These included, nutrition plan, detailed write ups on proposed training exercises, locating a gym nearby, etc. Spartan also had a training app, which mirrored the training resources on the website.
We put together a simple survey to find out what people knew about team obstacle races, physical sports type training and fitness apps. The screener questions were all multiple choice type questions.
We received 48 respondents from all walks of life in less than a day of posting it. From the responses, we could see some key trends in team activities, sports training and usage of fitness apps. We picked 10 persons of varying fitness levels, training intensity and training requirements for our interviews.
Interviews were a way to collect more data for further analysis. These were conducted over 2 days. We spent half a day brainstorming our interview questions and did a trial interview amongst ourselves to confirm that the questions were relevant. After we refined the questions, we conducted our first 3 interviews as a team, rotating between interviewer, observer and note taker. The results received were rather disappointing as we weren’t able to get what we need. Thus, we made further adjustments to our questions to make them more concise without being overly specific.
The interview questions were kept short and broad to allow interviewees to speak whatever came to their mind.
“Could you share with us what comes to your mind when you hear ‘Team Obstacle Race’?”
“Tell me about the training you did to prepare for <that event>.”
“Tell us about the fitness apps that you use.”
The interviews were challenging as most interviewees were quite stumped when asked about “Team Obstacle Races”. As we had anticipated that this could happen, we quickly switch over to training and fitness apps related questions as these were key to the training app. While we do try to let the interviewees guide the session, there were times when we needed to prompt.
“Could you tell me what pains you most when using the apps?”
“You mentioned you did <… …>. Could you share more details on what you enjoyed about it?”
10 interviews and a bunch of feedback. We weren’t sure how we should start, thus, we decided to go with what we were familiar with. Pain, pleasure, context and behaviour. And as more stickies went up, we started to regroup them in a different way! We started moving the points back and forth, breaking in little discussions various times to talk about where some of the stickies should go.
Things started to fall in place. The natural relationships appeared. Some relationships contained a lot of points, so we broke them up into sub relationships.
Fitness Apps — Tracking Exercise, Common apps used, Chat/cheer/taunt friends
Training — People do train (surprisingly), People who don’t train
Motivation — Peers, Competition, Self
A bunch of other smaller points which didn’t seem related to training app at the point in time — Forming teams, team building, common goal, cost of race, fun, training videos, new experiences, event day related items
From the interviews, we were able to pick out some common traits.
- Fitness Buff: Serious exercise, usually prefer to train alone as they do not want to be slowed down by others. Group training typically involved other fanatics.
- Social Fitness Fans: People who exercise if it was fun, or they had friends to do it with.
- The “In-betweens”: People who exercised to keep fit but sometimes needed extra motivation or fun element to keep them going
We created 2 personas, Huffy (the Fitness Buff) and Puff (The Social Fitness Fan Junkie), to guide us in our quest to prototype the app. The app should be able to help Huffy and Puffy train and get ready for the Tough Mudder event.
From the affinity maps, we picked out all the features which were required and prioritised them based on their demand and cost of implementation.
The features which would be prototyped were those with average demand and cost of implementation. These features would allow mudders to motivate each other by sending challenges to each other, track their team’s progress on these challenges and chat with team mates.
Allowing mudders to send training challenges to their team mate, gave individuals the flexibility to complete these challenges in their own time.
Tracking and viewing each other’s progress served as motivators for both individuals and teams to train harder.
The chat module allowed mudder teams to effectively communicate within their teams, within the convenience of a single app.
From our research, most people already owned at least 1 fitness app which was capable of tracking various fitness markers. Syncing data from these external sources would lower the cost of implementation compared to developing our own trackers. This would also increase convenience to mudders since they would be able to continue using apps which were familiar to them. As this feature involved further research into 3rd party fitness apps, the team prioritised this for prototyping and testing at a later phase, to allow for more time to perform an in-dept study.
The features which were low in demand had been parked aside for future development.
We drew several potential designs for each screen before we discussed and selected the ones which were more intuitive. We applied some of Jakob Nielsen’s 10 heuristics for Interface Design, during the sketching exercises. We made reference to other similar apps, so that people would not need to “re-learn” our app. For consistency, we tried to use standardised icons and words instead of reinventing our own.
From there, we proceeded with more sketching of the intermediate screens to ensure smooth end to end testing for our scenarios. We did an internal test and made some fine tuning based on our observations.
Prototype & Test
We created a time box for these activities. 3 1-day sprints. For each sprint we targeted to test with at least 4 persons and revise the prototype based on test findings.
To ensure consistency throughout all our tests, we gave each person an information sheet for reference, to supplement the verbal brief. We observed that most people referred to the information sheet during the tests, and there were no cases of incomplete test due to forgetting of the test scenarios.
Low fidelity paper prototype. This was made from our initial sketches, put on POP, to make it clickable. 6 people tested our prototype.
Feedback. Too complex, overloaded with information and unclear visual hierarchy. Some people had trouble completing the tasks due to the low fidelity content on our prototype.
The team decided to move into a higher fidelity digitised prototype, which would incorporate the feedback that was received.
Interactive Digital Prototype, on inVision.
Feedback. Still too much information on some pages. Icons and tracking statistics were confusing. Navigation was also challenged as the menu was hidden.
We made more refinements based on the feedback. Key improvement was to replace the hidden menu with a navigation bar at the bottom of the screen. This cut down 1 tap to reach the required feature. YEAH!
Feedback. Most people agreed that they could perform the tasks easily as the screens were familiar and resembled other apps that they had used before, and graphics were visually appealing. However, there were still a couple of feedback relating to display of information on some pages. We proceed to make some minor enhancements to our prototype.
The Final Product
The birth of our Tough Mudder Training Prototype on InVision after 2 gruelling weeks!
Potential future development:
- Mobile App
- Research and allow synchronisation of data from 3rd party fitness apps
- Include Instruction Fitness Videos
- Find a workout / gym (location services required)
- Schedule training (self and team)
- Simplify registration process (possibly individual registration, and use “Build A Team” to include other registered participants as team mates)
- Enhance “Build A Team” to allow participants to easily and quickly find team mates
Working as a team brought the project to a different dimension. More people to manage. People management was never easy. Different work styles, expectations, made this project a lot more challenging. However, it also allowed me to look beyond what I normally would. More ideas were generated, as we had different perspectives about the same issue. Being objective, keeping an open mind during discussion (especially when there were conflicting views), willingness to accept critic and suggestions, helped to resolve issues quickly. Taking a short break helped to clear the mind and a more rationale solution would emerge. Assignment of work units was interesting. While it would be more efficient to assign work to people who were familiar with it, it would mean the person wouldn’t be able to develop skills in unfamiliar areas. To ensure we all had equal chances to learn, everyone had to participate in every stage. To improve efficiency, we encourage each other to volunteer to take up the more detailed work that they were comfortable in.