Recruitment season for Columbia's student organizations at the beginning of each semester can be extremely hectic. How can we lighten that headache?
October - December 2022
Product and UX/UI Designer, Interaction Designer
Kimberly Tsao, Evan Li (Developers)
Every year, hundreds of Columbia’s student clubs undergo an extensive form of recruitment process for new members. This can result in hundreds of applicants, multiple interview rounds and deliberation processes, and way too many folders and spreadsheets to manage. Specifically tailored to helping Columbia’s largest clubs mitigate these headaches, ColumbiaClubApps is a platform that allows users to efficiently view, sort, filter, and manage applicants for an accelerated and organized recruitment cycle.
While there are ample resources to help students find the clubs they are interested in, there are far fewer resources that help lighten the logistical headache for these clubs' board members. Ensuring that every application is accounted for can be an emotionally draining nightmare during the peak of recruitment season. Even before conducting specific contextual inquiries or talking to potential users, I identified 3 original problems that persisted in the club recruitment space.
The sheer number of applicants can be overwhelming. Popular undergraduate pre-professional clubs receive 100+ applications every semester.
Many clubs manually created documents and spreadsheets for keeping track of applicants between interview rounds. This leads to a lot of room for manual error and accidental deletion of relevant data.
With no more than a week or two to manage what is sometimes multiple rounds of interviews, the recruitment process can often be fast-paced, time consuming, and both mentally and physically draining.
Through some contextual studies and conversations with current club leadership, I was able to get a better idea of what a detailed application process actually looks like. For a standard finance club or popular pre-professional club, there are typically at least 5 different steps in the process—and that's not accounting for multiple rounds of interviews.
From information sessions that sometimes require attendance in order to receive an application to informal social mixers that spark interest, it's often helpful to spot keen applicants early on.
Usually a Google form. Not the most difficult in terms of tracking the data, but transferring the knowledge can sometimes be a handful.
Different things to consider include logistics for interview times for applicants and booking spaces, as well as consistently taking notes as different board members often speak to different candidates in order to save time. Lots of room for error here.
Board members will often sit down together to review applicants and try to build out the intended roster of new members. During this step, there's typically a scramble to find the correct interview notes or other forms of disorganized chatter based on everyone's opinion.
Seems like a simple email but can be just as manual error-prone. At least 2 clubs we spoke to recounted situations where acceptance emails were either sent to the incorrect people, or not at all.
For privacy's sake, all personal information has been redacted, but the images have not otherwise been altered in any way. That being said, it's obvious even with a quick glance that club recruitment currently requires multiple folders, spreadsheets with up to hundreds of entries of data, and numerous forms and email correspondences to review.
Most students who are actively applying to clubs are. Older students (juniors, seniors) occasionally apply to new clubs, but upperclassmen usually only apply to more casual hobby-based clubs that don’t have a super extensive application process.
"I don’t know if I should be looking for updates on Facebook or Instagram or the club’s website.” “I’m not sure where each club posts their most up-to-date information."
Applicants find that using Google Forms and email communication to submit applications was manageable. Even if one applicant had multiple applications to submit, it was usually convenient enough as they were already familiar with the interface.
On top of using Google Workspace applications for management (eg. Google Docs, Google Sheets, Google Forms), there are other platforms that many companies currently use to manage recruitment and HR, such as Greenhouse and Workday. These platforms offer recruiters features to create job postings, analyze applicants, give applicants scores, and more. That said, no existing platform completely fulfilled our potential users’ needs.
We then synthesized our conversations and identified the top priorities for our design solution. We wanted to design a platform that focused on making the applicant review process more streamlined and efficient. As well, we wanted to handle deliberations between rounds of interviews and identify the applicant information fields that were most important to club administration.
Ultimately, we devised four key pillars: Visibility, Organization, Manipulation, and Aggregation.
Given the scope of our project, our course mentor suggested that we begin by focusing on either the administration or applicant side in order to prevent our team from spreading ourselves too thin. The general flow for our design solution is pictured above. While all screens were addressed at the lofi stage, we decided to ultimately prioritize the features highlighted in dark blue for our final design.
I created rough sketches of all the features for context. As we pivoted to focus on our two most important pages, the applicant dashboard and individual applicant profile, we revisited our user interviews. Since many clubs already use a table layout with one horizontal row for each candidate, we decided to follow a similar style to maintain consistency.
When managing large volumes of applicant data, design elements needed to be modular, flexible, and consistent.
With these qualities in mind, I visualized the layout for an expandable row element that would achieve the core functionality of our applicant dashboard.
One piece of feedback we received from our design mentor was that some elements of our interface, especially our applicant dashboard, currently appeared to be a little busy. As such, I began to tackle this by incorporating visual design and colour in Figma. In the first three iterations of the dashboard design, I focused on trying to find the best layout and features that our users would prioritize.
I designed a menu to the very left of the dashboard that would allow users to quickly view different categories or groups of applicants.
Our initial intention was for users to be able to sort and archive rejected applicants while also creating new groups in the case of multiple rounds of interviews. However, upon further testing, our users notified us that they did not see many realistic use cases for creating new groups.
This version kept all the applicant entries as a centered modal.
With the “New Action” button placed on the top right side of the page, any drop-downs from the button would overlap with the database.
Users I spoke to agreed that Version C was the most effective in spatial organization.
One piece of feedback we received from our design mentor was that some elements of our interface, especially our applicant dashboard, currently appeared to be a little busy. As such, I began to tackle this by incorporating visual design and colour in Figma. In the first three iterations of the dashboard design, I focused on trying to find the best layout and features that our users would prioritize.
In existing solutions, club administration often used color-coding to determine deliberation status. In order to increase familiarity, I decided to use similar red-yellow-green color schemes to highlight an applicant's status.
I wanted to design interactions that made selected applicants visually distinct.
Before even clicking into an applicant's entire profile, there were certain elements that were deemed important based on observations on what types of content club leaders really looked for.
I also implemented a feature that allows the user to categorize applicants by whether or not they have been interviewed in the current round, as well as a drop-down menu that would allow users to toggle views of the applicant pool between multiple previous rounds of interviews.
As well, I began to create iterations of designs for how specific information for each individual applicant’s profile would be displayed. The most important information to display consisted of access to uploaded documents, basic information, application responses, and interview feedback. Due to engineering and time constraints, I chose to keep the layout fairly straightforward.
As we moved into finalizing our high fidelity designs and animating our prototypes, I also built a design library in Figma that documented the important design assets within our interface. This made it easier to later implement our designs as code.
After various rounds of testing, we produced our first complete high-fidelity design of our applicant dashboard and individual applicant screen! The specific features are as follows.
While we completed some testing and feedback using a design with real applicant information from one of the clubs we interviewed, user profiles were modified to fictional applicants for privacy reasons.
Users can choose either to log in as a club administrator or student applicant. For convenience, users may also sign in with their Google or associated school accounts.
When reviewing applicants, club administrators may select some or all of the applicants for aggregate actions such as sending a wave of acceptance and rejection emails.
Each applicant has a status tag associated with their profile. From the dashboard, users will be able to directly manipulate these status tags and quickly discern an applicant's current deliberation status.
The dashboard’s default fields of information that are displayed include applicant name, school (college within Columbia), graduation year, deliberation status, and whether they have been interviewed yet this round. Users may click on the field titles to sort applicants in chronological (default) or ascending/descending alphabetical order.
Users can also filter by certain fields on the dashboard to selectively view applicants with specific qualities. For example, the filter function allows administrators to quickly only view applicants from a certain school or graduation year.
Users can search by key words to yield specific applicant results. For example, the GIF here showcases searches for applicant names related to “Bear” and “Ice Bear.”
From the dashboard, users can click on applicant entries to see more information. Users can also navigate to the individual applicant page to read an applicant’s responses or view their interview notes.
After selecting multiple applicants whose status tags have been changed to “accepted,” users can click the “New Action” and send out an acceptance email based on a previously uploaded template to the selected users.
Whether it is between rounds or for the final deliberation details, users can select rejected applicants and send multiple applicants a rejection email. After being “dropped,” these applicants’ profiles will be automatically moved to the “archived applicants” section at the bottom of the dashboard.
This was a feature suggested by our design mentor! With the between-rounds feature, users can also view snapshots of the applicant pools during previous rounds for applications that require multiple interviews.
Some also offered their opinions on next steps.
By the time I completed most of these designs, many clubs had completed recruitment. Although the context they provided was still valuable, it would've been helpful to directly run A/B tests during the recruiting cycle to measure the platform's efficiency and track how much time is saved from the busy work.
Certain suggestions we received included designing features to handle demonstrated interest tracking, sorting ability based on multiple fields, additional interview scheduling, and automatic diversity statistic calculations at the end of every round.
We converted our designs to code using HTML/CSS, Flask, and React, but our next steps would be to continue perfecting the implementation.
While Columbia Club Apps is hyper-specific to, well, the Columbia campus, we're glad we decided to go this route. This project taught me a lot about how to work with users, make observations, and understand context for a real problem happening around me. After all, even Khan Academy started as an attempt to help one child get better results on her school grades!
After incorporating extensive naming and labeling conventions in Figma, we found it much easier to collaborate on our code implementation while referring to the design file.
Critiques can seem scary, but are usually so valuable. The best insights and breakthroughs often come from real user tests, especially when you've been working on a project for so long you find yourself completely biased to a certain aspect.
