How to win a Hackathon and be a good person
A guide to earning brownie points and being a winner.
In August of this year, Tabcorp ran a pair of one-day community Hackathons for the volunteer groups CVA and OzHarvest.
As responsible citizens, this seemed like a perfect way to get involved, give back to the community, and take a break from our regular work.
Every good Hackathon requires a crack team of digital commandos, so it was time to assemble the A-team.
Chapter 1: Gathering the four Horsemen. And then two additional horsemen.
The team started with me:
Chris — UX Designer/Team Captain/Man-bun enthusiast
With my impressively limited skillset brought to bare, it was time to find some programmers.
I work in a multi-discipline team. Our front-end development has iOS, Web, and Android expertise, alongside a group of testers, back-end, and DevOps people.
I really wanted to finish the Hackathon with a working prototype that CVA could take back to their organisation, so I decided to prioritise front-end development. Due to the limited timeframe, I left testers out of the equation — testing is really important, and we’ve got some really talented testers in our team, but I figured we’d be way too time poor to properly test anything.
After some persuasion (And begging. A lot of begging, actually), I had assembled my crack team:
Ivan — iOS Developer/Can brew his own beer
Chao-iOS Developer/Self-proclaimed nice guy
Abhijeeth — Android Developer/Alternate history fiction writer
Arthur — Web Developer/KFC Evangelist
Chai — UX Designer/Very cute dog owner
Okay. This is the real deal. With a team assembled, it was time to do a bit of a brainstorm and figure out what we were going to do on the day.
Part 2: Picking the most important problem in the whole world.
That’s a dramatic title. I was hoping for something more witty, but this is what we get. Sorry.
CVA provided three problem statements. They’re pretty long, so I’ll paraphrase:
Problem 1: Tell the Story
CVA organises and executes on hundreds of volunteer events every year, and it’s the success of these events that drives future participation and donation. They want a more effective way to share these events with their stakeholders.
Problem 2: Spotlight on Staff
The staff and volunteer workers that CVA employ are required to undergo a significant amount of training for each of the events they partake in. CVA would like an efficient, effective way to empower staff to complete self-driven training.
Problem 3: In Data we Trust
As an organisation, CVA contains thousands of assets, employees, volunteers, staff and stakeholders, all of which need to be effectively tracked, managed, and maintained. They’ve got the data, but they’d like a cost-effective solution to manage this data and increase the effectiveness of CVA’s resource management.
All good problems, well worth solving. But even with a team like this, we can only save the world one problem at a time. We brainstormed all of the problem statements, but one solution really stood out to us. It was for the first problem:
- CVA employees should be able to quickly post events to the website, or to a CVA app.
- These event pages should contain rich, ad-hoc information, as well as dynamically generated data.
- These event pages should inform viewers of the events major milestones for completion.
- These event pages should drive volunteering and donations.
The core concept came from our 6th team member, Chai. He pitched it as a kickstarter-esque solution for community projects. We all felt it was a winner, and decided that’d be what we’d go for on the day.
Part 3: Design and Development
The Hackathon took place at the Odecee/Cognizant Collaboratory (shameless plug). We all got there early and begun the most important activity of the day: scoping the best coffee.
By the time we’d done that, we decided maybe we should head up to the Hackathon.
There was a brief introduction before teams could get started. Once we sat down and got setup, we realised we had about 6 effective hours before the groups presented their solutions.
As a UX Designer, I’m used to taking at least twice that long just to pick a font, so I knew I’d have to up my game.
We started by drawing out loose user journeys. We knew that most of the app would be smoke and mirrors, so identifying what key funtions we wanted to showcase would be key to a good presentation. This was tempered, of course, by the fact that whatever we chose to do had to be achievable in our dwindling time limit.
The journey was relatively simple, and split into two parts for our demo:
CVA Event Organiser — Android Device
Our event organiser would create a new event, enter some static information, and then add dynamic elements to their page before making it public. This includes setting some milestones for the event, and identifying social media feeds the organiser would like to track.CVA Stakeholder (Volunteer or Donator) — iOS Device
Our stakeholder could go to the app, view a list of events, and select the event our organiser had created. From there, they’re able to pledge funds or volunteer hours. They can also view all the static and dynamic data.
The critical component of this plan was the interactibility between the two apps. It was really important for our demonstration that the changes made on the Android device would be represented on the iOS device. Furthermore, we wanted to demonstrate the social activity tracking live, so we needed to build that feature.
We split the development logically: Ivan and Arthur had backend experience, so they focused on that functionality. Chao and Abhi were responsible for the iOS and Android frontend, respectively.
Chai and I started sketching UI and mapping out the functionality of the app. This started pretty rough.
Appendix A: Tools we used
Anytime I read an article like this, I’m always curious to know what design tools a team uses. To that end, let me summarise a few things that we used on the day:
Sketch: Probably goes without saying, as Sketch is more or less the default for UX development now. On a personal note, I’m actually quite partial to Figma, but since our whole team is familiar with Sketch, that’s what we went with.
We used the Craft plugin to generate dummy data for our events and users in our prototype.
Flinto: Chai introduced me to Flinto when I first started at Tabcorp — it’s a small, lesser known tool with some fantastic features. It’s capable of complex animations and interactions, and has a very straight-forward UI. It’s also got a great plugin for importing your sketch files, and fits nicely into our workflow. We didn’t have too much use for this on the day, but it’s our tool of choice for generating interaction animations.
Slack: I think just about everyone has Slack now. If you don’t, feel free to Slack me and I’ll tell you all about it.
XCode: The only application that allows you to program in Swift, Apple’s proprietary coding language. We used this for the iOS app.
Android Studio: No prizes for guessing what we used Android Studio for, this was Abhi’s IDE for the Android app.
With a loose framework in mind, and an inappropriate amount of coffee, we got to work. This was the fun part; building the app on the fly, making snap decisions about UI and functionality, all while trying to keep the project within scope.
It was around this point we realised we might’ve been too ambitious, but it was too late to turn back now, so we dived in.
After the first few hours, we had some pretty solid preliminary UX, and the code was starting to come together.
The UI style was pretty straight forward. Visually, we took a lot of inspiration from the CVA website and iOS itself.
We also looked a lot at the MeetUp and Kickstarter apps, as they had similar functions: creating and managing events, leveraging live data, etc. At this point, we iterated. In a few hours, we had a functioning demo.
By the time we presented the project, we had a working prototype on both iOS and Android. We’d also managed to get communication working between the two so that we could update event status from one device to the other, and we’d integrated Instragram. The presentation went well, and we were lucky enough to win the Hackathon!
Upon reflection, I think there were a few key factors that allowed us to scrape throught with a win:
Good research and planning
We spent a good amount of time before the day studying the CVA problem statement, and really trying to understand where the pain points were for their users. This really gave us a clarity of purpose on the day, as we all agreed and understood where the opportunity in CVA’s business was.
It might seem obvious, but if there was one thing I’d recommend to anyone doing an activity like this, it’s understanding the user, and the client.
A diverse, multidisciplinary team
Our team make up represented six different nationalities, with developers proficient in multiple code bases. Because of our mixed talents we were able to come up with a really comprehensive solution that solves a number of problems in some really innovative ways. Being able to lean on the knowledge of our teammates was integral to building our prototype.
The hard work and dedication that the team put in on the day was really excellent, and I can’t speak highly enough of them.
An agile approach to concepting and development
Right from the start we utilised whiteboards and pen & paper sketches for rapid prototyping and journey development. This allowed us to identify gaps in our user journey early, and make quick adjustments.
It also meant we had a great resource during development to keep us on track, as we were able to mark off screens and journeys as we completed them. Chai really led this effort early on, and it paid massive dividends throughout the day.
I wrote this more for prosperity, so if you got this far: thanks for reading! The prize for winning the Hackathon was to spend two weeks building out the soltution, so I’ll be writing a part two at some point.
If you want to learn more about CVA, you can find them here!
If you want to learn more about Odecee, you can find them here!
