back another project

StartupTree Competitions

StartupTree, Product Design Intern

Summer 2017

Researched and designed a module for creating, managing, entering, and judging applications and competitions within the StartupTree platform.

While I was a Product Designer for StartupTree, a platform for managing entrepreneurship on college campuses, we discovered a need for college entrepreneurship programs to run competitions, and more generally collect applications for things like job postings.

For the purpose of this case study, we focused on helping administrators of college entrepreneurship programs run competitions. I generally refer to the module as the "Applications module" to reference the broader scope.

The Problem

We interviewed an administrator at Harvard Business School to discuss how they ran competitions and their current challenges and pain points with existing platforms and systems.

Notes from our interview with the Harvard Business School's entrepreneurship program director

The StartupTree CEO is also the director of eHub (the physical entrepreneurial space) at Cornell, and served as another important resource in understanding the needs of other administrators of similar programs.

We discovered that schools host entrepreneurship competitions, but need to use a variety of tools on multiple platforms to run them. Currently, there is no centralized platform to manage these competitions.

Entrepreneurship administrators have to use a variety of platforms and mediums to run competitions, end to end

Their largest pain point was the judging flow. At HBS, they had used a competing platform for 2 years, but the system crashed, and they had to revert to their previous paper rubrics.

Secondarily, startups, student organizations, and independent projects can recruit on StartupTree, so during the process we wanted to create something that would be able to collect applications for this use case as well.

The User(s!)

We identified 3 kinds of users for this module:

  1. the administrators
  2. the judges
  3. the applicants

Our focus would be on the first two users identified, due to time constraints. We had a very rudimentary version of the applicant flow built that would only need to be upgraded minimally. However, we wanted to upgrade existing systems so the administrator to gain a lot of functionality and freedom, and we would be building the judge flow from scratch.

The Admin

Typical administrators are faculty members of entrepreneurship programs at universities who are already familiar with the StartupTree platform. They're looking for ways to better facilitate the application process for competitions specifically and in general.

A typical administrator.

The basic workflow for an admin user involves creating and managing the event, the application questions, and the judging. Throughout, they need to be able to monitor progress at each step and make changes on the fly.

The admin workflow. At the end of a round, they might need to repeat the entire process again.

Armed with the information we had gathered from our interviews with Harvard Business School

Some messy notes, sketches, and flows from my notebook. If only I had remembered to document the neater planning sessions! Rookie mistake.

Admins needed a central location to navigate through the process of managing a competition, so we created a dashboard that serves as a pivot point into the rest of the managing flow. While designing this module, I also planned on redesigning many other views for admin users, so this dashboard needed to be scalable and applicable to other StartupTree modules. The majority of the information for these dashboards can be pulled from existing user profiles.

An administrator's central dashboard for each competition. While visually very clean, if I could revisit this project I think re-exploring the navigation would allow for better user experience. I think this is missing callouts for the "bigger" actions.

Creation of each application needed to be broken down into smaller pieces. Admins often do not have all the details of the event upfront upon creation. They may first add the most crucial information — the event details about time, deadline, etc. — then create the application questions for applicants, and add rubrics and judges last. Giving administrators flexibility and keeping these pieces independent from each other allow admins to work asynchronously and allows for better error recovery.

Breaking up the creation process of an application into four steps, all of which can be completed or revisited at any time. This screen is for inviting and managing judges.

The final step for the administrator is the review of all the evaulations to choose winners (or applicants to advance to the next round). Evaluations can be shown by applicant or by judge and may also be downloaded as pdfs.

An administrator's view of an individual applicant

For the Judge

From the conversation with our school and our CEO's knowledge of the kinds of competitions that are run by university entrepreneurship, we identified the judge user to primarily be of an older demographic with industry experience. That being said, they likely would be less tech-savvy, so we chose to create as straightforward and narrow of a process as possible.

Log in, sign up. If I were a judge, which would I want?

An obstacle we ran into when designing the judging side is that judges may not be on the StartupTree platform -- and may not want to be. But some judges may already be on the platform!

We determined that judges would access their platform through a customized link. The link would bring them to a sign in that allowed them to either sign in with their StartupTree account. We wanted to encourage judges to sign up, but not enforce it, so the main CTA on the page is the Log In button. However, judges may also continue as a guest. There is a competition passcode (set by the admin) for each competition on top of having a customized link for a second level of security.

The judges' initial view is a list of applicants, with ranking (that changes as judges complete evaluations), the status of their evaluations, and personal notes to help the judge differentiate between individual applicants.

The judge's initial view of all applicants

As judges read through each application, they are also presented with an evaluation to complete. The evaluation section was designed to mimic a piece of paper or physical rubric to help improve the judge's mental model.

The judge's evaluation view for an individual applicant

One of our biggest pain points was determining how to incorporate force rankings. We asked questions like "Where does it fit in the flow?" and "How do we make it intuitive?" We did not want to bring judges away from their evaluations, but also did not necessarily want to add steps to the overall process. In the end, we chose to nest a modal with a table of rankings inside each evaluation (that would update globally); however, I believe this solution was not the best we could find. Because of the short timeline and limited resources, we could not user test and opted to implement it as best we could, but I would have liked to explore more options and test them with real users.

Force rankings for judges

Outcome and Reflection

As a result of building this module, StartupTree signed over a dozen of university and other entrepreneurship-related programs. Many university entrepreneurship programs host competitions and have applications for roles, and this structure is flexible enough to fulfill both needs.

If I were to revisit this project, I would reexplore the navigation for administrators, create a better onboarding system for judges with tutorial copy and interactive help, and redesign the third audience's, the applicant's, flow.

back another project

more projects