Rythmico is a new music tutoring company focusing on bringing more students and tutors together. With the release of their app, students will be able to find and book the best music teachers and classes in their local area, right from their phone. By taking away the need for external communication, everything from tutor schedules and communication will all be managed from the app. There has never been a product like this built for both the students and the tutors.
FOR THE STUDENTS AND THE TUTORS
I needed to cater the product to the needs of both students looking for tutors and tutors looking for students in one single app. By separating the experience into two core feature sets, it meant that I could define user flows that worked for a variety of use cases.
For every feature, I would have to ask the question “Is this really needed?” When researching the needs of the student (through interviews and surveys in Typeform), I found that there were some features that were a necessity for the app. The problem in the market is that it is almost impossible to find the right tutor without asking a friend for advice. This meant that students needed solutions to that problem. They needed a way to find local tutors in the area for the subject they wanted to learn, and read reviews before deciding whether to book or not.
Tutors needed a way to manage their schedules, and be on a platform where they could be accessible to anyone. Another requirement that came from the research, was that tutors wanted to define if they were teaching to a single student or a group (such as computer software classes).
The requirements helped to shape the information architecture and made sure that all the important features were obvious and stood out.
WIREFRAMING, USER FLOWS & PLANNING
After giving priority to certain features and requirements, I moved onto wireframing and early user flows for different situations. These included scenarios such as “I want to find a piano teacher that can come to my place after work” or “My daughter loves dance at school and I want her to get lessons but we don’t have room at home”.
These different user goals allowed me to create a variety of different personas for the customers who would be using the product. This was done early on in the project so that wireframes could be designed with the existing knowledge of what the users wanted.
At this point, I utilised prototyping tools such as InVision to manage the flow of the wireframes and give a visual response to the needs of the user.
With the process of quick, prototype-driven iterations, I would get a sense of how some of these ideas were being used. Not only did it help to figure out what needed to be the focus, but it also helped to take away anything that compromised the most important features of the product.
The first thing a user would see when opening the app would be the login screens. This began with the most important question that would determine the experience the user would get, “are you a student or a tutor?” This would be changable from the user settings in the profile but was an important step to put at the front.
AN INTERFACE BUILT FOR THE USER
The user interface had to be structured so that the most important information would be at the front. This, for example, meant that the find a tutor section would be the home page for students, but the schedule would be the first page a tutor would see.
The process for find a tutor needed to be straightforward and completely focused around the question “what do you want to learn?” Further down the page would be information about local/featured teachers for those users just browsing, but the focal question would be the first thing a user would see.
Another challenge was how location would be displayed and how this information would be input by the user and at what stage. After wireframing, it seemed putting it right on the front page took up too much screen space and actually wasn’t a field that needed to be determined until the user was actually searching for a subject. This meant it was moved into the search feature as both would go hand in hand.
BOOKING A TUTOR
The process of making a booking needed to be simple and straightforward. Generally, after user interviews, it seemed that this was the most frustrating part of booking lessons. Schedules had to be managed, emails would be sent back and forth to decide on times, and how would students know if the teachers were any good? Apart from word-of-mouth (normally just from one person), there was no proof of the skills and capabilities of tutors.
The flow from a tutors profile page, right the way through to making a booking, needed to guide the user from a feeling of trust. It also needed to take away the pain points of organisation. The product would need to show the tutors schedule in an easy to understand way so that a booking could be make there and then.
FOR THE TUTORS
By reducing the amount of time needed for organisation, this would also have a huge impact on the tutors and how they would manage their schedule. By separating the experience into two user groups, it meant that the navigation could change and allow tutors to have access to everything they need to manage their clients.
Firstly, a tutor profile page needed to easily accessible to them so that they could edit this easily and quickly. From research, it was also clear that some tutors teach multiple subjects, so there needed to be an add a subject feature, so they could manage multiple profiles.
One of the most troublesome aspects for tutors (many who are self employed) was managing schedules and having an overview of earnings throughout the year. By giving the users these features, it would allow tutors to transfer every aspect of their organisation into the product, taking away the need for their own spreadsheets or diaries. Everything would be accessible from the app.
This would also be true for communicating with students. Without having to send emails back and forth (taking users away from the platform), a chat function was necessary for students/tutors to ask questions and provide more trust.