KRAM pairs students with tutors, within the same university, on demand.
Tutors on KRAM earn money, while students get the help
they need to ace that upcoming exam. It's win-win.
I was approached by Danny and his team to design the interface for KRAM, and solve any UX related challenges along the way. The timeline was an urgent 2 weeks, but the results turned out nicely.
Danny already had mockups prepared on Balsamiq and a clear vision of the app's functionalities. Having these two things prepared really helped kick off this project smoothly.
Prototyping and Feedback
For prototyping I highly recommend using InVision. I can probably write an entire blog post on why its such a great tool, but to keep things short, its an amazing platform to present designs and collect feedback. In week 1 I had all the screen designs ready and was able to gather valuable feedback from the client and developers. Its a good idea communicate with developers early on in the design process, so that you can create your designs around any potential engineering issues.
Log In/Sign Up Screen
I kept the Log In/Sign Up screen fairly straightforward. Just a quick UX tip, its better to use "Log In" over "Sign In" because the wording would otherwise be too close to "Sign Up" which may be confusing to users.
Sign Up Flow
The Sign Up screen only asks for key information (in fact, Male/Female could be left out as well) to get the users within the app quickly. Depending on whether or not the user checks off to register as a Tutor, they are either taken to the Tutor onboarding or straight to the main screen of the app. Since Tutor onboarding requires a bit more work from the user, I included a Skip button to reduce bounce rate. On the main screen the student receives a friendly reminder to include billing information (left out of the sign up flow to keep things simple) or to complete their Tutor profile.
This was probably the most challenging screen to design. Basically Tutors on KRAM have to set their availability, which usually varies each day of the week. Asking the user to set their timeslots for all 7 days of the week is quite a lot of work, so the Availability screen had to be as clean as possible.
My first iteration (greyed out) was way too overwhelming. The idea was that all time slots of the week are shown (from 8am-10pm) on a single screen and the Tutor simply clicks on the times they are available. But seeing so many numbers on a single screen was a bit too much.
My next iteration separates the Availability settings into two screens. The first screen is the weekly view, which then branches into a specific day. On the Day screen the user can set their timeslots on a 24 hour basis (because hey, some people may need tutors at 2am) or copy the schedule from a previous day, which saves them some time.