We met with METCO representatives Colin and Milly at their headquarters in Roxbury on April 8. During the meeting, we discussed their hack needs for the Hacking the Archives event and shared with them what we had planned for the hack itself. As projects pitched and developed at Hacking the Archives will extend into the summer, we wanted to learn what METCO had planned for the long term.

The Roxbury location is right off the MBTA Orange Line, a few blocks away from the Jackson Square stop. METCO’s headquarters are housed above the Mass Rehab Commission’s Roxbury office in an old New England building with creaky wooden floors and well-worn couches in its hallways. A small dog and a receptionist greet us at the METCO entrance on the second floor; the receptionist mentions attending the Data 4 Black Lives conference and asks if we are affiliated. We explain that we are not and take time to investigate some of METCO’s informational materials on the wall, including a timeline of their history.

Colin arrives and we are led into a small conference room, slightly chilly and sporting a freshly-cleaned wooden table. He welcomes us to what he calls “our little hideaway” as he plugs in a space heater, informing us that it may blow a fuse, but the heater does not turn on. We begin discussing the hackathon idea and our general plans, sharing the product of the pit crew organization so far. We then ask about their needs and desired outcomes in designing and programming the hackathon.

Our key takeaways from this conversation are as follows:

1. METCO’s long term goal is to “create a ‘reciprocal busing’ program” (though Colin stresses that this is not official terminology). METCO currently has over 3,000 students who are bused from Boston into the suburbs, where they learn about suburban histories, cultures, and other ways of knowing and being. They believe that the suburban schools and communities should make an equal effort in learning about Boston through these students. Students from Boston should be able to present their respective histories through their own voices and research, producing stories that they can feel proud of and have ownership over.

2. METCO would like to use the hack opportunity to begin collecting stories and places that correspond with the history of METCO, preferably tying into the social and activist histories of each respective neighborhood. They have expressed their hopes that METCO “should be just one part of a larger social justice story.” Ultimately, this project should lead to a sustainable program that can be refreshed and renewed year after year.

3. Their target audience is suburban classmates and teachers unfamiliar with the histories of Boston-area students. They wish to accomplish the following through their project:

– Make visible the unknown history of desegregation in Boston

– Dispel suburban myths about what Boston is like

– Provide suburban residents with an engaging way of learning about Boston and its people

They plan to work with primary historical materials and will likely be bringing yearbooks, handbooks, fliers, and other sources to the hack. They also hope to bring in high school students currently participating in the busing programs as participants in the hack, as they will take over and lead development of the project over the summer.

As per METCO’s feedback from this meeting, we plan to address the following:

1. We will be assisting METCO by researching and bringing more primary sources to the hackathon. In addition, we will center the activities for the hackathon around their goals to produce a tour/street guide to Boston.
2. As METCO hopes to bring in Boston-area high schoolers, we want to make sure that they have equal stake in the project. As a result, we have reached out to see if METCO can arrange a meeting with us including one or more of their students.

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.

(For anonymity’s sake, some of the MIT-specific names and spaces have been changed or removed.)

There are several educational technology-based labs within MIT that collaborate regularly. Every month, one of these labs hosts a monthly playtest where researchers present their projects to people outside of the department (and outside of MIT) and allow these people (user testers) to test the projects for potential usability. While this is not a design space in the strictest sense – the projects in question were premade – the playtest space gives user testers a unique opportunity to see works in progress and offer feedback based on their own experiences and expertise. It’s a unique opportunity to share our knowledge and tools with the greater community.

As someone who has presented projects several times in these playtests, I have noted that we rely heavily on the user feedback in order to improve our games, simulations, and experiences. In other words, everyone is an expert based on their own lived experience. Whether the user tester in question is a student, teacher, professor, scientist, or concerned citizen, their input matters greatly to the future of each project. As a educational technology creator, I ascribe to iterative design – the theory that design takes a circular path and can be improve through continuous feedback, change, and reiteration. Change is constant and ongoing, and emergent from an accountable, accessible, and collaborative process.

However, I realize that these playtests are limited in terms of design justice. The fact that we present half-complete projects over potential ideas to users is limiting in itself; we create what we believe is useful and show it to a community that may or may not need it. While we do work with schools and organizations from the beginning of the design process, we could only do so much within the playtests to create community-led and -controlled outcomes. The users were required to work with our preexisting structures to offer criticism and feedback.

Another major issue was the imbalance of power that existed between the researchers/designers and the user testers. Although we regularly encouraged users to speak up and make their voices heard, this was not always easy. There were far too many times where users became intimidated by the technology and immediately shut down. I still recall the dozens of users who told me “I’m not a gamer” or “I don’t know computers” and refused to offer feedback because they believed that they were not “smart enough” to do so. The fact that users felt uncomfortable was entirely our fault. It is the priority of the designers to not only make users heard, but feel empowered to speak up.

The playtests provide an opportunity for teachers to tell us about what may “already be working for them” and for other educators. However, the limited demographic representation of user testers was yet another issue. Many of the user testers were MIT students and staff who heard about the event through email or word of mouth; others were outside-of-the-bubble locals who receive newsletters through the edtech labs or are friends and former colleagues of the designers. Many of the educators represented, thus, were from schools in the greater Boston area who regularly work with MIT. What of people who may not have had the means to come to MIT, or lacked the connections to receive news about our playtests? What of the children and students who would be most directly affected by our projects, who rarely if ever appeared at the playtests? There were large swathes of the Boston community that were strongly underrepresented among the user tester population which compromised our ability to deliver true design justice.

While playtests are only one step within the greater circle of iterative design, it is vital that we connect more deeply with the community we serve throughout the entire process and reach far beyond the MIT bubble to do so.