In this post, I will be reviewing the Hack for Inclusion event at MIT through the lens of design justice principles. This hackathon happened in late February of 2019 in the MIT Media Lab space and focused on “finding innovative solutions for important, difficult, and messy problems related to creating a culture of inclusion in a complex, globally diverse world.”

While I have participated in hackathons before, I found Hack for Inclusion’s structure to be unique. As opposed to on-site organization of teams, the HfI organizers asked for participant information beforehand and organized us into teams based on skill and/or interest. As such, each team was diversely composed of developers, engineers, designers, educators, and other skilled persons. Although I can absolutely see the advantages in crafting teams before the event, I wonder if this impacted the limited number of challenges posed by the organizers. Almost all of the challenges were sponsored by different companies, nonprofits, or advocacy groups, and as such each group began with a different level of available resources. The challenge my group was given, “Society Reentry from Incarceration,” had representative subject matter experts but did not have a sponsor.

The hack was organized as follows on the first day. All teams followed the same schedule, as is listed here. The following day was devoted to building, testing, and judging.

(A disclaimer: we were given the option of listing our favorite challenges before the hack, and “Society Reentry from Incarceration” was not on my list if only because I have little to no preexisting knowledge on the topic. As such, I was surprised when I received this challenge and often found myself confused over the course of the hackathon.)

Design Justice Strengths

• Design as empowerment (to some degree). As previously stated, the hackathon’s organization was unique in that we were sorted to different groups before the event. This allowed us some time to get acquainted with the topic, potentially connect to other group members, and do some background research.
• Understanding of what is already working at the community level. We had some experts on post-incarceration programs who offered their experiences working with newly freed persons or knew of accurate secondhand accounts of programs that were effective for our target audience. Ultimately, this informed the final design of our project – rather than building something entirely knew, we decided to consolidate what already existed and make it easily accessible to those who need it.

Design Justice Opportunities to Improve

• Lack of community-controlled outcomes. Our group was made up of developers, nonprofit workers, and graduate/undergraduate students. The people who would be most impacted by our work were entirely absent, so we had to rely on secondhand testimonies on the internet to design our experiences.
• Lack of voices who would be most directly impacted by our design. As previously stated, we had no former incarcerated people who we could contact and interview, or otherwise involve in the project. We did spend some time interviewing a prison warden, but I am all too aware that their experiences are entirely different from what a prisoner would face.
• Lack of accountability. After the project was said and done, there were a few emails sent out by the organizers asking us to send materials or offer feedback. Otherwise, there was no other “push” for us to continue the project.
• Lack of expertise. This may have only reflected my experience in the hack, but I did not feel like everyone was treated as an equal expert throughout the process. Our group was unusually massive – 10 people – and it was primarily 2 or 3 people experienced in post-incarceration programs who dominated the conversation. I found myself unable to speak up or contribute much throughout the event because of my sheer lack of knowledge.

Looking back, I suspect that the hackathon organizers were particularly careless with putting together my team. Of the 10 people present on the first day, only 2 people came the second day to continue working on the project. It seemed that they decided to group together everyone who could only come for the first day, which is a strange decision on their part.

While I enjoyed the experience overall, I sense that there was far more that a hackathon that labeled itself as fostering inclusion could do. More than anything, it could promote an inclusive design environment where all feel included, and where all members of the hacking community have equal access to resources.