HackerHelper
In a month-long class project with a team of 2 UX researchers, I led the interface and interaction design for a help request ticketing system to faciliate communication between hackathon participants and mentors, ensuring hackers receive the guidance they need in a timely manner.
Team
Christina Raganit, Celine August Santoso, Gurnisha Rehal
My Roles
Product Design, User Interface Design, Interaction Design, Prototyping, Wireframing
Course
IAT 334 - Interface Design
Duration
July 2024 (1 month)
Mobile and desktop user interfaces for HackerHelper
My Role
As the user interface designer, my primary responsibilities were to build the interactive prototype for the desktop and mobile layouts of HackerHelper on Figma. To enforce consistency and improve my efficiency for prototyping, I built a library of reusable UI components (buttons, forms, inputs, etc.) in Figma that can be adapted for both desktop and mobile, complete with established typography styles, colors, and spacing values.
Check out some of the highlights belowI also worked alongside our UX researchers to visualize the user flows for both platforms, leveraging my previous background as a frontend developer to build layouts, screens, and interactions on Figma that were technically feasible and able to be implemented effectively. I continuously refined and improved the interactive prototypes based on user feedback and the results from user testing.
Check out some of the highlights below
What's a Hackathon?
A hackathon is an event where students create tech projects to solve challenges within a set time, like 24–72 hours.
As a computer science graduate who has had countless learning opportunities in hackathons, I sought to enhance the hackathon experience by first understanding the goals, behaviors, and needs of the kinds of people who are involved in these events—participants, mentors, and organizers.
Who's Who in a Hackathon?
Participants
Collaborate in teams with other participants to develop projects
Organizers
Students responsible for planning and managing the hackathon
Mentors
Experienced professionals who provide guidance and assistance to participants
Design Discovery
Exploring the hackathon domain to identify a problem we could solve
As an avid hackathon participant who has attended over 16 hackathons since the beginning of my academic journey, I could have created a solution based on my personal preferences. Instead, I made sure each design decision was based on data from user surveys, interviews, and usability testing.
In the process of exploring this domain, we surveyed a total of 34 organizers, participants, and mentors and interviewed 4 organizers, 2 participants, and 2 mentors. In each stage of the design process of this project, I made sure I was not designing for myself even though I am part of the target audience.
3
User groups surveyed
34
Survey participants
8
User interviewees
The Problem
The current system for requesting mentor help is error-prone, often resulting in unanswered requests.
Paint Point | 1
For large hackathons, high volumes of help requests can result in messages being unintentionally ignored or forgotten.
Mentors also struggle with identifying whether or not a hacker’s help request has been completed, further hindering them from providing efficient support.
Paint Point | 2
Hackers struggle to describe issues clearly and provide context to the problem they are facing.
Hackers, especially beginners, often find it difficult to articulate their problems and do not provide key information, which results in misunderstandings and delays in receiving effective help from mentors. This complicates mentors' ability to assess and address issues efficiently.
Paint Point | 3
If a mentor finds a request too complex, their attempts to locate a mentor who can help add further clutter to the message channels.
This increases the chances of hacker messages being unintentionally missed, ignored, or forgotten. Some mentors are also hesitant to communicate their inability to solve a problem because they are scared of seeming incompetent, which causes further delays for hackers hoping to receive guidance.
Paint Point | 4
Hackers are unable to provide feedback to mentors on their mentorship.
Hackers expressed that mentors who actively help and regularly check-in lead to a more positive hackathon experience. However, without a feedback system for mentors, when hackers receive inadequate support and mentorship, they cannot provide input to help mentors improve their skills. This is detrimental, as poor mentorship can deter hackers from participating in future hackathons.
What does this mean for mentors and hackers?
Hackers lose time
Delayed mentor assistance and lost requests causes frustration for hackers as they spend valuable time waiting for help.
Mentors get burnt out
Information overload on multiple requests complicates mentors’ ability to assess issues efficiently and find relevant requests.
Hackers get frustrated
Low mentorship quality or unresolved requests makes hackers feel unsupported and ignored.
Design Challenge
How might we effectively connect hackers facing challenges with suitable mentors to ensure they receive the proper support and guidance in a timely manner?
Our Solution
HackerHelper is a help request ticketing system to facilitate communication between hackers and mentors, ensuring hackers receive the guidance they need in a timely manner.
This web application is designed to be responsive on both desktop and mobile, allowing hackers to submit help requests from their laptops while mentors can view new requests on their mobile devices as they assist hackers around the venue.
Marley the Mentor and Hiccup the Hacker will be guiding us through how HackerHelper is used!
Step | 1
Hiccup gets stuck on a CSS problem and requires mentor assistance.
From our interviews with mentors, we discovered that hackers often struggle with describing their issues clearly and providing sufficient information when sending help requests, thus complicating mentors’ ability to efficiently address issues. The guided prompts ensure that Hiccup is providing information that mentors require to solve the problem the hacker is facing.
Hiccup the Hacker creates a help request on the HackerHelper platform.
Step | 2
Marley has some experience with CSS, so HackerHelper recommends Hiccup's request to Marley.
The current system in place for hackers to request help and mentors to review help requests sent by hackers is inconvenient and ineffective, delaying mentors from finding a request that matches their skillset.
HackerHelper recognizes that Marley has CSS experience and recommends Hiccup’s request. Our system uses skill-based filters, organizes requests by status, includes structured request details, and recommends requests to mentors based on skills, allowing Marley to evaluate the requests faster.
Marley the Mentor is recommended Hiccup's ticket because he's familiar with CSS.
Step | 3
Marley accepts the request, informs Hiccup that they are on their way, and heads for Hiccup’s location.
After accepting a request through HackerHelper, Marley can immediately notify and communicate directly with Hiccup within the comment section of the request.
This centralized collaboration makes it easier for Marley to locate the request in his dashboard and refer back to if needed. This feature prevents message clutter in the channel during status updates, reducing the chance of important messages being overlooked.
Marley the Mentor updates Hiccup on their status through the comments of the request in HackerHelper.
Step | 4
Unfortunately, Marley can’t solve the issue, but Sunny might be able to help! Marley refers Hiccup’s request to a new mentor.
HackerHelper allows Marley to refer Hiccup’s requests to another mentor—Sunny—by tagging her in the comment section and updating her on the issue. Unlike current platforms where flows end at a mentor taking on a request, HackerHelper anticipates situations where a mentor might be unfit, thus preventing hackers from missing out on the help they need to succeed.
Marley the Mentor uses the Refer a Mentor feature in HackerHelper to help Hiccup get the help they need.
Step | 5
Hiccup marks the request as complete and sees a dialog request for feedback.
Once Hiccup’s CSS problem is resolved, he can mark the request as complete, triggering a feedback pop-up for the newly assigned mentor, Sunny. During our initial research, we discovered that hackers are very unlikely to fill out long feedback surveys. Hence, we implemented a short feedback form that encourages hackers to send immediate feedback that can be completed quickly and efficiently.
Hiccup the Hacker is prompted to give feedback to Sunny.
Step | 6
Hiccup also decides to give feedback to Marley so he can improve.
Hiccup also decides to give feedback to his previous mentor, Marley, by using the message feedback feature. Our usability tests revealed that numerical ratings make mentors feel discouraged to mentor again, HackerHelper focuses on qualitative feedback that promotes a more valuable and supportive environment.
Hiccup the Hacker sends Marley mentor feedback from the Mentors tab in HackerHelper.
Reviews
What user testers are saying about HackerHelper
As a previous hacker and mentor, I think an app like HackerHelper would be really useful! It makes it much easier for hackers to connect with mentors, and for mentors to communicate with each other. This would be especially helpful in larger hackathons by keeping requests organized and clearly indicating which request is being worked on by which mentor. So overall, I would love to see this implemented for future hackathons."
Anonymous Mentor
User Tester
Learnings
This project was incredibly rewarding! What made this project even more special for me was the ability to work closely with SFU Surge, the student organization behind the largest hackathon at Simon Fraser University, to discover the pain points of individuals who are involved in the hackathon domain.
I gained valuable experience in interaction design and prototyping while working alongside two skilled UX researchers who provided deep insights into the discovery stage of the design process. Here are some key findings that I encountered during the process:
Learning | 1
Figma has significant limitations in prototyping, particularly for complex component behaviors.
For instance, it doesn’t allow user input, making it harder to gauge user testers' reactions to interactions like adding skills when signing up as a mentor for the first time. I hope to explore more prototyping tools that can better support these types of interactions.
Learning | 2
A development background makes a huge difference when designing interactions!
When a teammate suggested skill input through comma-separated values, I proposed an alternative based on previous experience developing a specific input method which I felt would be less error-prone. Users commended my suggestion for its ease of use during testing, and I was pleased to know my proposed interaction was technically achievable.