Defining the process

Hackathons take many forms in both their purpose and execution. If you attend these events as a hacker--please can we stop using that term--you've probably engaged with a variety of these forms: new product and concept development, collaboration between public and private industries, novel uses/creation of data...the list goes on and on.

At the Brown Institute, we have been fortunate to experiment heavily with this form, often focusing our energy on the design process as opposed to the construction. The Photography, Expanded lab, for example, mixed practicing photographers, journalists, designers, and engineers to collaborate and develop new projects focused on social justice or human rights issues. For this workshop, the process hinged on a largely adapted Stanford d.school model that focused on audience or reader as opposed to user. Although the event was extremely structured, there was little in the way of framing the event around a particular challenge.

Other hackathons that we've held provided an in-depth framing of the challenge, but lacked structure and process. An example of this was our most recent hack event, the MINDS Innovation Challenge, which commenced with an in-depth seminar on the contemporary challenges facing news agencies, but lacked any facilitator-led engagement with the design process.

While the results of these two events were varied, both produced inspiring and viable output.

A few months ago, we began a collaboration with the United Nations Development Programme on Climate Information for Resilient Development in Africa, primarily to help them design a hackathon to complement their 'Last Mile' workshop. After weeks of conversation, the process we arrived upon was a day-long comprehensive framing of the challenges, a brief introduction to design thinking concepts, and 24 hours of development.

A detailing of the workshop methods are below:

Day 1
  • Empathize: participants spent day one of the conference listening to the challenges faced by countries in attendance
  • Define: at the close of day one, groups were asked to define the core goal of your project, and the guiding principles that will govern the project
  • Assets: participants were exposed to a variety of the data available to build applications around
Day 2
  • Stakeholders: at the beginning of day two, groups began by defining both direct and indirect stakeholders of the project
  • Metrics: groups defined what attributes will define success for this project
  • Challenges and Questions: to conclude the design process, groups were asked to identify roadblocks and limitations, as well as gaps left unanswered by their product/solution
  • Build