Last weekend, I participated in HackPrinceton, a 36-hour hackathon.
In this post, I want to share what we did and my learnings.
Before I start, a huge shout out to the amazing Ariya, Aagam, and Sanskar! Lost a lot of sleep but the grind was so worth it!
We built ⊠drum roll ⊠DinoBud!
Itâs a partner accountability system that helps you
Wait⊠that sounds pretty simple.
Well, two features make it different from other products:
In the end, our team won both âBest Interactivity Hackâ + âBest Financial Hackâ!
We also built a Figma demo. Check it out below if youâre interested
Now, let's go over my learnings from the hackathon.
I donât like to argue, and Iâm a people pleaser.
Why argue? If we can just follow one direction and start building, isnât that great? Why make everyone frustrated and tense?
But, Iâm starting to realize:
Thatâs actuallyâŠnot so good.
And a tweet from Scott Belsky - founder of Behance - explains the why:
The essence is:
Beware of nodding heads. Seek disagreement because thatâs when new ideas spark.
Let that sink in for a second.
And this happened on the first two days of HackPrinceton.
Initially, our team was in a good groove. We added over 40 sticky notes of ideas onto our Figjam board. We were all excited about them.
But then it was time to decide on a single topic.
And what followed was hours of discussion. Hours.
And oftentimes, the discussions got a bit heated. People talking over each other. Or the entire team remaining silent because nobody knew which idea to go with. It was near impossible to align on one idea that we all wanted to work on.
In the end, we settled on the accountability partner idea at around 11:30 AM on Saturday. The submission deadline was Sunday 8 AM.
At the moment, was it uncomfortable?
Yes damn, it was uncomfortable. You cannot imagine how damn badly I wanted to just settle on an idea and start designing.
Yet, if we go back to Scottâs quote:
Beware of nodding heads. Seek disagreement because thatâs when new ideas spark.
In retrospect, I would say the heated discussions were an incredible learning experience for me. Without it, I donât think we would have come up with other new ideas. We sure wouldnât have understood what each other cared about in this hackathon.
As you could tell, I was the nodding head in the group, occasionally sharing my thoughts.
In the future, I want to contribute. I donât want to be afraid of sharing my thoughts. If I have a valuable thought, share it.
More importantly, contribute to the conversation with a designerâs perspective. Donât be afraid to ask:
So⊠what are the possible use cases of this idea?
Whatâs the problem weâre trying to solve with this idea?
Are there any existing products that do this?
Remember:
There may be heated conversations. There may be moments when you feel like your team is not going anywhere. Embrace that feeling. Find ways to break that stalemate. Donât be afraid to speak up.
At a hackathon, you need to design fast. By fast, I mean going from idea to lo-fi to hi-fi in a few hours. Or maybe less.
Why?
Because time is everything during a hackathon. The faster you can design, the faster the engineers can start implementing.
This year, my team consisted of two product designers including myself.
I know - this is very rare in hackathons. But I really appreciated someone to discuss designs with. And it made designing a lot faster.
Also, the other designer did 80% of the designs, and I probably helped with 20%. I really need to get better.
At a hackathon, 99.9% of the participants are developers.
Thus, as a designer, you will work with developers. Thereâs no question. Thus, you need to understand what developers care about.
From the discussions Iâve had, I realized that developers value the following:
Is this feature easy to implement? Will I spend a lot of time on this?
What happens when I click this button? Will a modal pop up? Will it open up a new page?
Ultimately, the goal is to make a developerâs job easier.
Here are some practical questions that were often asked by the developers:
What could be built with the timeframe left?
Should we include this feature?
Whatâs the purpose of this design element? Is it truly necessary?
How can we build this in a simpler, easier way?
On the nuance level, developers also have different goals.
Here are some examples
My point is: Listen to what your team members care about. Understand and find a common ground.
This is also important to know before you look for teammates. People have different mindsets towards hackathons.
For example, one may just want to attend workshops and chill. Another person may focus solely on awards. Another person might be the type that works all night to grind.
For our team, I would say weâre more in the camp of grinding but also having fun. We donât mind staying up late as long as we can build a great product. But we also want to have fun and laughter.
But, this may not be for everyone. So, understand your working style and find team members that resonate with that.
So many projects used Chat GPT.
Iâm starting to use Chat GPT a lot more often. And it was only until this hackathon that I realized:
Damn. A lot of our project ideas can already be done with Chat GPT.
Itâs incredible how much it can do. Iâm definitely going to use it more.
Plus, I canât even count how many times our team mentioned Chat GPT in our discussion. Itâs so interesting to see how AI is now such a prevalent topic when thinking about products.
And I would say one of the most common questions during our discussion was:
What can our product do that Chat GPT cannot?
Participating in hackathons makes me want to learn how to code even more.
Or, with AI, learn how to build an idea.
Honestly, most of the ideas our team talked about have the potential to be built.
And if only I understand the full stack, I can build all the ideas.
Itâs such an enticing thoughtâŠ
I love hackathons.
The energy. The commitment. The passion.
People gathering together and dedicating serious time to build ideas.
If youâve been to a hackathon, youâll understand what I mean.
The energy is infectious. And, though I do feel physically exhausted, mentally Iâm super pumped to work on my next side project.
This was interesting.
Before, Iâve always thought hackathon is this âhackers-onlyâ competition. But, this time, it felt different.
This time was the first time where I felt like
Wow! Having designers on the team actually can help a project stand out!
For our DinoBud project, one of the most frequent praises was on the UX/UI Design. Now, I want to preface: Our front-end and full-stack engineers were fantastic. Though they werenât able to build everything, they seriously did their best considering the time.
As one of our engineers said this beautifully:
A designerâs dream is often a developerâs nightmare.
Well, we sure did give them a hard challenge with our DinoBud designsâŠ
But, itâs what helped us stand out. And demoing our Figma prototype helped as well.
In fact, one judge didnât even know that it was a Figma prototype!
Thus, if youâre a designer worried about your role at a hackathon, I want to tell you:
Designer has a place in a hackathon.
In short, HackPrinceton was a blast.
Sure - I slept for a total of 7 hours in 36 hours. But building things together with my team was an amazing experience.
And I canât wait for my next hackathon experience (TBD)!
Thank you for being awesome and reading this far! :)
If you have any questions, feel free to reach out on LinkedIn, Twitter, or by email. Will love to set up a casual call and chat!
â