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:

1. 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.
2. 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.
3. 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.
4. 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.

On March 6, three members of the core MassMesh team, plus Ned and I ventured down to Jamaica Plain to present about mesh nets and their liberatory potential. Our audience: Ujima Boston, a democratically controlled investment fund focused on building the solidarity/co-op economy. In order to demonstrate the process of building a mesh network vividly, we played a game called NodeRunner that was originally developed in 2015 by the Detroit Digital Justice Coalition. Participants were able to successfully play through the game, and we garnered a lot of rich input about what residents of JP expect out of community owned internet infrastructure.

Although we hypothesized that most concerns would center on cost and speed, most were about coverage (as a percentage of the neighborhood) and completeness of the break with traditional ISPs. This was dramatically highlighted when we presented information about sharing existing internet connections. A wave of concern swept the room. “But if we plug into Comcast in the end, what have we gained?” This is exactly the kind of enthusiasm for cutting the cable that we want to hear/foster, and I was pleasantly surprised to hear it expressed in our very first community meeting. Discussions focused on obtaining and operating an internet exchange point (IXP) are coming up next week.

Overall, the event on March 6 was a great first engagement, and there are more to come. The relationship we’re building with Ujima could help us grow into our first neighborhood installation while Ujima expands their list of accomplishments for their membership.

The framework for thinking that we explored during class has helped me surface some of the strengths of MassMesh, and has also raised a few questions about out strategy for rolling out our network.

Epistemology

Right now, we’re of course focusing on building the basic technical knowledge necessary to participate in a mesh network. This has to be there in order to lift ourselves out from under the thumbs of corporate internet giants. There is also a bit of necessary education about the political implications of joining the mesh, and the historical basis for our current situation (in which ISPs have an impressively powerful lobby in the legislature.) In addition to spreading technical know-how, though, a good outreach strategy should also garner knowledge about how to effectively organize in our communities. This is important knowledge for the developers at MassMesh.

Until we have a deeper understanding of how to successfully organize in our communities, MassMesh’s discovery efforts will be limited by our own ability to draw out insights without creating biases in the room. We also run the risk of over-simplifying concepts to the point that residents don’t feel like input is necessary or possible. There are a host of options for implementing community controlled open internet, and these must all be explored.

The knowledge that we create must be sharable, but this is one of the things that I struggle to visualize. We grew our mailing list when we engaged with Ujima, but those tend to have low participation. We could certainly do more to maintain a strong online presence as a group (MassMesh.) Creating useful artifacts for other organizers would be a good thing too. The NodeRunner game that we played on March 6th could benefit from a bit of clarification. While participants in our workshop could likely tell the difference between a regular ISP and a mesh network, I’m not sure in what situation they would propagate this knowledge. We should do some work to discover or create these situations if at all possible.

Values

All view expressed below are meant to be representative of Mass Mesh, not necessarily any of our community partners or affiliated organizations.

The values that drive our project include the belief in the power of non-market exchange, desire for building neighborhood autonomy, belief in ubiquitous and open internet, and disbelief in both private intellectual property and private infrastructure.

These values can create serious dilemmas and conflicts for us. One is that it is impossible to simply install autonomy. The social project of building community owned internet is one that is just barely under way now, but is of critical importance. If we choose to approach it in a way that minimizes the required effort from residents, we could end up creating just another ISP. If we choose to approach the social project in a way that requires a lot of work from residents we risk fizzling altogether due to lack of engagement. Ultimately, we will have to figure out a short, medium, and long term strategy for this, which will be the subject of a later blog post.

In addition to the difficulties associated with building autonomy, I see a potential conflict on the horizon where a neighborhood that has successfully joined our mesh network decides to pursue profit in some way. This could include over-charging new residents for access or some kind of fine system for people with fussy hardware on the network. Ultimately, the network would still be operational under these circumstances, but it would certainly undermine our value of non-market exchange.

Our values are in flux, and in particular we have begun to value community input much more this year. In the past, most of our time has been spent hashing out the technical underpinnings for the project. Now, we are actively engaged with one community partner, and that list is growing to potentially include Tent City Apartments/ SETC, Artisan’s Asylum, and even Netblazr.

Outcomes

Depending on who is talking, our outcomes could be measured in several ways. One is simply the cost of internet. If my internet costs go up by joining the mesh, why join? This one is understandable, but I don’t think it’s likely to be the only measure used. When conducting the game last night at Ujima, the primary question that got asked was, “what about all those inactive cones?” Essentially, “what if the whole neighborhood doesn’t have access to the mesh?” This leads me to believe that a common measure of our success with be coverage as a percentage of the neighborhood. Other possible success metrics will be speed, reliability, and consistency of network coverage.

Ultimately, these outcomes will be owned primarily by residents, with Mass Mesh’s reputation sustaining either a healthy boost or critical blow as a result.

Stakeholders

There are three kinds of participants/stakeholders.

1. Residents
2. Organizers
3. Technologists

Each of these groups will have distinct roles. While the technologist is responsible for guiding installations, education, and network strategy, she may not be as qualified to speak about the reliability of the network. Residents, on the other hand, will be deeply aware of the quality of network coverage, and will need to maintain their hardware/software in order to uphold it. This process of staying up to date and the process of continually improving the network should be facilitated by organizers, who convene residents and technologists in constructive ways.

Conclusions

In conclusion, the values of Mass Mesh are ambitious, but attainable with the help of residents. Autonomy really begins with the mobilization of affected communities, and we are now actively working to foster this. Although we have been a mostly technologist lead organization up until this point, resident input has already changed our perception of expectations. As we build knowledge, it will be critical for us to share it in meaningful ways. This is something that should be explored more in the near future. Now that we have identified our stakeholders, we should spend time refining their personas and gathering input from them. Overall, the framework for thinking that we employed in this post has exposed some under-pursued interests in our project.

It was useful for me to think with the Frauenberger et. al’s accountability and rigor framework in terms of beginnings, middles, and ends for my project. In developing my project, one of the challenges is that the users (stakeholders including educators, criminal justice officials, police officers) who will use the training materials to better interpret social media are not the same group of people who are most affected by the outcomes of the technology we want to develop. The users will adopt the training materials, but youth in disproportionally policed and surveilled communities of color are most affected by the outcomes of the training technologies. So it is important to us (my team, collaborators, and myself) that we learn and work alongside youth as we ideate, design, test, iterate, etc.. the social media interpretation training product. 

Beginnings:

I am thinking more deeply about how I will build relationships with youth, and come to understand their thoughts, ideas, and concerns about the social media surveillance issue. I am keeping in mind that although youth may have a variety of good ideas, it’s important for me to consider the constraints and affordance of the product technologies as I know them. It’s important that the tech developers on my team have an understanding early of which community – derived ideas we are thinking of prioritizing, so that I can also help facilitate brainstorming with youth in a more productive way. 

In the beginning I am also thinking about how we might evaluate that our training products did something well. This could be an assessment of their critical reflection or decision making on how to respond to a students’ post. At this point I can consult with the youth community partner about what they think a successful training might look like to them.  

Middles: 

Using the accountability and rigor framework, I realize that it would be good to also consult with the youth about the look and the feel of the training system. Important questions to bring to these conversations could include, do they feel good about the ways their stories are being portrayed and represented in the product? Do the scenarios users will train on feel authentic to lived experiences youth are having? Does the training product seem to culminate in a way that honors youth’s realities and suggests actions and alternatives that youth would actually like to see? I also realize that I need a way to capture and integrate the feedback/results that I gain from these conversations. Perhaps by working with youth to illustrate comics, where they will tell their own social media stories. ? 

Ends: 

This section helped me to think about the end goal of building these training materials in terms of, where would/could I see the developed product being used in the future and by whom?  It also helped me to think about ways to share and prepare tokens of appreciation to the youth community group we are working with, such as films of their participation that they can keep and share with their families.  Since policing and arrests are sensitive topic, its important that that kids feel that they are playing a valuable and important role in this project, and that it’s hopefully something they can  continue to look back on positively and constructively. As far as outcomes, I am also thinking more through how our system impacts specific skill development in users such as interpretation of youth’s social media from a more holistic and humanistic way, as well as building empathy skills around youth. 

Other things I am thinking through having read the Frauenberger et. al. piece.  ~

What values drive this process? Empathy, empowerment, democracy, justice. And a follow up question for myself and my team – what does equity and success look like for us here?

How do stakeholders and users get involved as well as benefit?Participants can gain on several levels: improved competency with technology, the awareness of novel education opportunities, building of relevant social networks. Impact can also be seen in altered structures (maybe more schools will adopt this model), altered practices and perspectives . 

Disclaimer: I haven’t met with my community partner yet — I’m going to update this once I meet with them and have more context!

I am partnering with the Design Studio for Social Intervention (ds4si) to co-design the Festival of Counteratmospheres, taking place in June. ds4si has a wealth of experience co-designing interventions, installations, events, workshops, and more with communities in Boston. From delving into their past projects, I can see that they are actively engaging with the principles of design justice. I am really looking forward to learn from them and to share any useful skills and resources I might have.

Here are some initial thoughts on this project, through the four lenses of participatory design put forth by Fitzpatrick et al. in “In pursuit of rigor and accountability in participatory design.”

Epistemology

In their past projects, knowledge is constructed with the communities at stake, rather than constructed for communities. In fact, many projects start with an open question that invites responses from the community, like visioning workshops. Sometimes, these responses are turned into “productive fictions”, like Public Kitchen. The knowledge that is produced with the community can then be disseminated in the forms of physical zines or digital resource guides, like the Social Emergency Response Center Manual. This then provides a framework for organizations and individuals outside ds4si to create their own projects and events.

Values

ds4si prioritizes marginalized communities — the groups that make up the horizontal public. Their design process reflects this prioritization, by both inviting and meeting community members where they’re at in all stages of the process (from ideation to execution). Accessibility is a key concern emphasized in ds4si’s projects, reflected in choices of meeting spaces, event spaces, and materials.

Stakeholders

So far, I understand the stakeholders of this project to be the community members participating in the organization of the event and the event itself, the ds4si organizing team, and myself. I see myself benefiting from this project by having the opportunity to observe and practice co-design principles in action.

Outcomes

This festival will create multiple counteratmospheres that can serve as spaces for the Boston community to convene and to generate more ideas for the future.

I am working with Annie on the Boston Activist Organizations Hackathon project. This project is being co-developed with Professor Karilyn Crockett from DUSP, grad student Meesh Zucker, and the following community partners: the Dudley Street Neighborhood Initiative, the Boston Ujima Project, and the Center for Economic Democracy. Also involved are Ceasar McDowell’s Boston Community Learning Project, activist filmmaker Simeon Awosan, and the Northeastern University Archives & Special Collections.

The plan is that these groups and individuals will be both the co-designers of, and the participants in, the hackathon. Due to the high number of stakeholders, there is a need to ensure everyone is on the same page and address conflicts as soon as possible.

Epistemology:

• Kinds of knowledge constructed:
  • Community activist history
  • Discursive and relational connections between struggles, between generations
  • Strategies for organizing
  • Strategies for teaching
  • Strategies for cooperative economics

• Trustworthiness:
  • Produced out of collaboration between elders and youth in activist organizations and from affected populations 
  • Histories are always political, and this history is clear about its politics: to accurately portray the local struggles in the Boston area from the activist perspective

• How shared:
  • Conversation and co-design, during the hackathon
  • Public display in the street, after the hackathon
  • Dissemination of documents and films

Values:

• Driving the process:
  • desire to teach about history of housing struggles
  • Importance of cooperative economy to local community empowerment
  • Importance of learning from elders and across organizational bounds

• Potential conflicts:
  • Different epistemologies, approaches between elders and youth
  • Multiple stakeholders with multiple interests: need to make sure everyone is heard and every stakeholder’s needs are attended to

Stakeholders and desired outcomes:

• Dudley Street Neighborhood Initiative
  • Desired outcome: gathering oral histories and local knowledge
• Boston Ujima Project
  • Desired outcome: gathering local history and examples of resident-led efforts to create tools for cooperative economic practices at the local scale
• Activist Film Project/Simeon Awosan 
  • Desired outcome: Activists to view raw footage of Chuck Turner & Mel King, give feedback, and suggest additional content
• Boston Community Learning Project/Ceasar McDowell
  • Desired outcome: Review and sort drop box file of notes and videos; gathering activist stories of Boston organizing to identify gaps and opportunities for public distribution
• Northeastern University Archives & Special Collections
  • Desired outcome: public engagement with current archives and acquisition of new stories/content  
• All stakeholders
  • Desired outcome: A way for residents and passersby to encounter the “archive” on the street, commemorating 50+ years of local activism, galvanizing support for future land battles and organizing efforts

This week, I am speculating about my project I am working on with Instituto del Progreso Latino in Chicago. I am using the framework outlined by Christopher Frauenberger et al. in their paper “In pursuit of rigour and accountability in participatory design.”

Epistemology

• Kinds of knowledge constructed
  • The biggest form of knowledge I see myself gaining is around the collaborative process. I hope that all project partners can learn more about what forms of communication and organization will work in this context to accomplish our goals of collecting and sharing out success stories from within the organization.
• Degree of trust in the knowledge
  • I hope that the stories we are able to collect as  result of this design collaboration feel genuine and connected to what’s actually going on in the city. I hope to enable the creation of stories that people trust and that people feel a personal connection to.
• Potential for transfer
  • It would be nice to see a workflow and supporting tools that could be shared freely online.
• Sharing of knowledge
  • I hope that I am able to help design a system of sharing and collecting stories from my community organization partner that allows community members and a wider public to see the assets and successes of Pilsen/Chicago.

Values

• Driving values
  • I think the driving values of this project are respect for community of Pilsen and equity in decision-making.
• Change of values in the process
  • I don’t forsee any changes of values in this process. But I do hope that project partners feel comfortable pointing out when values seem to have shifted unintentionally, or when they need to shift to respond to unforeseen circumstances.
• Reflection of values in the decisions
  • I hope that all decisions are agreed upon with regards to the goals and expectations of this project as agreed upon at the beginning of the collaboration process. I hope this shared understanding will contribute to mutual trust and shared ownership of decisions made. And I hope my project partner’s immersion in the community they serve help guide me to learn about any of my own blindspots I may have in my current position as a student at MIT.

Outcomes

• Different interpretations of outcomes
  • I hope the interpretations of outcomes are pretty well aligned, owing to work put in at the beginning of the collaboration to align expectations and goals
• Owner of outcomes
  • Instituto will be the owner of the outcome, though I hope that a process we come up with can be shared more widely to other organizations that might be able to benefit from what we learn.
• Sustainability of outcomes
  • I hope that the outcome of this project is a process that can be used for several years.

Stakeholders

• Stakeholders
  • Right now, the stakeholders in this process are the folks at Instituto and myself. It would be nice if
• Participants
  • I hope that we are able to share out the success stories of the community that Instituto serves in a way that affirms and creates joy. I also hope that there might be a way to share stories back with the community in a way that makes them accessible and enjoyable memories/commemorations.
• Benefits for stakeholders and participants
  • Instituto will have a tool/workflow that helps fill a communication need, and I hope the participants are able to feel celebrated and affirmed, and possibly have access to a recording of their success in an enjoyable way.
• End of project
  • When this project ends, I hope that I am able to integrate this work with other projects I am working on with Instituto, and help maintain/refine this project as needed. However, I do hope that this project can develop something useful for Instituto, that they are able to sustain without much outside intervention. I hope I can help share any lessons learned with other similar groups as well.

In this post I will describe a workshop course that I took last semester. I am keeping the details relatively vague for purposes of anonymity.

The focus was designing safety interventions. In this course we went through a design process: define the problem, understand the users, ideate, prototype, present. This framing separates the “designer” from the “user” of the design—it is clearly design for, not design with. The designers were totally isolated from the user community, as the user research component (phase two—understand the user) basically just consisted of interviewing people about their general feelings on safety. An orientation towards innovation was a given, as there was no attempt to look for what is already working. The “problem definition” framing at the outset exemplifies this.

We were then told to develop “personas,” imaginary users who could generate some use cases for our designs. This is sort of the opposite of the design justice principle to “center the voices of those who are directly impacted,” as we actually centered our voices even when we were supposedly designing for others. Though we were meant to assign real responses from our interviewees to our invented personae, we were essentially instructed to speak for an imagined other. In the ideation and prototype stages, our reference point was our personae, not any real user.

Certainly the design process was done with the best of intentions, and to some extent, design justice principles #1 and #9 were followed. But I cannot see how any of the others were—somewhat troubling for an introduction to MIT’s design philosophies.