Why every UX designer should go to a Hackathon
Learn how to collaborate with engineers in 30 hours
Before attending my first #HackMobility in San Francisco, “Hackathon” was just a nonsense buzzword.
“Isn’t Hackathon only for engineers?”
“What I can do in 30 hours if I don’t know how to code?”
While holding a lot of doubts, I decided to give it a try.
It turned out to be an unforgettable experience that I learned and heard from people in different positions. Such a practice also reinforced me on how important it is to put my hand into actual work and how much I enjoy dealing with ambiguity while pushing through the challenge within a team.
I would recommend every designer to participate in a hackathon. Just hack, learn, make friends, but most importantly, just have fun!
Here is what I learned from my first Hackathon and what I created in 30 hours:
Day 1: Learn how to push through as a team
10 am: Introduce yourself to find a good fit
Entering the building with a full stomach of food and coffee, my excitement can be noticed by anyone who passed around. After talking with a bunch of people, I ended up forming a team with three engineers: Mario, SeHee, and Julian, who were just looking for a designer to join the team. All three of them come from a non-tech background just like me, and this is what fascinates me about the industry — the embracement for diversity, where anyone has a chance to learn, practice and grow.
Noon: Build a shared understanding to move forward
As I was super excited to dive into the design thinking approach, the engineers were talking about APIs, a term that has always confused me. So I broke into their discussion and asked explicitly what an API even means. Eventually, with their help, we got on the same page. Then, I suggested another way of approaching the challenge, starting from answering the following questions:
- what is our goal?
- why this product should exist?
- who we’re building the product for?
- what their needs are?
Guided by these questions, we started brainstorming as a team and everyone was throwing out different ideas until we made an agreement: to build a car-sharing app with the unique audition function to make the driving experience more fun and accessible to people who live in the city and to increase the efficiency for car owners when they don’t need to use their cars.
2 pm: Draw on a whiteboard together to maximize collaboration
When we drafted out the big picture of our product, we moved on to the next step: to decide core functionalities within the platform we were going to build. We came in front of a whiteboard and started to draw any solutions we could think of. This cross-functional sketching exercise emphasized the layout of functionalities and contents, which not only need to be usable but also feasible to build within our time and technical constraints.
After we all felt comfortable moving on, I started with some comparative analysis and began to refine the wireframe and workflow and the engineers put their hands to write the infrastructure code necessary to get the data needed to UI layers.
As a designer, I use a lot of visual elements to demonstrate the usability and functionality of a product, starting my thought process from the user. Even though we talk about engineering constraints all the time, it wasn’t until I talked to engineers in a real-life project that I realized that any render on the surface requires a complicated back-end technology to support its function.
5 pm: Visualize core elements to pivot quickly
After the engineers reviewed the wireframes and agreed on the layout of components, we started working independently, but it’s still crucial to communicate all the time to reduce any confusion and maximize the team efficiency. When I was designing toward hi-fidelity screens, I always kept my teammates updated with any design decisions.
Midnight: Make UI elements accessible to boost efficiency
It’s time to work on our tasks individually. Before pushing pixels on the screen, I made a mini style guild including logo, color, and font styles, to make sure when my teammates need to pick up the necessary information, they could have a simple guide to refer to.
Day 2: Learn how to give a presentation as a team
Thanks to the engineers’ effort, they turned my design into a hand-coded and live-data prototype! After we submitted the documents, Julian explained to me how the front-end coding was structured, and this real-life example has significantly broadened my basic knowledge about HTML & CSS. The best learning model for me is always from doing.
Noon: Leverage your strengths to show the best of your work
Once the hard work was done, we gathered together to practice our presentation. My major responsibility was to illustrate the user’s journey including their needs, motivations, behaviors. Due to limited time, we showcased the ideal outcome of the product by presenting the clickable prototype in front of judges. My teammates were taking charge of the technical side of the story: what APIs were built with, what data they could obtain and how the app works from the back-end.
Together, we showed a story from a user’s perspective to the technical implementation. We were excited to see whether people liked our idea, and were eager to receive critical feedback.
Click here to see our prototype!
Final thoughts:
A huge shoutout to my talented and diligent engineer teammates!
The most meaningful lesson I learned in 30 hours was how to collaborate with engineers more efficiently by understanding how they think, and how to approach a challenge given limited time & resources.
Always communicate, think critically, and convey feedback in a positive way. Even though we need to perform our tasks in a high-pressure circumstance, it is only by being collaborative that we can move forward and level up as a team.
For next time:
It will be interesting to see how product designers can carry out some simple usability testing and conduct interviews under the time pressure of a hackathon.
