We just launched PageGauge.io — designed and built in a one-day hackathon, across San Francisco, Portland, Vancouver and London.

This was unanimously the most successful hackathon that any of us have participated in. Here’s what we did:

Get setup beforehand (1–2 weeks before actual day)

1. Agree to do the hackathon — buy-in and excitement from the team is key- and decide a date that the team is available, and block it off in the calendar (to avoid any meetings being scheduled).

Thursday is what we consider the best day — you get recovery time at the weekend, it doesn’t detrimentally impact your weekly sprint, and people are happy to work late (as opposed to Friday).

2. Select an idea. We did this just as two Co-founders, because together we were clear on our objectives (see below) and could make a speedy decision. We were going to be the evangelists and provide leadership so it was important we both believed in our idea.

*Our objectives when considering ideas:

• Something whole team can get involved in
• Not directly part of product roadmap
• Something based from current learnings
• Something that can be tested with other / new customers
• Something we can deliver within a day
• Something valuable that fits in with our growth strategy*

3. Prepare the logistics (week before hackathon day)

• I set up a Trello board with an overview of all the tasks I could think of for product, design, engineering and marketing. Once the spine was ready, we had a quick call the day before to walk through the main tasks and answer questions. After that everyone on the team felt comfortable they knew what the day would bring and begin planning accordingly.

Our Trello board a few days before the day

We had to be super-efficient on the day so before that I also added cards with Trello shortcuts, Hangout link, launch timer, inspiration etc.

-We had a separate Slack channel for the hackathon and we setup integrations with Trello and Github so that people could see progress.

-We created a Google Drive folder for all related documents (and had a sub-structure that matched the lists on our Trello board). We had invited a designer to participate in our hackathon and made sure he had access.

4. Think of a good name

We setup a Trello checklist to enable everyone to contribute ideas. It’s important the name is simple and conveys the essence of the product and has available domains! We used https://domainr.com to check. Once we agreed, we bought the domain and a registered the Twitter handle.

5. Engineering setup: It’s important to not get stuck with building environments on the day, so get that figured out the day before. Brian also thought ahead a little and created the scaffolding for the app. To ensure our designer, Mike was able to be productive without needing a rails environment, we architected the product as an API + front-end site.

On the day

Kicking-off: It’s important to stay on top of dependencies to avoid anyone waiting or wasting time. We had planned a team kick-off call at 8am PT but I made use of being in London (8 hours ahead) to ensure our preliminary research was ready to discuss on the call.

After researching what affects webpage usability I compiled this summary table which we discussed in our kickoff call

We had the first kick-off call to agree the most important usability criteria that we wanted to include in the first version of PageGauge. We did this as a whole team so everyone understood the fundamental product, before doing a separate engineering kick-off where we translated these criteria into a set of rules we could implement within the day.

Continuing to focus on the process: it was my job to make sure things worked smoothly. Some of the ways we did this:

-Had a Hangout call running all day. We also implemented the Hangout Toolbox so that people could have separate conversations on the call and also listen to their own music without being disturbed by others.

-Many activities involved multiple team members, which posed the risk of double-work or missed expectations. Therefore we updated our Trello labelling so that it was obvious what exactly everyone was working on. I kept reminding everyone to use these until it became habit.

-Another big risk in the day was that we would spend too long in the earlier tasks, leading to a crunch on the latter ones. For this, I advised that no-one should spend longer than 1 hour on a single task. If they were unable to do complete it within that period, then either it needed breaking up, or flagging to me. In addition we setup three check-ins for the whole team; 10 min calls every 3 hours to provide an opportunity for everyone to share successes and highlight issues / risks.

Getting sht done! It was great to see as tasks were marked off completed and we tried to get something up as soon as possible, to build momentum and to better provide feedback. We built the front-end and API separately, so neither were blocked by the other, and could be tested independently.

Progress of our Trello board throughout the day

Key tools we used included: Trello, Slack, Drive, Hangouts, Hangout Toolbox, Github, Heroku, MongoDB, Bugsnap, Redis, Surge, MailChimp, Twitter, Namecheap, Sketch, Segment, Medium, Product Hunt, CustomInk

Closing out and follow-up tasks

We finished almost all that we had set out to accomplish for the day late on. There were a few things outstanding and we had to make a decision on when to launch and whether to spend any more time on it. We agreed that we should stick to our earlier plan of launching the next week (apparently the best times to launch on Product Hunt are Tue, Wed, Thurs) but we also wanted to launch a valuable product, so decided that we could dedicate another few hours over the weekend and upcoming days to close out.

This actually ended up delaying our launch by a few weeks, because we found it difficult to generate the same type of momentum when working asynchronously in small parts. There was also no clear end point because everyone had suggestions for incremental improvements — something to watch out for.

Lessons learned

I’ll update this a couple months afterwards, so I can incorporate what impact the hackathon had over time. If you would like to participate in a future distributed hackathon we run, then you can sign-up here.

Want to learn more? Subscribe to the Chameleon blog for free insights to help you become a UX and user onboarding master.

Please share these learning with others by hitting the ❤