Paul Wilshaw · Designed for Humans

Guide

Making hackathons more inclusive

Illustration of a mixed group at a hackathon, working at computers with ideas and emoji above them.

Hackathons are great. They do, however, exclude people. I created a plan for a hackathon that includes people who'd normally be left out: encouraging everyone to understand the problem through research, and offering training and upskilling for anyone not confident in coding or design.

Start with the problem

First, define the problem statement and frame it, so organisers and participants share the same understanding. Work through each step, and if you can't give a clear, simple answer, clarify it before moving on:

  • Goals: do you know clearly what problem you're trying to solve, and what you're working towards?
  • Understand: do you know the biggest problem you face?
  • Frame: can you articulate your idea simply and clearly?
  • Ideas: do you have a range of ideas for solving it?
  • Evaluate: are the ideas robust? Which is the strongest?
  • Decide: test and choose the strongest idea. A clear vision makes for an effective solution.

For this plan I focused on mental health. In the UK, mental healthcare is in greater demand than ever: one in four people will experience a mental health problem at some point in their lives, a quarter of patients wait more than three months to see a specialist, and 6% wait more than a year (Campbell, 2018). The hackathon's brief: use automation, robotic process automation (RPA) and AI to improve patients' access to mental health services, and raise awareness of RPA with technical and non-technical people alike.

Why hackathons leave people out

Hackathons began as volunteers collaborating on open-source software, but organisations soon adopted them to gather ideas quickly through sponsored competitions (Richterich, 2017). I've experienced the 'contractual transaction' Rodney Folz describes: at a hackathon at Microsoft, days of talks about products came before any hacking, and five days of 12-hour stints ended with a £500 restaurant voucher and good PR for the sponsors.

There is a clear contractual transaction of goods and supply: your time, your résumés, and your intellectual labor in return for their dinner, their cheap sunglasses, and their shirts emblazoned with corporate logos.

Rodney Folz, 2015

The barriers aren't only the ticket. Delegates are often expected to bring high-spec laptops, phones and other kit, which shuts out people from low-income homes. At the Hearst Hackathon in 2015, around 80% of participants were visibly male (Zukin and Papadantonakis, 2017). Time pressure and prizes reward 'Frankenstein' prototypes and CV-driven choices over what end users need (Jee, 2015). What hackathons do brilliantly is prove ideas quickly; they rarely produce a finished product.

An inclusive plan

The aim was a hackathon where delegates collaborate on the brief rather than compete, and where learning is the reward:

  • Learning over prizes: mentors and practitioners, in person and online, teach delegates to build an automated process, and everyone who takes part earns an entry-level RPA certificate. Recognition goes to teamwork, participation and acts of kindness, not winning teams.
  • Many ways to contribute: an automated process, a website, an app, a film, an animation or a podcast can all answer the brief.
  • Paid tickets for a good cause: free tickets always lead to lots of no-shows, so tickets are paid, with the fees donated to the mental health charity CALM.
  • Free VIP passes: around 40% of tickets go free to delegates from under-represented backgrounds and low-income households, for example anyone who's had free school meals or a college bursary. VIP delegates attending in person get the software and hardware they need.
  • Reaching the right people: recruitment targets schools, colleges and universities in areas the English Indices of Deprivation 2019 show to be skills and economically deprived, through their own newsletters, websites and posters.
Hackathon ticket options: a virtual pass at £40 and an in-person pass at £80.
Ticket pricing for the hackathon.
A free VIP pass for eligible delegates.
The free VIP pass, for delegates who'd otherwise be excluded.

Talking to humans

To keep every channel consistent, I wrote tone of voice guidelines for anyone creating content for the hackathon. Talk to humans, not developers or enthusiasts who already know what a hackathon is. Inform, don't lecture. Ask, don't tell. Cater for different levels of expertise. Keep information bite-sized, use sentence case, avoid italics and light fonts, and spell out abbreviations the first time, like artificial intelligence (AI).

Personas, built from anonymised data on behaviour, age and roles, shaped where and how to reach potential delegates. Registration also captured accessibility needs, so the event could plan for them, using a set of icons I designed:

Icons for accessibility needs: visual impairment, colour blindness, hard of hearing, motor or physical difficulty, keyboard only user, anxiety, autistic spectrum and dyslexia.

I tested the communication with potential delegates for usefulness, efficiency, effectiveness, learnability and satisfaction (Rubin and Chisnell, 2008), and tried different channels: a podcast about my own experiences attending, organising and judging hackathons, and teaser campaigns shaped to each social platform's audience. The website offered two journeys: a creator path for experienced hackers and a learning path for newcomers.

The creator journey: interview potential users, ideate, generate and submit.
The creator journey.
The learning pathway: interview potential users, learn to automate, start automating and submit.
The learning pathway.

What could be done better

Hackathons have worked well in retail, banking and travel because hackers can easily reach the people who use those services, often friends and family. Healthcare is different: access to patients is rightly regulated, and reaching people with mental health needs ethically takes real investment. Lasting solutions mean breaking down the barriers between hackers and the frontline practitioners who have the problems to solve (Chowdhury, 2012).

The pandemic complicated things further. Face-to-face mental health services were interrupted, and an online hackathon raises the barrier to entry again: every delegate needs broadband, a capable computer and the right software for the whole event. The hackathon could run virtually, but providing equipment and one-to-one support, the heart of its inclusion, would be much harder.