At the beginning of 2015, I founded a startup named Lovelô with three other people. It was a fantastic experience that made me understand even more about discovering what users want and how to find the balance between the user and business needs.
In this case study, I want to share a bit of the process it took to build the iOS app, beginning with research, working through ideation, and then revealing outcome.
Lovelô's primary objective is to help people be more active and maintain exercising. In our preliminary research, we found out that in Brazil, 40% of people stop going to the gym after the first two months. Some people start to get bored going to the same place at the same time. Others don't feel like leaving their house to exercise.
Our solution was to provide our users access to more than 8.000 activities in several studios and gyms, so they don't get bored, while also making a home workout option for those who don’t want to get out.
We already had a web app where people could book their classes in studios and gyms, but the performance wasn't the best in mobile devices. We needed to start building new features so the users could exercise in their own homes. After some research, we decided to change our focus and put our efforts on an iOS app.
The primary challenges we faced in developing an iOS app was the small budget and the deadline. In a fast-paced startup, every second counts. We had to be careful to take a lean approach while collecting enough user insights prior to implementing anything.
My first step was to gather all the information and research we already had, sit down with the team and start discussing and drawing out ideas. I believe it's essential to involve everyone from the beginning and collect all the ideas and insights as soon as possible. Admittedly, I had to be extra careful to moderate the session to make it productive and not an endless discussion.
We used a simple vote system to prioritize the features and ideas, and at the end of the day, we had a bunch of sketches ready to be polished. We also used the session to brainstorm what features may become problematic, giving us a better idea about what may need to be sacrificed.
I wanted a realistic version for user testing to not only get feedback about the main features but also compare how the user would feel using an iOS-like app vs. our previous web app interface. We were also planning to use as much iOS default components as possible to make development faster and easier.
Before the Design Sprint, Google Ventures had this research method called "research sprint" that was basically a framework for a quick and inexpensive user testing. It was a fast and reliable way to answer essential questions and test assumptions without the time or expense of launching a product. It reduces risk and helps the team work quickly and confidently.
I decided to proceed with this framework to answer some of the most important questions we had about our next steps as a company:
The first step of the research sprint is to identify and select the right participants, screening out the ones that won’t provide helpful feedback. We mainly wanted to talk to people between 18 and 50 years old who exercise and are iPhone users. We also wanted to exclude specific people that are unusually technical, out of age, or working in the sector.
To find the right people for my interviews, I wrote a screener questionnaire. Every potential participant filled it. I sorted them based on their responses until I had five people that fit the bill.
Like any good survey, it was essential to write questions that didn’t reveal the “right” answers.
I created my questionnaire using Typeform, and you can find the original version here (It’s in Portuguese).
To recruit people I used olx.com.br (it’s a kind of Brazilian Craigslist) and offered them a gift card to participate in the research. It was a fast and inexpensive way to recruit people.
After selecting the participants based on my criteria and scheduling their interviews, I started to create my interview guide. I began with open-ended questions about their past experiences and current behavior. I tried to get more context about their life, habits, attitudes, and problems to help me understand their reactions and feedback.
These initial questions are an excellent opportunity to build rapport. It makes the participants more comfortable about giving me real reactions and honest feedback during the interview.
I booked a quiet room and used a simple camera on a tripod connected to my laptop to record the interview. I used some personal details shared by the participant to personalize the scenario and tasks.
Being a good interviewer takes time and practice, but with some tips in mind it's not that hard to do a good job:
After all the interviews, I spent some time analyzing the recordings and summarizing what I learned to plan my next steps. As we already had a good idea of our users’ needs from previous research, the user testing didn't uncover any significant issue. It still was a great way to validate our ideas and give us confidence in our solutions before implementing anything.
After a few adjustments, we were ready to go. That was one of the benefits of the high-fidelity prototype approach, and it saved us much time between user testing and the final version. As mentioned before, we tried to use iOS components whenever possible to make our development more straightforward and faster.
The first step is to choose between doing a program or exercise routine at home or booking a class at the gym. In the program list, the user can select the one that fits him the best based on the type of exercise, experience points, calories, or time.
In the program overview, the user can select between three levels of intensity: light, default, or heavy. There he can also find the exercise list and warm up tips.
At home, the goal is to exercise in the shortest time possible. The video starts automatically so the user can focus on the exercise.
After completing the program, you can leave a comment on your feed, add a photo, and share it on your social network.
The user can search for any class using the map, filtering by date, time, name, or modality of the class. The classes are clustered by distance and location. In the class overview screen, the user can find useful information, such as available spots, who's going, description, reviews, and facilities.
After booking a class, the user can also share it on his social network and invite his friends to join him.
The feed shows several activities: when you book a class, go to a class, finish a program, and more. The aim of the comments and likes feature is to keep the community engaged.
Every activity counts and the user earns experience points from them. The points and the list of the most active users are shown on the leaderboard, encouraging healthy competition.
It's also easy to find friends from Facebook or the user’s contact list. The user can also invite friends using the app, allowing them to get a discount when they subscribe.
The payment flow aims to be intuitive and straightforward. The user can scan their credit card or type it in. This visual approach with the credit card was well received during the user testing and is big win over the credit card errors we used to have.
Right after user testing, our developer started to build the base for everything and we kept working closely during the process. Good communication was essential for us to keep moving at a good pace. I shared new screens and ideas daily so we could discuss what would be a better approach.
When the first version was ready to go, we started testing it on TestFlight. We invited some of our closest users to the beta test and made a private group on Facebook for them to post bugs, questions, and comments. That helped us a lot to uncover bugs and issues.