For this blog entry, I am writing about ATHack 2019, an assistive technology hackathon at MIT. I examine its strengths and its opportunities for improvement through the lens of Design Justice Principles.
Personal Notes
I find it important to note a few things before presenting my reflections on the event:
- I have not had the lived experience of disability. These reflections come from my own attempts to think more critically about my role as an ally.
- I had a small part in helping to prepare the ATHack event this year, and my main planning contributions were around documentation. I present only my own personal views here.
- Related to the above, I had a positive impression of the organizers and the event itself before going into it. I aim to present constructive criticism in this blog post that I can build on as I hope to have a more active role in planning next year’s event.
- I will not really dive into an examination of the politics around the category of “assistive” tech. That could be a whole article of its own (in this case, one written by Sara Hendren).
ATHack Overview
ATHack is a student-led hackathon at MIT focused on assistive technology, i.e. technology designed specifically for the needs of people with disabilities. Within the broad terrain of accessibility and assistive technology, ATHack has a specific scope of social and educational goals, as written in its mission statement:
Our mission is to make the world more accessible to everyone
by building connections within our community and fostering collaborative efforts to create inclusive technology. Through ATHack, we introduce students to the fun (and challenging) design space of assistive technology while building connections between community members, engineers, and designers. We hope to inspire participants to pursue projects in the AT space in the future.
The event’s central concept is that the planning team matches student “hacker” teams to form a partnership with a “co-designer”. Co-designers are people living with disabilities who come in with a design challenge/prompt to collaborate on with hackers, typically based off of a hurdle they face in daily life. There is an open call for participant applications, though there is a (flexible) emphasis on attending two in-person events at MIT. The primary purpose of the applications is to ensure a certain level of commitment to the 3-week timeline of the event, as well as a good fit with the event’s overall goal of a collaborative learning process, rather than a completely ready-to-deploy project.
Event Format
The event is split into 2 parts. The first is an introductory dinner where hackers meet co-designers, learn about their particular design prompts, and submit an online preference list for which co-designer’s team they’d like to join. After a matching process by the event organizers, teams have about three weeks to get to know each other, learn more about the co-designer’s problem space, brainstorm, and order materials for from the event organizers. The second part of the event is a 12-hour hackathon, ending with brief project presentations and an awards ceremony in which teams are honored for categories including usability, innovation, and documentation.
Design Justice Strengths
The major strengths of this event as seen through a Design Justice lens come from its emphasis on a collaborative design process that centers the expertise of a co-designer.
Co-Designer Collaboration
The organizers are very purposeful about their language, framing, and event organization to set the tone that hackers are addressing design challenges with co-designers, not for co-designers. The most obvious way this comes across is in the language around co-designers. Importantly, the structure of the event underscores this message as well. Teams are given a few weeks so that all team members can learn more from the co-designer about their specific design prompt. Teams are expected to learn from the expertise of their co-designers, and they are expected to be able to show how their project meets the needs and engages with the contributions of their co-designer. This learning process centers the co-designer, and can include activities ranging from interviews to tagging along on a typical commute or shopping trip.
Collaborative Flexibility
There is a lot of flexibility in how co-designer teams are arranged. Some co-designers have formal engineering backgrounds and come in with prototypes or concepts to iterate over with a team in terms familiar to them. Others come in with a rich understanding of a particular problem space, and they’re looking for a team who can help brainstorm solutions and test them out. Some want firsthand experience in every stage of the design process, while others would rather provide expertise/feedback at particular stages. Some collaborate with their teams independently, while others collaborate along with parents or caretakers. The event is organized such that none of these differences in collaborative process is treated as the norm or as the ideal. There is no “best” way to collaborate, but there are processes that are better fits for individual teams.
The 3-week lead-up to the hackathon event also allows for increased options for remote collaborators. Hackers and co-designers who couldn’t make it to the hackathon event due to unforeseen circumstances were still able to meaningfully engage remotely day-of thanks to the time spent collaborating ahead of time.
Emphasis on Real-World Needs
At the introductory dinner, event organizers stress that a good design isn’t necessarily one that uses the newest and flashiest technologies. A good design is one that meets the needs of the person who will use it, and there is a usability award at the end of the hackathon to honor that. A good design is also one that is documented well enough that the process can be repeated, and there is a documentation award at the end of the hackathon to honor that.
As with many hackathons, this event has a few big-name corporate sponsors . However, unlike many other hackathons, their involvement is very minimal. Sponsors do not receive participant resumes, and they do not send any promotional materials to the event. This greatly reduces any incentive a team might have to build a flashy but unusable tool that might grab the attention of an outside onlooker.
Design Justice Opportunities for Improvement
Where the event succeeds in centering voices of co-designers on individual teams, it could improve on its own organization process to follow the co-design model in planning the event itself. If there is difficulty in recruiting event co-designers, maybe the first iteration of this process improvement could be in the form of an advisory committee of particularly engaged co-designers from past hackathons.
Planning Follow-Up
In class, we talked about the benefits of engaging community partners and co-designers in hackathons, but we did not talk about the challenges of follow-up with them. Event follow-up is a tricky subject for hackathons that promote strong, short-term personal connection with co-designers. How do teams navigate a situation where they don’t get as far with projects as they thought they would? What about when they get farther than they imagined, and their project seems like it could be quite close to being deployable? The event organizers say in the application and at both in-person events that participants are not expected to work on their project beyond the timeline of the hackathon. However, some teams are very excited to continue work on their project past the timeline of the hackathon. It’s not hard to imagine teams’ expectations may fall out of alignment as people get caught up in the excitement of the day’s progress or in the disappointment of not accomplishing everything they thought they would. I wonder what it would look like to adapt a Working Agreement for use in this context so it’s accessible and non-intimidating for everyone involved? Is there a guided conversation teams can have built in to the hackathon schedule, to discuss whether and how they want to continue work on their project?
Linking Out to Advocacy Issues
ATHack targets the scope of its projects to its educational goals and its timeline. The hackathon projects end up targeting a specific individual experience, which makes a lot of sense for a short-term commitment. However, evident in many of the presentations at the end of the hackathon is the fact that the co-designers’ experiences are not just their own. They come in with design challenges in the context of broader issues, for example: existing assistive technology that doesn’t assume the active lifestyle they lead, existing assistive technology that’s not very usable independently, or lack of accessible options for an activity of daily life. Some co-designers call these broader issues out specifically, while others do not. I wonder what it might look like to be able to link event attendees with local advocacy groups that might be pushing for industry/policy change, or service organizations that focus on disability. Could there be brief presentations from such groups at the closing dinner/ceremony at the end of the hackathon? Could the organizers invite representatives from these local organizations to be judges at the hackathon, or sit and talk with participants at the closing dinner?
Managing Space
The hackathon is hosted in the Beaver Works space, with a few distinct rooms for group work. The room where most of the software-focused teams were working was a little hard to navigate once teams were settled in and working there. Though there is probably a little more room to rearrange the space for better accessibility, the most straightforward solution is probably to reduce the number of software-focused teams. Alternatively, there might be space for a spillover room for participants, since it’s easier to find a space suitable for teams working on software projects. However, both of these potential solutions come with serious downsides for the event, and a spillover room creates more potential logistic issues, like the ones this event faced due to inclement weather.
Overall, the rest of the physical setup works when everyone is not in the same room, which basically only happens at the end of the day. This is typically in a different venue on campus more suited for all the participants to navigate at the same time. However, this year there was a last-minute change in location for the event closing, due to inclement weather. In responding to participant concerns in getting to the other campus location in snowy conditions, the event closing ended up being in a space that wasn’t really suited for it. I think it’s easy to say that there should be a better Plan B for that kind of situation, but I am not sure what that would actually look like. A combination of lab/classroom/workshop spaces works really well for this hackathon, but not well for a dinner or closing ceremony, and vice versa. This might be a case where an advisory board or co-designers for the event itself could help find a suitable back-up plan, or a completely new way to think about closing the event.