A Civic Media Codesign Studio On Open Collectives

Comparative Media Studies 362/862, Spring 2020

First class on Tues Feb 4th: 6-9 pm
Room 9-217
Regular sessions: Tuesday evening, 7-10pm

Instructor: Marisa Morán Jahn 
mjahn AT mit.edu
Prereqs: One subject in CMS or MAS, or permission of professor
Enrollment: limited to 16. Open to both grad and undergrad 

The Civic Media Codesign Studio is a service-learning, project-based studio course where students partner with community-based organizations to create civic media projects grounded in real-world needs. Covers theory and practice of codesign, including methods for community participation in iterative stages of project ideation, design, prototyping, testing, launch, and stewardship. Projects are collaborative, interdiscilplinary, and team-based.
In the Spring of 2020, this course involves students in co-designing projects with “open collectives,” or self-organized communities whose digital and physical platforms harness 21st century tools and together share the goals of economic sovereignty and communal self-determination. The groups are as follows:

• Quipu is a micro-currency platform and physical marketplace empowering members of a low-income community in Colombia, 75% of whom are resettled victims of armed conflict.  
• Mosaic.us is an affordable housing construction collective pioneering the use of machine learning to simplify building assembly and facilitate communal barn-raising.
• CarePod, a care-based co-housing unit and strategy created with the National Domestic Workers Alliance.
• Re-appropriating the concept of the kibbutz to meet 21c urban trends, Communit offers low-cost collective living in abandoned buildings in a neighborhood known for its worker history and mixed, diverse population.

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.

Context, Outputs of listening methods

Existing web platform

The current website platform uses a WYSIWYG (“what you see is what you get”) visual editor. That makes it very user friendly for the staff, while limiting layout options, interaction possibilities, etc. It also includes features to schedule, make plans, and other procedural tasks common in the education sector. It also includes a built-in form creator, and response collection platform.

Existing success stories

Existing documented success stories have been collected largely for the purposes of annual reports. There are a few in the form of a paragraph-long third-person narrative and picture of someone who went through a program, alongside some statistics about that program as a whole. Others are a page long with an accompanying photo. These stories are all in English, and are not shared out with the community in a systematic way.

Examples from other community organizations

I looked at three organizations’ online presence to get an idea of how other organizations serving a Spanish- and English-speaking population share their work online. There were some useful ideas, but nothing that addressed the challenges in an ideal way. I might need to ask more people for resources/models to take inspiration from.

Literature Search

A Pew survey of US Latino news media sources suggests that using online methods might be a good way of reaching Millenials and Gen X Latino populations, with a lower share of Baby Boomers (though still a significant amount). That same survey also suggests that we should put materials online in Spanish to reach a foreign-born population, which community partners noted in observations of response when material is put online in Spanish.

current work process

The current process to collect success stories is pretty involved. It involves connecting with clients via program staff, interviewing the clients, asking for a photo submission, and writing it up to varying lengths for use in materials like an annual report.

Ecosystem Map

Highest priority personas

In thinking about this design project, it is helpful to think about a few key personas that we can imagine interacting with our design in some way. For this design, we are focusing on communications staff, Spanish-speaking clients, and funders.

Anticipated Challenges

Sustainability

One key challenge is that templates, workflows, solutions must be able to stand on their own. Ideally they won’t even require new accounts for free online services. Money, time, and energy are all valuable resources and the best effort needs to be made to conserve time and energy in a project without a budget.

Multiple Audiences

I have a sense of a tension between wanting to give funders a clearer idea of what Instituto does, as well as giving local community members a better idea of what Instituto does. The messages we would want to send to both groups come from the same place, but might need to emphasize different things or take different forms. I think a significant challenge will be coming up with a process that can either speak to both at the same time, or easily enough lead to multiple outputs from the same source material.

Next steps

• Talk with other people doing communications work within my networks.
• Create lo-fi prototypes for more concrete feedback from others at Instituto. None of the items mentioned above takes that much effort for me to produce an unpolished version with existing materials or placeholder text/media.

Questions for the class

• Have you seen any community organizations taking a bilingual approach to online communication, which could serve as a model?
• Do you have any ideas about how to make this process/outputs more relevant to educational programs and participants themselves?
• I feel like I’m a little too limited in my thinking right now. What are some wild ideas you have about this communication topic, without any regard to feasibility? I could use some out-there inspiration.

The Festival or Counter Atmospheres is a 4-day event in June that will take across three public sites in Boston: Upham’s Corner, Downtown Crossing, and Copley Square. The purpose of this festival is to activate spaces for public-making – where familiar and unfamiliar people can come together to engage with familiar and unfamiliar activities. Through forms of verbal discourse, such as panels and discussions, as well as other forms of discourse, such as art-making, play, and food, we hope to spark new ideas, conversations about difficult issues, and a stronger sense of a right to the city and its public-in-theory spaces.

Design Brief: https://docs.google.com/document/d/1zg3FHCFkuITiq_ubthIFrit2AhENkjkxDJwi-enWrIA/edit?usp=sharing

Presentation: https://docs.google.com/presentation/d/1LxJHrOTslTQhQfkwN3i0TwY3jenoNGU70p3bzr8UqQQ/edit?usp=sharing

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 .