What I Learned from HackPrinceton as a Product Designer

a dinosaur emoji on a light green background

Last weekend, I participated in HackPrinceton, a 36-hour hackathon.

marketing graphic for hackprinceton 2022
*2023 oops | Source

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!

Collage of my teammates working and taking picture at the closing ceremony
🌃😎

What our team made

We built 
 drum roll 
 DinoBud!

Graphic for DinoBud - an partner accountability system to help you learn

It’s a partner accountability system that helps you

  1. Set a learning goal every week (E.g. Learn React)
  2. Set your punishment (nothing serious)
  3. Write four tangible tasks to achieve your goal
Wait
 that sounds pretty simple.

Well, two features make it different from other products:

  1. Add a real-life accountability partner
  2. Use our learning coach powered by Chat GPT to get helpful resources/advice

In the end, our team won both “Best Interactivity Hack” + “Best Financial Hack”!

Screenshot of our team winning best interactivity hack and financial hack
LET'S GOOOO đŸ”„

We also built a Figma demo. Check it out below if you’re interested

Learnings

Now, let's go over my learnings from the hackathon.

It’s okay to express my thoughts

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:

Screenshot of scott belsky's tweet talking about how people should strive for disagreement
Source

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.

Figjam full of sticky notes
A lot of great ideas here 💡
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.

key and peele sweating
Source

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.

man nodding awkwardly in a dimly lit room
Source

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.

You need to design FAST

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.

a cat smashing the keyboard frantically
Source
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.

Understand the developer’s perspective & goals

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:

Ease of implementation

Is this feature easy to implement? Will I spend a lot of time on this?

Specific interactions

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

  • I want to build a paradigm that has never been seen before
  • I want to build a product that can be scaled
  • I want to build a product that doesn’t just copy what GPT4 does

My point is: Listen to what your team members care about. Understand and find a common ground.

Hackathon working styles

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.

Power of Chat GPT

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.

youtube thumbnail saying gpt4 is coming
Source

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?

Urge to learn how to build

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


The infectious energy of a hackathon

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.

Designer has a place in a hackathon

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


Figma page of a ton of 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.

Conclusion

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)!

And that’s a wrap!

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!

‍

Read Next