2014 – early 2015
I designed one form for creating a project regardless of starting from a portfolio or a hackathon. When submitting to a hackathon, users were presented with a “project picker” page where they could create a new project, or quickly submit an existing project. The only additional form fields needed were those specific to the particular hackathon. New projects created at a hackathon were automatically displayed in the user’s portfolio.
We also improved the questions on the form itself, re-writing all the fields using more natural language and adding question prompts to help hackers explain their project.
As the project neared completion, I organized a user testing session with previous hackathon submitters. We led participants through an exercise to submit a project to a mock hackathon using the new implementation.
We used their input to make improvements before releasing the new flow to a handful of “beta test” hackathons. After more feedback and adjustments, we enabled the new submission flow as the default for all new hackathons on our platform. This feature affected the most critical point of a hackathon, so I continued to ask for feedback during future user interviews.
We always have hackathons live with open submission periods, so the new flow couldn’t be released like a normal feature (where it's deployed and instantly enabled site wide) because it would break hackathons with open submission periods.
I worked closely with our engineering team to maintain two submission flows at once. We released the new flow as a "feature" that could be enabled on a per hackathon basis. All new hackathons used it by default, and we migrated existing/old hackathons one by one when it was safe to do so.
Hackathon submissions and portfolio projects were stored in the database as two separate entities, which diverged over time. We could not just map one to the other due to differences in column names and associations.
Portfolio projects are designed to be a living entity that evolve over time. In contrast, hackathon submissions need to preserve the project at a given moment in time: the submission deadline. The system must be designed so that hackers could continue to edit their project forever, but hackathon judges and managers could see a “snapshot” of the project at the deadline for fair judging.
Product/design problems become engineering problems. Working together early and often = better ideas, faster results, and a happier team. I saw big wins by including engineering team members even in my earliest brainstorms for this project, and this became my go-to method for complex projects moving forward.
For large projects in a startup environment, it’s crucial that everyone on the team understands what you’re spending so much effort on. Especially for non-tech teams (sales, marketing, etc.) provide an overview of improvements the work will accomplish. Some methods I used during this project:
When you think you have the perfect solution figured out, you’ve definitely missed something. There’s no substitute for watching real users try your product. In addition to the fun experience of yelling “how did you miss that button?!” as you watch the sessions, you’ll end up with a much stronger solution.