I recently got into a really great conversation about hackathons in the Designer Hangout slack channel. We were wondering, what role does a designer actually take on at a hackathon? What value do designers provide hackathons, and what about the opposite? After the conversation, I kept thinking about it, all the hackathons I’ve attended, what I’ve learned, and how I’ve contributed. There seems to be this idea floating around that designers, especially those who don’t code, don’t really have a place or can contribute much during a hackathon. While that notion is (luckily) dying down a bit, I thought I’d write out my thoughts on the subject.
Hacka… what?
For those of you who aren’t sure what hackathons are, I’ve found the best way to describe it is this:
Hackathon: A big ‘ol nerd event where a bunch of big ‘ol nerds form teams in order to create digital/hardware projects for 24–48 hours straight. They are then judged by a group of peers and professionals, winners often receiving prizes consisting of cash, hardware, software, and a well deserved rest.
That’s the gist of it. A hackathon is a marathon where teams hack together a project. But there’s really so much more that goes into it. I mean, there’s got to be a reason students are so willing to give up their weekend (and thus their most precious sleep) just to furiously type away at their keyboard and chug coffee after coffee… right?
Right. The topic of why hackathons are awesome in general has been written about pretty thoroughly, so let’s talk about why more designers should take part in hackathon, and what doing so has to offer them.
Hackathons, designers, and symbiosis.
Much like spider crabs and algae, designers and hackathons have a mutually beneficial symbiotic relationship. Designers provide ideation, creation, research, and empathy. In return their skills in these areas are strengthened, they develop new skills, and they have a shiny new and interesting project to show off. Having a designer on your hackathon team give your developers the freedom to focus on the technology while the designer focuses on the product. Let’s go into more detail:
Prioritization and Project Management Skills
Hackathons are short. You and your team need to get a working prototype in front of the judges in less than two days. There’s pressure from your team to jump in and gogogo. But you’re cool. You’re zen. This is your time, as a designer and as a problem solver, to shine. Hackathons are great because you‘re so constrained by time that you are forced to prioritize how every second is spent. You’re not going to be able to go through a full round of research or conduct A/B testing. You’re forced to think about how you’re going to tackle the project in front of you and get it done within the time frame.
One of the most important contributions a designer can make on a hackathon team happens during the define stage. You’re going to be the person who gets into the nitty gritty of what the project is actually going to be, and what’s most important. You should (hopefully) have at least a general idea of what your team wants to do, now you just need to know now how to refine it. Ask yourself questions. Why are we making this? Who are we making it for? What is the users goal? Has anyone ever done anything similar? How can we best utilize the technology at hand? Questions like these and more will help your definition process, as well as understanding your users and their needs. It will give your team a clear understanding of what they’re going to make, and it will give you much more insight into what the team needs to prioritize.
This stage takes some time, I usually shoot for an hour or two, but think of it like an investment. You’re going to sacrifice some time right now so you don’t waste a lot time later by pivoting. By this point though, your team ready to go, you know what you’re making, you’ve gained experience managing a team, now it’s time to move onto design and development.
Making the Damn Thing
You’ve asked a bunch of questions, you know what you’re making, maybe you’ve done some competitive and comparative analyses. You now know what’s been done before and what your team can provide that’s different. This is where the fun begins.
Once production starts, it’s the designers job to apply their ideation, research, journey map, and understanding of the user all at once and with this information, lay down a solid information architecture. This will give your team a solid framework to build off of, you can mark what’s most important, and it leaves you to start on the UI.
There are a few directions you can go after this. Personally, I always like to take a marker or pen and draw out my low fidelity wireframes before getting on the computer. This presents the opportunity to quickly iterate and change the layout without using up a lot of time. From here, I like to code the front end while my developer teammates make sure the back end is solid. If you’re not a coder, that’s totally cool too. Get started on some high fidelity wireframes so your developers don’t need to think about the layout.
Once you have a good portion of the project developed, you might start having some trouble finding things to do. Maybe you’ve finished all of the mockups and now you’re idling by while the developers code away. This is a good opportunity to do some guerilla usability tests, work on how your team will present, write content etc. but most importantly, make sure you and your team take a break every once in a while. You got this, don’t kill yourself over it. After a while, you’ll see that your project is done surprisingly early. Take this opportunity to test it and look for bugs, let other teams and mentors play around with it, and see if there’s anything you need to change before presenting.
Now Go Show Off
I’ll finish this off in a typical narcissistic way by talking briefly about myself. Almost three months ago I graduated with a BA in psychology and a minor in social science from a university who’s psych program mostly focuses on clinical and therapeutic practices. I don’t sound like the type of guy you find at a tech meetup, let alone a hackathon. Despite that, I focused my studies on cognition and HCI where I could, started a design & code club, worked my ass off, landed internships, and now I’m a full time UX designer. Which is kinda dope if I do say so myself.
Now, while numerous factors got me to where I am today, one of the most important was my portfolio. As any designer will tell you that a good portfolio is absolutely necessary when it comes to job hunting. It’s what lets recruiters and hiring managers know that you are capable of doing good design work, and just as important, showing your design process.
As it currently stands, three of the five design showcases available on my portfolio/medium are the result of hackathons. I like to keep them there not only because they illustrate how I go about my design process, but they show how I design under pressure. Attending hackathons tells employers that you’re excited about applying your skills in design, you’re (the good kind of) crazy enough to spend a whole weekend without sleep, and it shows that you’re smart enough to delegate what needs to be done and when, even under said pressure.
Whether you place or not, hackathons are absolutely one of the best ways to build a portfolio. They provide you with a loose theme to base your project on, a time-frame to keep you from slacking, and prizes which motivate you to make something good. Best of all, you can quite literally make whatever you want. This give you the opportunity show your creative side, stretch your skills as far as they can go, and really make something great.
Find a hackathon. Go have fun. Not a student? Reach out to your local tech community and find one near you!
Thanks for reading! This was my first blog post ever! I’d love some feedback, or If you liked this article, it would mean a lot if you hit the recommend button or share with your friends.
If you’re interested in learning more about me, feel free to check me out in the following locations: linkedin / website / instagram