With Grasp, you can get any homework or class question answered on demand through peer-to-peer help, either in person or remotely.
I led the interaction, web design, and visual design. The two engineering co-founders developed the native app and backend servers. I worked closely with the engineer at Penn to map out potential user flows, wireframes, prototyping and beta testing for user feedback.
At a high level, help provide a solution for student's that's free, yet tutors get paid. At a low level, designing and implementing an efficient solution at scale for a two sided marketplace, and considering how to best measure offline activity.
College is tough, but finding help when you need it shouldn't be. At the University of Pennsylvania, tutoring services must be scheduled ahead of time through the Penn tutoring center, which only offers select times. As a student, however, no one plans on encountering an issue in, for example, a line of code, or a math problem. And while classes at Penn are hard, finding tutoring when you need it shouldn’t be.
Our research group consisted of students between the ages of 19 and 22 that attended UPenn.
Students are most likely to use online resources and friends. They view tutoring services as providing help for students that really need major concept help, as opposed to smaller, perhaps more technical questions on a problem set.
Students procrastinate. A lot. According to the Penn student development coordinator, she received over 45 emails the night before the MATH 103 (Introduction to Calculus) midterm regarding tutoring. This happens over and over again, year after year.
Students that have used Penn's tutoring service find the experience of signing up frustrating The software Penn uses is clunky, and provides no insight as to who is helping and what kinds of experience they have.
One of the greatest frustrations students face is that the tutoring service offered through Penn must be scheduled ahead of time, and is only offered at fixed times from 6-10pm. Often times, students feel the frustration of being stuck on a problem set, according to some undergraduate engineers we interviewed, for an extended period of time if they can't get the help they need as soon as possible.
By aggregating our user research results, we ideated a variety of potential solutions to solve this problem. This involved focusing on the core value that we would deliver to our customers. For students, this meant delivering convenience, ease of use, speed and reliability. For tutors, this meant providing extra opportunities to tutor students and get paid, but not at the expense of convenience. For professors/administrations, this meant providing real-time data on the kinds of topics their students need help on, as well as the frequency of requests.
We originally planned on going B2C, but after some consideration, we believed that this was the wrong approach for a variety of reasons.
Students don't want to pay for on demand tutoring. Our users told us that they would not pay for tutoring when it's provided free on campus, or when they can ask their friends or find help online.
Recruiting tutors would be difficult. We would have to manually approve each student that wants to tutor, which would be extremely difficult at scale.
If students did pay, we would be taking a commission fee. We'd be making pennies on the dollar.
Furthermore, we are also providing a lot of value to professors - we collect information from students including subjects, courses, and frequency of requests that can be transferred to professors via an admin portal in real time.
I began by sketching out potential user flows to gain a better understanding of how our users might address their own pain points. There were many, many ideas and possible iterations that we tested on our peers, which ultimately led us to the most recent one:
We mapped out potential userflows to explore logical steps for users to take to accomplish their goals and to relieve their pains. By starting with the circles on both ends (starting states, end states) it allowed us to clearly see the relationship between the problem and the solution we were developing. For students, this meant providing a platform for them to filter and find tutors near them with expertise in their subjects quickly and effortlessly. For tutors, this meant providing them with a simple platform that allows them to make some money without actively searching.
We implemented an onboarding process for both students and tutors to visually demonstrate to users how easy it is to request/provide help. It also helps convey \ the linear relationship between being stuck on a problem to getting help quickly via our app.
From a branding perspective, the illustrations also allows us to speak to a younger, college-aged demographic.
One of the most iterative processes in designing this was creating the steps the users took to enter in the information. We did quite a bit of user testing here to understand how users reacted upon first seeing these iterations. A positive response would most likely warrant a higher conversion rate, which is especially important when users are already in a negative/frustrated mindset when searching for help.
Our users enjoyed the first the most and disliked the third because it felt "formy", and led to cognitive overload.
We ultimately decided to blend the first and the second.
Forms yield a low conversion rate, and when you couple that with students that are frustrated, it becomes critical to provide user feedback each step of the way.
The progress bar provides immediate feedback of what still needs to be filled out, and once a form field is filled, a green check mark appears to confirm with users. We believe this design will yield the highest conversion rate.
Liability and safety is one of our number one concerns. What happens if it's the night before an exam, and a girl needs help at 11pm in her dorm room and doesn't want a stranger to come over and doesn't want to leave? By providing them with a remote tutoring option via Skype, we attempt to solve this particular use case and seek to increase safety.
We designed around this challenge by allowing students to cancel the sessoin if it hasn't started, which then queries them to submit a reason why they cancelled.
By allowing users to view a map with their own location as well as their tutor's, it allows students to better visualize how long a tutor might take to arrive, especially given that students know the campus pretty well. We also decided to provide reviews of tutors, toggled when users swipe the bottom bar up or tap the vertical ellipses on the right.
We also strategically made it difficult for students to cancel, first with a full profile swipe interaction, then hold interaction, then interacting with a modal window. This was to a) prevent accidents and to b) minimize students second guessing their need for help.
We decided to create a larger, more blatant notifcation once tutors arrived within 100 meters of the student's location. The notification prompts the student to get in contact with the tutor; the same notification appears on a similar map screen for tutors once they're close.
We only allow tutors to start the timers to minimize error. The student can see the amount of time that has elapsed in their session. If there has been a mistake, such as a tutor starting the session too early, the student can cancel it for quality assurance.
We implemented a review/rating system after users described to us the importance of quality tutoring sessions. Because we're using an existing base of tutors through the Penn Tutoring Center, we were not worried about the quality of tutoring, but to provide students with as much information as possible, we decided that implementing a simple review system would be in the best interest of the students. We iterated through a couple of possibilities for the review system.
Furthermore, when we tested this idea out on users, they thought the binary system was a bit too mean, even if it was the honest truth.
Obtain feedback from users earlier. We didn't obtain that much feedback while we were designing; instead, I would do a design sprint, then test, as opposed to testing during sprints, which made our workflow longer and less efficient.
Build natively right off the bat. We thought taking the React Native route would be a good route, but it proved to provide us with a lot of engineering challenges, primarily with screen lag and difficulty of implementing swipe gestures. Now we're redoing it in Swift and Java.
Approached talking to Penn (and other schools) sooner, possibly even before we built the app. It would've saved us a great deal of time working with the school early on, which also would have helped us with what we should be designing for them. I'm currently designing out an admin panel/dashboard for them to view the data.