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.

TL;DR

I participated in Hack for Inclusion this weekend, and this is what I found to be successful and lacking from a Design Justice perspective:

What was successful:

• The event focused on using design to sustain and empower our communities.
  • This was reflected in the challenges that the Hackathon centered around.
• Everyone felt like an expert.
  • On my team, everyone had meaningful ideas and skills to contribute. And this includes people we reached out to for interviews.

What could be more engaged:

• The event could enable more community-led and controlled outcomes.
  • Apart from user interviews, we had no interaction with the actual community we were working on a solution for. And that was part of the issue — it felt as though we were building for a community rather than building with a community.
• The event could further encourage engaging with existing community solutions.
  • During the research stage, the emphasis was completely on identifying problems rather than identifying existing solutions. During the prototyping stage, the emphasis seemed to be on building something new and novel.
• The event could place more emphasis on “change as emergent from an accountable, accessible, and collaborative process” rather than as a point at the end of a process.
  • At the end of the hackathon, everyone presented their “solutions.” And while the organizers did encourage people to continue building and refining their solutions, there was no accountability otherwise.

This past weekend, I participated in Hack for Inclusion. While I’ve done coding hackathons before, this was my first design hackathon. This hackathon was much more structured than ones I’ve done in the past, and it was also split into two days rather than being an overnight affair. Before the hackathon, we got to rank three questions we were most excited to tackle. I ended up being assigned to my first choice (which was not the case for everyone, so I’d say there were varying levels of enthusiasm on my team), which was fostering inclusive commercial development in Somerville.

Throughout the hackathon, all the teams were essentially guided through the “human-centered design” process, from user research to prototyping. For many steps of the process, we were given around 30 minutes to an hour (with the exception of prototyping, for which we had several hours). Our team was also assigned a mentor, who was a government employee working on development in the City of Somerville. During the process, she offered us feedback and gave us more context about Somerville from her own experiences of working with developers and business owners.

Each step of the design process felt very rushed, and my team definitely struggled to reach consensus at times. We all came from very different backgrounds career-wise (academia, law, consulting, non-profit) and identity-wise. I really appreciated getting to meet and collaborate with this diverse group, but the social friction was high at times. This reminded me of Lily Irani’s piece last week, on how hackathons often promote low-friction environments where you can quickly come to consensus and build, build, build. Funnily enough, every time our team took some time to come to a consensus, someone on my team tried to emphasize the “move fast and break things” mantra.

Because we were given, by far, the most time to prototype, I think this led most teams, including ours, to focus on building a solution rather than taking time to understand the problem. I felt that the short hour we had to conduct and reflect user interviews was not enough (and I also took issue with the fact that we were encouraged to cold call business owners for interviews…1) do these business owners have time for spontaneous interviews on a Friday? 2) without prior relationships and trust building, how much information would they be willing to disclose? 3) there was no accountability in terms of us following up with them and sharing the potential solution we were working on). After some brainstorming and a lot of conversation, we realized how little time we had left, so we quickly decided to focus our solution on building a local community fund that could support minority business owners who need capital (and might be excluded from traditional forms of capital like bank loans) to grow their businesses. I thought this solution was promising, but we got caught up in the rush of feeling like we had to build a “product.” So we ended up framing the idea as a mobile app (which in retrospect, was a lazy solution that won out over other ideas we had for in-person relationship building between business owners and the city…and totally perpetuated technochauvinism). I distinctly remember someone from my team saying that we needed a “flashy” solution to impress the judges. 🤦🏻‍♀️So, yes, we ended up presenting this app called SomerFund:

Overall, I learned a lot from this event. Was our solution a success? Not really. Did we really contribute meaningfully to minority business owners? No. Was this overall event successful? I think that will only become more clear after following up with teams in later months to see if any community relationships were sustained. But I was inspired by the ideas we had during our brainstorming process. It was great to meet people outside of MIT. I learned more about Somerville. And it was ultimately a good space to reflect on principles of design justice, and how (or whether) a short-term hackathon can lead to meaningful, community-led design solutions.

Hi everyone! As I’ve been working with the Black Mother’s Breastfeeding Association in Detroit, we have been brainstorming ways that a “hackathon-style” event could support their work. During our last meeting, we’ve started brainstorming a distributed hackathon during Black Breastfeeding Week on August 25th-31st. While the Project Director is tinkering with the budget and exploring capacity, I started to research and collate distributed hackathon models to learn from here: http://bit.ly/distributedhackathons. If anyone knows of former events I can learn from or organizers I can connect with- I super appreciate the support. Thank you!

(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.

While working at Optum (United Health Group,) I was part of a medium sized team tasked with guiding the development of an app to help veterans re-acclimate to civilian life. We conducted interviews with veterans, organizers, and veterans’ family members. We compiled our findings, debated what they meant, and ultimately, provided a laundry list of features to the development team.

Only insiders were involved in the design work.

• Designers were all employees of Optum. This manifested more technical solutions than were called for.
• Designers were mostly male, and mostly white or eastern asian.
• Design conversations took place in Optum’s corporate headquarters, in a locked room. Not even all employees were authorized to enter.

I think this stands out to me now that I’m not in that environment. At the time, I was happy to be interviewing people in the real world, and thought that human centered design was the best that we could do. It was more empathetic than the other work I had done at Optum, which was mainly focused on efficiency in our call centers. In hindsight, it is a shame that no impacted veterans were in the room when we were debating the features that were and were not useful. Something tells me that they would have shot down many of the ideas that us 20 somethings thought were appropriate.

The product shall be an app.

When interviewing the veterans, it became clear that they already had substantial assets for their recovery. These were often support groups hosted in their local church basements, and friends willing to be on call in a crisis. The whole time we were compiling our interview results, it was very clear that the expected output of our time would be plans for an app. With that in mind, we set to work creating features. Small groups imagined calendar helpers, gamification of therapy, enhanced chat clients, and more.

Ultimately, the one feature that did get implemented was a video series — pretty low tech. This was a bit of an about-face on the design team’s part, but a good one in my opinion. In the end, though, we shouldn’t have spent a whole week talking about apps. It was abundantly clear from the interviews that mobile apps were not a welcome approach. If we hadn’t wasted so much time trying to imagine a mobile app, we may have been able to provide something better than a (very basic) video series.

Lack of true institutional support.

Some part of me feels like the whole endeavor was akin to government hackathons “as an exercise in the State feeling good about itself.” If United Health Group really wanted to get behind veterans re-entering society, they would support the organizers that we interviewed rather than trying to commodify their insights in an app.

Conclusion

The fact that this design endeavor was pursued by a corporation seriously compromised it in terms of design justice. The well from which we drew our designers was seriously tainted by racial bias in hiring. The problem we were trying to solve was framed as something that must be solved with technology from the beginning, but ultimately, was not. The project was shuttered about 6 months later. This was touted as a win — we “failed fast.” At least we did no harm. I’m not entirely sure that we had to fail, though. By including the insights of our interviewees in a more meaningful way, we could have potentially helped them to make a positive difference in their comrades’ lives.

Hello everyone!

Hi everyone, I’m a research fellow at the Berkman Center, working on developing framework for UX, cultural context, and technical feedback for open source public interest projects. 5 years ago I founded a non profit organization called Localization Lab that works on tech adoption through collaborative localization. Before starting the organization, I often encountered developers not interacting at all with the end users, sometimes over years of product development. This not only has a huge impact on the usability and security of the tool, but also on the diversity of the user base, as they are not involving people from the focused group as an integral part of the process. On the other hand, the people from these communities, who often come from developing countries, also miss out on socioeconomic opportunities that come with having some experience working on a product, design, coding, or project management. We do co-design through structured exercises with end-users, UX designers, and developers, and I’m looking forward to learning the history and different theories in the class.

So, I want to move away from the equity in access to technology to the right to participate in the technology.

I want to incorporate principles of co-design with developers we work with, because so often we see this colonial narrative in public interest tech where developers know what’s best for end users without seeking their input or cooperation. I want to offer some principles applicable to all the projects that we work on, to make them more usable and more secure. I would love to see this as a principle in international development too, where there is a similar problem in the right to participate in the design, solutions, and development of one’s own community.

Hi all, good to meet you last week. My name is Hannah and I’m a data visualization and mapping freelancer and organizer. In my work I support non-profits, journalists, and organizers in using data to better understand their research and tell compelling stories about it. I’ve worked in reproductive justice//abortion access, urban planning and community development, and Palestinian solidarity and anti-militarization. In my unpaid projects I organize with an anti-police and anti-surveillance collective in Boston, support a rapid response anti-doxxing crew, and organize community safety systems in my Jewish community. I live in a beautiful lil coop house and like to knit and care for my sun-starved plants.

I’m in this class to fight against the lonely freelancer life and work with some other brilliant folks in the service of movements that matter to me. Some ideas bouncing around include creating a secure intake system to level up the anti-doxxing work or designing workshops/events to support in collecting community testimony about experiences with the Boston police. The creative archival work celebrating 40 years of Wake Up the Earth also sounds interesting! I’m excited to hear what other folks are excited about and what we can create together this semester.