Problem
Peer learning has been known to show improvements in students’ learning processes, but traditional learning methods fail to emphasize this interaction enough. Moreover, many college students aim to gain a breadth of skills not directly related to academics, but there is no existing convenient or affordable learning solution for them to do so.
Why is this a problem?
The danger of traditional testing or teacher intervention is the pressure associated with it, which in turn can hinder learning. According to How People Learn:
“People often learn most effectively when there is no external pressure to improve and no feedback or reward other than pure satisfaction.”
In addition, in person, peer learning can be more comfortable for students and make learning more enjoyable. According to Peer Learning in Higher Education, students naturally gravitate to other students instead of teachers when asking for help. The reason for this may be an elimination of a hierarchy.
Understanding Current Interventions
I spoke with a few users, and conducted a survey to gather the most common learning platforms that were mentioned. I also asked a few questions on what users thought the shortcomings of these platforms were. Common responses for roadblocks included cost, time, and self-motivation. 
Competitive Analysis
I conducted competitive analysis with the same learning platforms that users mentioned they use from a survey. 
What did I learn?
1. None of the platforms students mentioned as popular emphasize accountability in learning. A high amount of self-discipline is needed in order to utilize the resources. 
2. The platforms encourage course purchases, but not course completion
3. The platforms commonly have a cost associated with premium content. 
4. For platforms with an online community, it is often so large that making meaningful, long-term connections is difficult.
5. The options have either no timing requirement at all, or very rigid timings
Ideation
I brainstormed 8 possible solutions to address the problem, without worrying so much about feasibility just yet. Rather, I concentrated on quantity and tried not to limit ideas to constraints. The sketches are shown below:
Storyboarding & Scoping
After gathering each of the 8 solutions above, I eliminated 3 solutions when considering feasibility, target audience, and scope. Then, I fleshed out the remaining 5 solutions in a storyboard sequence to show the context of which the solution may be used in. 
Each of the 5 solutions has an 8-panel vertical strip, shown below:
How did storyboarding inform my direction?
By storyboarding for 8 different solutions, I began to understand the plausibility of some of the solutions. 
If the origin story was hard to come up with, I realized that maybe this was not the best solution. The storyboards that dealt with interception (presenting the user with an opportunity from their normal daily activities) were easiest to create.
User Interviews 
After deciding my focused design approach, I conducted one-on-one interviews with 4 users, and then conducted a focus group style interview with 3 users at once. I structured my questions by asking about specific past instances and experiences students have had with learning. I did not want to just capture their use of online sites for learning, but I wanted to capture the socialization aspect of learning. I hid my solutions within these questions as to not explicitly ask the user which solution is preferable.
For example, one of my possible solutions was a peer discussion forum. I asked users the question, Have you been in a class where there was an open discussion forum? I then followed up with, Can you describe that experience? This question allowed me to understand how students felt about the helpfulness of peer discussion forums. 
An excerpt of my interview script is below:

Excerpt of interview script.

What did I take away from the interviews?
The interviews allowed me to discover user needs and frustrations with current processes. 
1. Users need a system with quick response time
One of my interviewees mentioned, 
“I use Piazza to post and answer questions, which is a peer discussion forum. But I just feel like it takes forever to get a response and I’m too impatient for that."
2. Users need learning tailored to their preferred method. 
"If I’m working on an assignment and can’t figure the issue out, I want an answer now that is specific to me.” 
3. Users have difficulty with clubs due to differences in skill level, location, and simply not having anything in common with the members. 
4. Users stated that clubs or groups did not motivate them as much as a one-on-one session. Users stated that the fact that there were so many people made it easier to drop out. 
5. Users valued learning experiences that were close by
6. Users prefer a solution where they do not have to pay, as cost can be a deterrence. 
7. Users like to build friendships from a learning or professional setting. 
8. Users need flexibility in the timing and time commitment of learning.
9. Users all seemed to have things they wanted to learn, but finding the motivation could be difficult. 
10. Users are cautious when investing time into an activity. 
“I always read reviews on Udemy before buying a course to see if the professor gets good ratings.” 
Personas
From the user interviews, I was able to generate personas for the archetypal users:

One of the personas assembled for this project.

What did personas achieve?
Three personas clearly identified user needs and frustrations, and the last anti-persona outlined the kind of user that I was not designing for. 
This allowed me to summarize my interview findings in a visual, structured manner so I had a rough idea for continuation. 
Solution Identification
The user interviews allowed me to see that mobile application that matches users for skill exchange would address the most user needs. I came to this conclusion due to the answers I received about peer discussion forums, notes, and campus postings. I consistently got answers which showed that while these solutions could be helpful and are certainly better than nothing, they were not quick enough or personalized enough. 
The mobile application would emphasize mutual and peer learning, and users could be matched on criteria such as interest, ratings, location, time commitment, and other important factors. 
For instance, if Student A has design expertise and is interested in coding, while Student B has coding expertise and is interested in design, Student A and B would be paired. 
These users could then meet in person to have skill-sharing sessions:
Key Features
Based on the personas, I decided on key features the application should have:
User pairing
Many users emphasized the importance of the one-on-one interaction.
Skill selection
Users should be able to select what skills they’re interested in learning so that information related to this can be curated. 
Recommended skills
After a user completes a match-based interaction with another user, there should be an avenue for the user to stay on the app and continue looking for more skills. A recommended skills list will guide the user for where to go next
Safety tips
Meeting strangers or people one is less familiar with can be associated with risks. Users should be given tips to avoid unsafe situations. 
Robust user profiles with tags, pictures, etc.
Users should be able to feel safe and construct a good idea of the person they are meeting through profiles. With detailed information, users can glean more about the person they will be matching with. 
Rating or endorsement system
This stops against no-shows, abuse of the application for monetization, and other potential issues. It also motivates users to teach effectively so that they are rated highly and endorsed for skills.
Time-associated commitment
Many students may have differences on what constitutes a good time commitment per week. Thus, they can indicate preferred minimum and maximum time commitments and filter by this condition.
In-application messaging
Users may feel uncomfortable giving out personal phone numbers during initial meetings with their match. This is reasonable, so in-app messaging makes this process smoother. Not only this, it encourages users to message each other more and interact more. 
QOC Design Defense
One of the most critical features of the application is the user pairing process. This will inform the rest of the user's experience, since if the user is not paired well, the sharing of skills will be ineffective. Therefore, I had the question of how users should be paired to exchange skills. From this question, I created a QOC (questions, options, criteria) diagram to evaluate options.
What did QOC tell me?
Based on positive and negative assessment on the criteria, the process that matches users based on both location and social media accounts (i.e. mutual friends) was the optimal option. This gave me direction on how I should link people.
Low Fidelity Prototyping
After understanding the desired features and approaches of the application, I created a low-fidelity paper prototype with key interactions. 
I tested this prototype by assigning users a variety of tasks to complete. When the users got confused or stuck, I asked them to think aloud so that I could better understand where the breakdowns in the process were occurring. 
What did paper prototyping reveal?
I iterated upon my prototype after receiving user feedback on the following features:
1. The standardized navigation bar. I have a section for “me,” “matches” and “messages.” A user described the “matches” section as ambiguous, since the user was unsure whether “matches” meant a way to find more matches or view existing matches. 
2. Process of choosing interests and skills. Users often forget what they can do, and one user mentioned how it would be hard for her to think of skills she has on the spot. When I asked her prompting questions like, “What languages do you know? Do you play an instrument?”, she was better equipped to make these choices. 
3. Matches and messages sections. Within messages, one can view the matches already. Having both confused some users.  
4. The “add friend” button. User were confused on the difference between becoming friends and matching, and the difference is not clear. From this, I determined I could remove the "add friend" functionality. 
5. Tour screens. One user suggested that instead of having the tour screens all at the beginning, which the user would likely forget, they can show up as needed in a more "on-demand" fashion. 
High Fidelity Prototype
Some initial screen designs and interactions are below. 
Onboarding
Profile Creation
Match Discovery
Sample Interaction
Learnings
Following this project from start to finish  really made me understand the idea of failing often and failing fast. The more iteration I was able to do, the better my product became. I also understood the importance of gaining an understanding for the real problem rather than just jumping to a technological intervention or solution. While a mobile app turned out to be the most reasonable solution for the issue I posed, this is not always the case - not all issues will be able to be solved by some web or mobile app. 
.   .   .
Back to Top