Why Designers Should Do Hackathons
I attended my first hackathon, MedHacks 2.0, at Johns Hopkins University two weeks ago. I teamed up with two of my coworkers, both of whom are Venture for America fellows and developers: one full stack developer and one who specializes in machine learning. Since they were knee deep in code for 36 hours, all of the UI/UX design was left to me. Here is everything I learned.
1. You will have an incredible amount of creative freedom.
Our ‘hack’ was a chatbot we called Remi who reminds you to take your medications and refill your prescriptions through SMS, Facebook Messenger, and Amazon Echo. Remi then tracks all of this data in a dashboard that is viewable online. The engineers on my team weren’t too invested in the front end design, which gave me the freedom to create what I wanted. In 36 hours, I made the dashboard, the branding, and the pitch deck for Remi without any instruction or designated path to follow. It was refreshing to dive into something with complete creative freedom and see it come to fruition in such a short amount of time.
2. You will master a new tool out of necessity.
I just recently started using Webflow for work (3 days before the hackathon). I decided to use Webflow to build the dashboard because it’s a quick and easy way to prototype and design a static front end with full functionality. I then exported the html/css for one of my teammates to make dynamic and to pull data from firebase. Using a new tool at the hackathon motivated me to dive deeper into the possibilities inherent in the structure of the software. If I were to go to another hackathon, I would choose a different software to learn during the event. There’s a sense of urgency to learn at a hackathon that you won’t get on a lazy Sunday afternoon staring at Lynda courses.
3. You will have to make quick decisions and rapid prototypes.
You’ll reach a point in the day when the developers will be staring at you and asking what they need to start building in preparation to hook the backend to the front end, which means you have to be ready and know exactly what you need. This requires quick decisions about different screens and views. For our project, I quickly decided on 5 screen views; I then had to stick with these choices after the developers started working. Maybe some of the views weren’t necessary or could have been improved, but at a certain point you run out of time trying to fix mistakes. You have to push yourself to think through and accept every decision you make in a small amount of time.
4. You will not create a perfect product.
Let’s all be honest with ourselves. The first 36 hours with any design problems are spent brainstorming, starting and restarting, and shuffling through color palettes. It can be a slow journey to the end product. At the hackathon, you need a minimum viable product in 36 hours. You create a logo, choose a color scheme, decide on a type face and then you make it work, because there’s no time to change it. You won’t create something perfectly optimized for the user with Dribbble worthy design because you don’t have time. This is a sprint and you should enjoy it, because you get to finally throw a bit of caution to the wind.
5. You will be a valuable asset.
Going into the hackathon, I doubted I would add much value to my team. I have basic front end knowledge, but not much past that so I wouldn’t be much help in actually creating the chatbot. If there’s anything I’ve learned thus far from my fellowship program, in my job at a fast-paced start up, or from my design school background, any product is 20% what you say and 80% how you say it. One of my most important value adds was with the pitch deck. I had the responsibility of creating my team’s story. With the right visuals, mockups, and market research, Remi went from a 36 hour project to a business people would want to invest in.
Overall as the designer, you get the opportunity to tell your team’s story. Don’t get bogged down by perfecting the features or capabilities. Everyone wants to see what you have built, but also where your project could be in two months. The best advice I can give is find a great team, always grab the free pizza, and enjoy the sprint.
