overview

tags
UX Design, Mobile, Web
time
Jan 29 - Feb 5, 2020
team
Individual design exercise
tools
Figma, Sketch, Lucidchart, Miro
design problem
My mentorship system lets freshmen approach and get help from upperclassmen, to adapt to Georgia Tech, by targeting two primary challenges.
design outcome
I designed the mobile version of a web application for mentees to find and invite mentors, as well as for mentors to fill their profile and deal with invitations.
Mentor: Registration

An onboarding process encouraging upperclassmen to present themselves to freshmen.
Mentee: Find and Invite a Mentor

Use filter, list, and detail info page, to find a mentor with best capability and motivation to help.
Mentor: Receive and Accept an Invitation

Get notified via SMS/Email, check invitation, and then decide whether to accept based on info of the potential mentee.

understanding

research
Since the essence of mentorship is about help, I firstly tried to identify students’ needs and problems in helping and getting help from other students. I interviewed:
4 users: a freshman, a sophomore, a senior and a first-year Master’s student
1 stakeholder: the director of an academic program at Georgia Tech

Based on interview notes and some domain research, I analyzed solutions currently available for students.
personas
I summarized motivators and demotivators of both sides in the situation that freshmen seek help from upperclassmen.
design objectives
To complement rather than replace current solutions for freshmen to get help in adapting to college life, I clarified the positioning of the new mentorship system, and derived major design objectives accordingly.

Now let’s talk about how I get Tom & Jerry matched, and kick off their relationship!
Here the story starts! Rock n Roll!

ideation

how to match?

1. What structure should the relationship have?

Since the mentorship system was specified between freshmen and upperclassmen, I made the assumption that Tom can only be a mentee, while Jerry can only be a mentor. Now the question is: How many mentors do we allow Tom? And how many mentees for Jerry?

After evaluating pros and cons of 4 alternatives, my decision was: Tom may have multiple mentors, while Jerry may also have multiple mentees.




2. What makes a good match?
Based on early-stage user interviews and analysis, it ultimately depends on mentors’ capability and motivation to help mentees.

As shown by Chart 1, I mapped all factors affecting Jerry’ capability or motivation as a mentor, and rated the priority of each factor based on these two dimensions. Jerry’ capability to help with certain topics depended on his: major, minor, career plans, class, skills, experience, organizations, courses, personality. And  Jerry would be motivated mostly by shared topics: shared hobbies, shared values, languages they both speak, same hometown, same high school, same ethnicity, same nationality, and mutual friends.

Based on Chart 1, I prioritized factors with enough impact on Jerry’s capability or motivation and mapped them on Chart 2, to evaluate their priority as well as feasibility. Feasibility measured how easy and comfortable it was for Jerry to provide the information to the system.

As a result, I sorted the priority of information needed as inputs from Jerry as: Major, Minor, Class, Career Plans, Courses, Languages, Organizations, Hobbies, Hometown. While as a mentee, Tom’s priorized information was a subset of mentor’s: Major, Languages, Hobbies, Hometown.

Considering the “N Mentors - N Mentees” structure mentioned above, it’s neither necessary nor feasible to ensure that every match is a perfect combination of all these dimensions. So how should I incorporate this info into the matching process?

To answer this, I had to figure out how the match should be initiated.




3. How to initiate the match?
Let’s assume a match between Tom & Jerry: Who should take the initiative to reach out and start the matching process?

The essential trade-off occurred between the info asymmetry as a con of A and the invitation overload as a con of B.
I decided on B over A since I found B easier to solve by design decisions. For info asymmetry, early-stage interviews have revealed freshmen’s difficulty in elaborating their own needs; and sometimes freshmen know what they want to ask only after knowing some upperclassmen. Therefore, it’s difficult to incorporate “My Needs for Mentors”/“My Expectations for Mentorship” as part of mentees’ profile.

While for potential invitation overload for mentors, solving it required me to figure out the detailed matching process.




4. How to maximize good matches while limiting mentors’ burdens?
As I’ve confirmed the general approach, I drafted an initial process flow for Tom to invite Jerry to be his mentor, and proposed 2 solutions for the invitation overload issue mentioned above, from both Tom’s and Jerry’s side.
I chose to limit invitations sent by Tom, since this would help Tom to be more thoughtful and responsible in sending the invitation, thus limiting invitations for mentors, and increasing “#Good Matches/#Total Invitations”.

Sounds good! But…

Now the limit could bring thoughtful and responsible invitations, while avoiding leaving the poor Tom with 5 declined/expired invitations without any chances to invite anyone else…

And of course, I decided to allow Jerry to respond to the expired invitation 10 days after Tom sent it. Since the expiration mechanism was to help Tom move on to more opportunities. If Jerry checked the invitation after 2 busy weeks of mid term and found out that Tom could be an ideal mentee, he should still be able to accept the invitation and strike a match!

Let’s look at a further concern: What if Jerry gets overwhelmed by too many paired mentees?

I proposed 3 solutions after updating the invitation process flow based on decisions described above.
I rejected option A, since early matches are not necessarily good matches. Option B was just too cruel…imagine what Tom would think if Jerry accepted his invitation first and then “unmatched” him? Option C seemed good so far. But, how should Tom kick off the contact? Solutions to this problem will be discussed in the “HOW TO KICK OFF?” part later. Before we even talk about that……

How would Tom find Jerry and decide to send the invitation? And how would Jerry decide to accept or decline?It’s essentially a “2-way selection”. Remember we talked about factors affecting mentors’ capability and motivation to help mentees? It’s time for mentors’ and mentees’ prioritized info to join the game!

For Tom to find Jerry among hundreds of potential mentors and make the decision to invite Jerry, I proposed 5 methods to incorporate Jerry’s info into Tom’s selection and listed info suitable for each method. I then rejected the 2 methods which barely fit any variable.

Once Tom invited Jerry, the only job for Jerry would be checking the invitation and deciding to accept or decline based on Tom’s info. Also, info flowing from Tom to Jerry would be way less than the other way, since freshmen had no minor, courses, or student organizations to tell. Even if they did, these variables would barely affect Jerry’s motivation to help them. As a result, I decided to show Jerry Tom’s name, photo, major, hometown, languages and hobbies in both the invitation list and the detail page.
how to kick off?
I proposed “Limit the time for mentees to initiate the contact after being accepted” without specifying the method of kicking-off, and now it’s the time for that missing puzzle piece!

I proposed two major alternatives for Tom to reach out to Jerry after being accepted as a mentee. Based on their pros and cons derived from user interview notes, I decided to leverage common communication tools instead of building a new communication tool specific to the mentorship system.

Another thing to consider was: After Jerry received the system notification of Tom’s invitation via SMS/Email, in what way he would deal with it?

I made the design decision as: Embed a link into the SMS/Email sent to Jerry from the system, and let Jerry log into the system by clicking the link. I rejected ideas of responding to invitations by replying to the SMS/Email, or embedding a 1-time link without authentication, due to concerns of privacy and security.

wireframing


I decided to prioritize mobile over desktop,
since early-stage interviews implied that both Tom and Jerry were more likely to interact with the system on mobile, during small chunks of leisure time. And it wouldn’t be hard to design the desktop version based on the mobile version.

Regarding mobile, I decided to make it a web app, not a native app. Although a native app allowed larger flexibility in design, user interviews reflected that Tom wouldn’t want to install another app only to find mentors and send invitations once per week, neither would Jerry want to install another app only to accept/decline invitations when receiving SMS/Email notifications.

Based on decisions made in the ideation stage, I drafted the complete process flow of Tom inviting Jerry to be his mentor, and sketched wireframes for 3 key parts in the process.
1. mentor: registration
I designed an onboarding process to encourage Jerry to let potential mentees know him as much as possible. Some info can be auto-filled based on the student database of Georgia Tech, such as: name, major, minor, class, courses taken.

I didn’t design the registration process for Tom, since mentees’ info to fill would just be a subset of mentors’.
2. mentee: find and invite a mentor
3. mentor: receive and accept an invitation

iteration


Without time and budget for formal user testing, I just invited 4 users to walk through my wireframes and asked for their feedback, and iterated different parts of my wireframes acccordingly.
mentor & mentee: login
Change: I replaced the duo entries with one single entry following the authentication template of Georgia Tech.
Why: “I have to go through this layer of selection? A freshman can only be a mentee, while an upperclassman can only be a mentor. The system should know where to lead me.
mentor: registration

1. How to simplify and justify the process?
Change A: I removed “Skills”.
Why:
-“This should depend on disciplines and careers. Not necessary to stand alone.”
-“If it’s for technical help, then it’s unsuitable for the positioning of this mentorship.”

Change B: I integrated 9 steps into 4 steps
Why:
-“9 steps freak me out. I would prefer less steps with the same amount of input integrated.”
-“Why should I even provide this info? Classifying them into some categories might make them look more meaningful and reasonable.”




2. How to signify and control the onboarding progress better?
User feedback driving iterations were summarized with grey annotations, while changes I made accordingly were summarized with blue annotations.




3. How to encourage showing courses while mitigating privacy concerns?
mentee: find and invite a mentor

1. How to make the filter comprehensive yet simple?
Change: I added one extra layer of selection for filter items, and better hierarchy to organize options.
Why:
-“I hate squeezing only these 3 items into this single page.”
-“Why only these? What if I wanna filter by hobbies?”




2. How to better present profile info of mentors?
Change: I created and iterated the info architecture based on mentees’ mental model.
Why:
-“It’s such a huge long list. I wanna be able to collapse some content.”
-“VIEW ALL is confusing. And it becomes redundant if Courses Taken can be folded under Academic.”




3. How to tell potential mentors a bit more about oneself?
“Mentees can only show their major, hometown, languages and hobbies. Should be a chance to add something personal.”




4. How to present profiles saved and invitations sent?
Change 1: I broke MY MENTORS into 2 tabs to separate SAVED from INVITATIONS.
Why:
-“It’s kinda weird to categorize saved profiles into MY MENTORS...There’s no commitment in saving a profile, right?”
-“Might be easier to understand the function of saving a profile if there’s a tab for this.”

Change 2: I added time info to invitation status.
Why:
-“An invitation sent 1 hr ago VS an invitation sent 5 days ago are totally different stories.”
-“It helps to highlight updates in invitation statuses with some labels like NEW.”

But I met a challenge from: How to organize invitations already sent?
Why:
-“Kinda annoying if declined/expired invitations pile up here.”

outcome

mentor: registration
mentee: find and invite a mentor
mentor: receive and accept an invitation
challenges
1. Working alone on a design exercise for the first time helped me reflect on the difference between teamwork and individual work. First, I tried for MECE (mutually exclusive & collectively exhaustive) for each branch in my decision tree, but it’s difficult for one brain to exhaust alternatives in a space. Also, without teammates’ disagreements which push me to find justifications for my opinions, I had to force myself to think harder instead of going for the “obvious” or “easy” way.

2. Due to limited time, many of my assumptions and decisions lacked quantitative back-up. Limitations regarding numbers and days were especially arbitrary.
next steps
1. In-person contact between mentors and mentees: There is more to explore in facilitating such contacts beyond the system. E.g. a university-wide offline event dedicated to the mentorship program.

2. Quantitative validation: Most of my assumptions and decisions are inspired by user interviews. It will be better to validate them with more time and larger samples, perhaps via a user survey.

3. Design evaluation: Walking users thru wireframes for feedback is far from enough. User testing is needed for evaluating usability as well as knowing users’ acceptance for sharing certain info in such a system.
acknowledgement
1. Individual work is never easy. I’m grateful for everyone supporting me with interviews and design feedback sessions!

2. It’s the first time I try to present a project with a storytelling approach. Thanks to Tom and Jerry, my childhood memory which inspired this idea!
The REAL Tom and Jerry……
Georgia Tech Printing  /  College Mentorship  /  GaTech College of Computing Website
Tencent Internship  /  Research Dashboard  /  Vis Beans