How I Survived My First UX Hackathon
I’ve heard of hackathons before, but never actually participated in one. They always seemed so daunting to me, mainly because they’re full-day events (and I’m not just talking eight hours). Given a prompt/challenge, the goal is to come up with the best possible solution in a limited timeframe.
This particular hackathon spanned a whole day. My team and I worked for a solid 13–14 hours. That’s a lot of hours and isn’t exactly ideal, but I decided to do it anyway and I’m glad. I ended up learning how to strategically manage my time and developed other key skills, all of which I can speak to in job interviews.
Methods
Before the start of the hackathon, it’s important to plan out the day. My team and I sat down to discuss what our process would be and how much time we would spend on each task. During an event like this, there isn’t time to dwell. It’s either you move on or reap the consequences down the line when it becomes a mad rush to get everything submitted.
Creating a Mini Roadmap
We set up a shared board in Notion to plan our day and ensure we were staying on task. It was important for us to set time markers. Even if we felt more could be done on a particular task, we had no choice but to move on.
It’s worth mentioning here that this was a struggle for me. As a detail-oriented designer, I always strive for quality. So, as you could imagine, I sometimes find it hard to move on. This is one of the reasons why I’m proud I participated in this hackathon.
If nothing else, it allowed me to work on my time management skills and learn how to move ahead when time and resources are tight.
We also agreed as a team that we would continue to work on our solution post hackathon, so we could worry more about quality then.
Process
Without a doubt, we had to make some sacrifices when it came to which parts of the UX process we wanted to prioritize. We had no choice but to be scrappy and squeezed in the relevant phases we thought we needed to set ourselves up for success. For the most part, we followed the phases of design thinking and conducted mini sprints.
Empathize & Define
These two phases were really all about defining our problem statement and conducting user research. We focused on identifying who our users would be and aimed to understand their needs, motivations, and behaviors.
Analyzing the Market
The night before, each team member took some time to analyze direct and indirect competitors pertaining to our problem space. In the morning, we came prepared to quickly synthesize our findings and form a user point of view that we would address with our design.
Gathering Data
We also sent out a survey to a few people to gather answers to relevant questions. Surprisingly, this helped out a lot.
All in all, our research was rather limited due to the time constraints we were under. Looking back, of course we would have loved to spend more time on research. However, the data we did collect was enough to make informed design decisions for V1 of our solution.
Ideate
Ideation consumed a big chunk of our time. Since we had two UX-oriented team members and two UI-oriented ones, we split up and designed in pairs. The UX-focused members drew up an app map/user flow, while the UI-focused members brainstormed visual directions. This involved creating some moodboards and discussing color, typography, and illustrations.
Following this, we thought sketching ideas was critical, so we used the 6–8–5 method to draw out key screens and flows. We had so many ideas (which was great)! Ultimately, sketching provided us with a solid foundation for moving onto wireframes.
Prototype
Going off of our wireframes, we created high-fidelity screens and prototyped the user experience. This involved transforming our ideas into a physical form to experience, interact with, and test. This part of the process was the most difficult because there wasn’t a lot of time to spend on perfecting the visual design.
Test
After putting together a solid prototype, the sensible next step would have been to test it. Testing is integral to any design process and it guides product iteration. However, because my team and I underestimated how long it would take us to assemble our prototype, we didn’t get much testing in. The best we could do was test it amongst ourselves. Originally, we did plan to test with users but ran out of time (this is definitely something to be mindful of in our next hackathon).
Iterate
Lastly, I want to touch on the importance of iteration, because it’s fundamental to good design. Since this was a single-day hackathon, we didn’t have time to iterate on our proposed solution. However, we didn’t completely disregard iteration. Instead, we decided to talk about it in a “future recommendations” slide at the end of our presentation. This also allowed us to switch from working on the happy path to thinking about alternate and edge cases.
Lessons Learned
Everything considered, there are some key lessons I learned that I’ll take with me to my next hackathon.
1. Don’t reinvent the wheel
There are plenty of resources out there to help speed up your workflow (especially during a hackathon)! Take advantage of these. Here are some my team used:
Google Fonts
A new tool for teams & individuals that blends everyday work apps into one.
www.notion.so
2. Gather just enough research
As mentioned above, we took a pretty scrappy approach. I don’t think this is a bad thing and when you’re strapped for time in a hackathon, it’s important to prioritize.
What is the final deliverable that needs to be submitted?
Ask yourself this question when analyzing the challenge and determining what you should spend the most time on. For example, we needed to submit a functional prototype, so we chose to spend more time on that.
3. Sketch out ideas
Thinking back to our UX process, I think sketching was the most important part because it helped us nail down the layout of key screens.
4. Don’t underestimate the time it takes to prototype
Prototyping, despite how robust and efficient design tools are these days, takes more time than you think. It can be a challenge to connect different states together and get things set up how you want them. My team and I only left about 30 minutes for our prototype and this delayed our final presentation, which in turn led to technical difficulties and a late submission…
5. Be honest
…more about that late submission. With only one hour left to submit our proposed solution, we were scrambling. The prototype had set us back due to unforeseen technical difficulties and with only 30 minutes left, we still hadn’t recorded our presentation. It was at this point that we realized we wouldn’t be able to submit our solution on time.
We were still really proud of our work. Even though we worked all day on our solution, we accepted the harsh reality—it was okay to no longer be in the running for the competition. Each team member really participated in the hackathon for the opportunity to dive back into design and get more experience under our belts, not for the prizes. Regardless, what we decided to do was send an email to the hackathon organizer, explaining our difficulties. Our goal was to be honest and upfront.
Doing so paid off because the hackathon organizer replied to our email, granting us an extra hour to submit. We didn’t see this coming.
This interaction, regardless of if we were still allowed to submit or not, was a huge learning lesson. Above all, it showed me the importance of being truthful.
Sure, we could have made up an excuse or lied. However, this would have done nothing but show what type of people we are and how we work. I’m proud of the team decision we made.
So that’s how I survived my first UX hackathon. If you’re interested, here’s our final prototype and presentation, which was a finalist in the competition!👇
Special thanks to:
- Leverage — the company behind the project prompt we chose
- Vlad Korobov—the organizer of the UX Result Hackathon
- The judges—for offering their time to review team submissions
