Working at Brainly
Homework help for students
Brainly is an education technology platform supporting +350 million school-aged students in the United States.
My role was of a Senior Product Designer in the B2C paid service, Tutoring, which connected students with tutors.
I was the core designer of this team’s projects, leveraging design strategy and business to reach the best outcomes with stakeholders.
We worked with mobile (iOS and Android) and a web-based version of the platform.
Projects were built as a team with a strong design thinking process.
We collaborated extensively with product managers, engineers, data analysts, quality assurance, and directors.
Understanding the market, and its possibilities
More than a million opportunities!
India is a fierce market with a lot of learning tools available. Students rely on digital means of getting ahead in class, including a vast array of local digital products, Brainly already has a lot of users but wants to convert them into paying customers
Brainly has around 4.4 million monthly users in India (👀really!) but most use the freemium version of the product. Some users convert when understanding its value through free trial sessions
Need to deepen the business impact
The conversion rate was extremely low in India, the goal was to increase it by bringing the platform closer to other key players in this market.
The project… audio sessions in India
Bringing all the features to the yard
Qualitative research was performed in this market to understand the competitors, and the data showed that users wanted to have video calls with tutors.
Technically speaking a video call was too massive for an MVP and meant changing the whole structure of the service.
It was settled with Stakeholders that the first iteration of this product would be focused on Audio, and its impact would be assessed.
We performed user research to understand the expectations that users had for Tutoring and how they would react to having an Audio session.
Some early Wireframes and concepts
There was a lot of brainstorming done to understand the user’s relationship with the Tutor, for example, if the user should “receive a call” from the Tutor, and how to communicate the call to them.
Ultimately it was decided to go for a more simple solution and avoid the “call” concept.
The UI shouldn’t be intrusive to the user’s experience, the simpler, the better.
Building the research
Testing under pressure, and for difficult scenarios
We performed research in India, with 10 non-Brainly users via video call, all school-aged children.
Testing meant testing an actual class between a Student and a tutor. So we needed a working app rather than a prototype.
By closely working with an Android developer we built a version of the app specifically prepared for testing.
We also brought in tutors (employed by Brainly), who we coached and prepared for the interviews.
→ The live prototype
The final prototype was very simple, the complexity laid with performing a live session within the interview
This was a very analytical project, we wanted to assess and measure how users interacted with the platform
We wanted to see the Tutoring sessions with audio in action, how would users react?
What information did we get from the experience?
Testing in unexpected markets
Testing in a live environment meant unforeseen challenges - We designed the prototype for the smallest Android device available. What happened?..the user had a smaller device!
We learnt that we should consider better local external factors, such as phones and internet connection in India.
We learned that these are very relevant cultural and environmental issues that users deal with daily.
When we continue testing for this market we will try to make our sessions more inclusive and safer for testing.
Sharing the results & leveraging the MVP
Affinity mapping from the results obtained in the interviews — for a closer look at my UXR process, we can do a call!
The research was very successful, but all users did comment that they were expecting some sort of video call (or seeing the tutor) but were still very satisfied with the new format.
We also gained very important insights about India as a culture and the user’s living situation.
We discovered that issues such as poor internet connection, device quality, living situation, and even weather can affect how users interact with the product.
Users also highlighted that they may want to use the app in other ways, audio is not the best option all the time, or for their needs.
Leveraging user-centricity with managers
I shared with business stakeholders my concerns of forcing users to have audio sessions by default
Being sensitive to the culture and country’s situation, users might be inclined to be actively talking by default, and might produce user dropout in an already dangerously low CVR
We reached a compromise: There would be close monitoring of the release, and if the results were not optimal then we would consider altering the flow
Success would be measured by the CVR (very low at the moment), and session rating, if continues to be low, or drops, actions would be taken
The business perspective
20%
Conversion Rate (CVR)
The new realise didn’t improve it
0.5
Average sessions per user
The new realise didn’t improve it
Usability testing with Brainly users. How can accommodate to their mental models?
Bring in accessibility to the discussion, how can we improve product access in the India market?
This project failed to "move the needle” for conversion rate and number of sessions requested. So the next steps would be to:
A/B test with an alternate format, giving the user the choice between normal or audio Tutoring session
Test other areas of the platform. How is Tutoring value being communicated?
How will this project scale?
Looking at the next steps…
This project started the path for improvement of the platform and opened the way to grab a further slice of the market inside the Indian Tutoring market.
The research will be replicated in the US to assess the needs of the US students vs. the Indian students for this feature.
Other improvements and features were identified from research and will take place in later iterations - video calls, in particular, will be a large project on its own.
…and what would I have done differently?
❗️At points, this project felt rushed it would have worked better if we had more time to analyse and test the outcomes and avoid so much back-and-forth.
🖥️ It would have been more valuable for the user to have A/B testing to see if the audio/chat chooser incentivised conversion.
