Content uploaded by Alex Ahmed
Author content
All content in this area was uploaded by Alex Ahmed on Apr 17, 2021
Content may be subject to copyright.
Online Community-based Design of Free and Open Source
Soware for Transgender Voice Training
ALEX A. AHMED, Northeastern University, Project Spectra
BRYAN KOK, Project Spectra
CORANNA HOWARD, Project Spectra
KLEW STILL, Project Spectra
This paper describes Project Spectra, a collective of open source developers that aims to build free and open
source voice training technology for transgender people. We demonstrate how a design prioritizing the agency
of trans users was made possible through sustained community collaboration. Using an autoethnographic
approach, we discuss our community-based design process, which was documented with memos, online
meetings and text conversations, sketches, and other data sources. We illustrate how we articulated our values
as a group: deciding our programming framework (including a Statement of Principles), elaborating our
“Experience Goals” (the feelings we wanted our design to elicit), and determining the features we wanted to
implement in our app. We conclude with a reection on the benets and challenges of conducting community-
based design research through an open-source organizational model.
CCS Concepts:
•Human-centered computing →Participatory design
;Collaborative content creation;
•
Social and professional topics →Gender.
Additional Key Words and Phrases: community-based collaborative design, free and open source software,
transgender, feminist epistemologies, autoethnography
ACM Reference Format:
Alex A. Ahmed, Bryan Kok, Coranna Howard, and Klew Still. 2020. Online Community-based Design of
Free and Open Source Software for Transgender Voice Training. In CSCW ’20: ACM Conference on Computer-
Supported Cooperative Work, October 17–21, 2020, Minneapolis, MN. ACM, New York, NY, USA, 27 pages.
https://doi.org/10.1145/1122445.1122456
1 STATEMENT ON RESEARCHER POSITIONALITY
Throughout this paper, rst-person singular pronouns (I,me) are used to indicate the rst author of
this paper. First-person plural pronouns (we,our) refer to our collective broadly, and also specically
to those of us who volunteered to contribute to this paper (the authors). I cannot separate my
own identity, concerns, and values from how the work was conducted. This work pays particular
attention to how my own social location and academic position inuenced the design process and
its outcomes. Ultimately, we hope to paint a holistic picture of our organization and faithfully
represent its members.
2 INTRODUCTION
Human-computer interaction (HCI) researchers are increasingly taking critical stances towards
participatory design (PD) methods – such as workshops, focus groups, and “blue-sky” ideation
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee
provided that copies are not made or distributed for prot or commercial advantage and that copies bear this notice and
the full citation on the rst page. Copyrights for components of this work owned by others than ACM must be honored.
Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires
prior specic permission and/or a fee. Request permissions from permissions@acm.org.
CSCW ’20, October 17–21, 2020, Minneapolis, MN
©2020 Association for Computing Machinery.
ACM ISBN 978-1-4503-XXXX-X/18/06. . . $15.00
https://doi.org/10.1145/1122445.1122456
1
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
exercises – arguing that they reinforce dierences in power between researchers and participants
[
40
,
42
,
57
,
62
]. Despite the ostensible benets of opening design processes up to individual and com-
munity engagement, such attempts are fraught by histories of institutional racism [
40
], colonialist
narratives of “development” [
43
], and the outsized inuence of corporate power under capitalism,
from which academia is not exempt [
33
,
41
,
46
]. These histories of oppression have marred attempts
to design collaboratively, especially with marginalized people.
This paper builds on existing literature that critiques and reects upon participatory and
community-based collaborative design methods [
6
,
14
,
40
,
62
]. For example, Harrington takes
the “design workshop” as their object of analysis, citing examples of how the practice “misalign[s]
with the lived experiences of underserved communities” [
40
]. Participants recounted histories of
mistreatment from the institution with which the researchers were aliated, and described the
design activities as “childish.” The authors argue that these tensions undermined PD’s potential as
a “democratic mechanism to respond to societal challenges,” and that “reconstruction” is required
to more closely align PD with community-based participatory research (CBPR), a methodology
that aims for co-ownership and non-hierarchical, sustained collaboration between researchers and
participants.
Whereas prior work focused on in-person collaborative methods, we will describe the possibilities
and diculties in facilitating a long-term community-based collaborative design project online.
We ground this discussion in the context of designing and building a free and open source voice
training app, with and for transgender people. We build on prior work exploring the voice- and
technology-related values and challenges that trans people face [
35
,
36
,
45
,
63
]. We argue that,
given the widespread marginalization of trans people, it is essential for computing research to not
only include us in design processes, but also to create sustainable structures for us to own and
control the work from top to bottom: from sketching and brainstorming to prototyping, testing,
and implementation.
We present Project Spectra, a collective dedicated to free and open source software (FOSS), which
is a paradigm for the development of asynchronous, collaborative software development. FOSS
primarily centers on code, not usability [
32
], and is not often used in HCI [
24
]. Despite a tendency
towards openness, signicant barriers preclude participation, particularly for women and people
without technical skills [
54
]. We further existing research studying FOSS development cultures and
practices from an HCI lens. Over the course of one and a half years, I (the rst author) documented
Project Spectra’s design process – which included meeting notes, key decision points, and my own
personal reections – as a series of design memos. These memos, which contain sketches, code
fragments, co-written documents, and screenshots from our app, serve as the primary data sources
for this paper. I use autoethnography, a methodology that seeks to “describe and systematically
analyze personal experience in order to understand cultural experience” [
27
]. Using my design
memos as autoethnographic eld notes, this paper explores the following questions:
•How did our organization work, and how was it structured?
•How did our design process shape our app, both functionally and aesthetically?
•How did my position as an academic researcher shape the design process?
In doing so, we hope to support researchers and practitioners in conducting community-based
collaborative design projects through a case study focused on transgender voice. However, this
paper does not – and ethically cannot – capture, summarize, or otherwise describe the beliefs,
feelings and perspectives of each member of Project Spectra. Instead, I combine autoethnography
with a feminist epistemology, centering “subjectivity, emotionality, and the researcher’s inuence
on research” [
27
]. Following Rosner and Haraway, this paper “stays with the trouble,” focusing
on moments of diculty, contradictions, and breakdown [
37
,
62
]. In summary, we
contribute
:
2
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
(1) an application and reection of an online collaborative design process; and (2) an overview of
our eort’s outcomes: the design goals, user testing, and implementation of a novel voice training
app for trans people; (3) a set of recommendations for researchers and practitioners interested in
community-based collaborative design.
3 RELATED WORK
This paper draws from, and builds on, two main lines of current thinking in CSCW: community-
based collaborative design, and understanding the conditions under which interactive systems
both support and harm transgender people. Calling on the work of queer and trans scholars and
activists, I describe how increasing public visibilty and acceptance of trans people is contingent
on normative gender performance. Finally, I set the stage for the current project by describing
trans voice training: the current clinical practices and objectives, as well as the resources and
technologies that currently exist.
3.1 Design Methods and Their Discontents
PD’s democratic origins in the labor movement have been well documented [
8
,
47
]. The methodology
ideally seeks to characterize participants’ existing practices, understand their needs and values,
and translate that information into concrete recommendations. The tools of the trade here are
typically qualitative, in-person, and limited in duration: in-depth interviews, focus groups, and
surveys feed data into task analyses, personas, and design goals. These techniques ostensibly inject
human needs and values into how technologies are produced.
However, recent work has shown how PD methods are part and parcel of exploitative systems,
specically in the context of HCI researchers working with underserved populations. Harrington
et al. [
40
] examine issues of access, equity, and harm in the context of the “design workshop,” a
traditional PD method, in a predominantly Black neighborhood in the Midwestern United States.
The design workshop, they describe, is a “spatially situated and temporally bounded coming
together of participant groups and researchers to envision new design futures.” Grounded in a
community-based collaborative design methodology, they aimed to explore understandings of
health and potential tools for health maintenance [
39
], and reect on their process [
40
]. Ultimately,
the workshops were fraught by legacies of institutional racism that could not be separated from the
researchers’ current work. One of their participants said, “You know I’m old enough to remember
when Northwestern would use us for studies but we couldn’t get medical help. I remember. And this
was after Tuskegee, knowing what they did. So, I have right to have my doubts.” The researchers
conclude by arguing for more equitable forms of PD through greater accountability, reexivity, and
acknowledgment of community history.
Rosner [
62
] describes the limitations of traditional PD by reecting on how she designed a
technology for knitters. She discusses how she began her research training with the “IDEO model”
– empathize, dene, ideate, prototype, test – and how she internalized those ideologies. Rosner
argues that this creates and sustains a distance between designers and the people being designed for.
In other words, participants tend to be briey part of the design process, during which time their
experiences and understandings of the world are extracted from them, and after which researchers
apply that knowledge to further their own goals and agendas. The products generated from this
process are prone to failure, and may not be needed to begin with [
12
,
40
,
67
]. Bennett [
14
] shows
how the cornerstone of the IDEO model, empathize, denies the agency of disabled people. As a
result, empathy exercises “may appropriate disabled people’s techniques and experiences while
rendering them non-designers through their disappearance. When designing for disabled users,
such empathy work congures designers as dierent and isolated from the empathized.” A distance
between elite “innovators” and “others” assumes that a technological solution is needed [
9
], that
3
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
these are two mutually exclusive groups of people, and that it can only be successfully built by the
former [42].
Notions of agency and self-determination feature prominently in all of these accounts. Rather
than being an abberation or accident, systematic denials of agency and power are part of HCI’s
founding ideology, and its ties to global capitalism and colonial histories [
42
]. However, scholars
have begun to articulate alternative visions for design and evaluation. Asad elaborated “pregurative
design” as an explicitly political framework for “negotiating more just collaborations between
researchers and community collaborators” [
6
]. By forging relationships focused on harm, healing,
and transformation, Asad calls on researchers to “[co-create] counter-structures” that replace
oppressive institutions. Harrington argues for a “reconstruction” in which HCI researchers address
the “methodological challenges” to traditional PD arising from structural injustices [
40
]; similarly,
Keyes et al. urges a “reorientation” of HCI towards creating “systems and spaces that exemplify the
world we wish to see” [46].
Taken together, these provocations show a collective desire for a radical transformation in HCI.
I argue that more methodological work is needed to accomplish this, work which must reckon
with the material conditions that structure who precisely has the power to make decisions about
the design and implementation of technologies. My goal is to provide just such an intervention,
specically within the context of building technology with and for trans people online. The following
sections will describe this context in detail.
3.2 Trans People and Technology Design
A growing body of work in HCI centers on how trans people navigate, and are impacted by, existing
technologies. For example, Haimson et al. [
34
] investigated how trans people navigate identity
disclosures and gender transitions on social media. The authors show how trans users assert and
navigate multiple identities across dierent platforms, and struggle to nd in-group connections
while simultaneously avoiding transphobic
1
harassment. Prior research also implicates the social,
cultural, and political phenomena that structure trans peoples’ relationships with technology. Keyes
[
45
] shows how automatic gender recognition (AGR) algorithms model gender as strictly binary
(thus erasing non-binary people), and how these technologies are tied to gendered surveillance and
police violence. Via qualitative analysis of interviews with trans people, Scheuerman et al. [
63
]
describes six overlapping forms of harm: insider (within-group) versus outsider (out-group) harm,
individual versus collective harm, and targeted versus incidental harm. The authors conclude that
designers should “examine the very structures of their technological creations” and “access the
rich history about intersectional marginalization... so they can understand how to sensitively fold
them into new policies, practices, and software encodings.” This valuable work disrupts reductive
understandings of technologically-mediated transphobic violence at both the interpersonal and
societal levels.
It is clear that no technological solution can address the multiple intersecting systems of harm
described above. However, prior work has attempted to create targeted interventions for specic
issues that transgender people face. In addition to this academic work, hundreds of commercially-
and freely-available apps have been created for trans users (a review of these is outside the scope
of this paper; see [59]). I focus here on apps designed to support trans peoples’ health and safety.
Beirl [
11
] describes the development of a bathroom safety and support app called GotYourBack,
which provides a list of bathrooms near the user’s current location, and uses crowdsourcing
to provide a rating on how safe people felt in them. Designers rst conducted semi-structured
interviews with trans people, constructed an anity diagram, and performed a task analysis. They
1Anti-transgender
4
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
then sketched prototypes and created a survey to elicit feedback on them, which was posted on
“specialist forums”; the survey was also “shown” to trans people who had participated in their
research. Their nal design was reached via paper prototype evaluations (it is unclear whether
trans people were included in this stage). Starks [
66
] conducted nine interviews with trans women
and non-binary people of color, which informed the design of the safety app U-Signal. Participants
shared that they wanted “no involvement” with the police due to misgendering and harassment; to
address this, U-Signal allows users to share their device’s location with their personal emergency
contacts. The authors’ describe their design process as a “human-centered approach,” and involved
semi-structured interviews. The initial interviews were with “one expert and one non-expert, which
informed the initial design.” Additional interviews were then carried out to understand participants’
experiences with anti-trans violence, and obtain feedback on their prototype.
Outside of HCI, in the eld of medical informatics, LeGrand et al. [
49
] describes Epic Allies,
an mobile game designed for cisgender men and transgender women to support adherence to
anti-retroviral therapy medications for HIV. In the game, users play as superheroes who are ghting
monsters in the ctional city of “Medopolis.” Periodic medication reminders and HIV-related
information appear within the app; users can also track their dosages over time. Epic Allies was
designed using the “Information, Motivation, and Behavioral Skills” model of behavior change; under
this model, each app feature is geared towards one of those three pillars. The development team
consisted of health researchers and an external “technology team” of consultants and programmers
“with expertise in app design.” The team created an initial concept on its own, and then conducted
three focus groups of 20 Black men who have sex with men – the “target population” – to assess
“adherence information, motivation, and behavioral skills needs,” and obtain feedback and iterate on
their prototype. An independent group of 7 men were recruited for task-based usability testing, to
assess “participants’ ability to successfully navigate the app, comprehend the educational content,
and determine if they found the app to be engaging and relevant.” A successful evaluation, the
authors write, would support “the planned commercialization of Epic Allies” and “justify the costs
invested.”2
All of the above design processes prominently feature experts (whose expertise is rarely de-
scribed and never questioned). Trans people serve the primary role of educating designers on
their experiences, such that the latter may understand, empathize with, and design for the former.
My intention here is not to disparage these research contributions; in fact, the rst author’s own
work has been structured by similar ideas [
3
]. My goal is rather to emphasize the epistemological
distancing between researcher and subject, which Bennett describes as “knowing the Other” [
14
].
In Epic Allies, this distancing is pronounced to the level of complete erasure: not only were trans
women (and cisgender men) not consulted in the initial creation of the prototype, but the app was
designed using focus groups, feedback, and usability evaluations with cisgender men only [
49
].
Although trans women were not mentioned in the design study, future stages of the project will
recruit both cis men and trans women who have sex with men in a randomized control trial to
determine the app’s eectiveness [
50
]. The authors combine trans women and cis men together
as part of the same target population, conating them based on the gender of their sexual parters
despite that they have unique needs and face dierent types of social oppression (which is a noted
issue in HIV prevention/intervention research; see [
60
]). The authors do not indicate whether the
design will be modied as a result of the inclusion of trans women, and only state that the app was
developed “with input from the target population.” These studies exemplify a trend in HCI and
2
This mention of commercialization and economic justication appears out of place in an academic paper, and recalls Irani’s
argument that so-called “human-centered” projects serve “not as an orientation toward compassionate solidarity but rather
as the mining of intimacies for projects of value creation.”
5
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
medical informatics research, wherein users are consulted simply as a means to a technological
end, rather than as partners and co-creators. As Irani writes, designers often “invited users to
exercise inuence, but they rarely shared design control with users” ([
42
], emphasis in original).
This paper asks: what possibilities are opened when trans people design for ourselves? What are
the consequences when we are left out of the loop? What challenges might we encounter?
3.3 Gender Presentation and Expression
This section will briey describe the context for the current project: the purpose and practices of
trans voice training, as well as gender presentation and expression more broadly.
3.3.1 Trans voice training. A 2015 survey indicated that 62 percent of transgender women in the
United States have either had voice training or currently want to have it [
44
]. However, that survey
and other studies [
25
,
31
] also indicated that trans people are impacted by high rates of societal
discrimination, targeted assault and violence, homelessness, harassment from medical providers,
denials of insurance coverage, and health disparities related to access to care. For trans people,
voice can be closely tied to survival in terms of both mental and physical health. Trans people may
nd themselves held to a standard of what constitutes an appropriately gendered voice and be
judged and addressed incorrectly, or potentially harassed and assaulted. Recent studies indicate
that trans individuals are more likely to be victims of targeted assault and violence than the general
population [
44
], and this fact can inuence the way trans people perceive their own voice and their
decisions to train it [3].
Dacakis [
20
] notes that the perspective and individual needs of the client must be included when
evaluating outcomes. This focus relates to prior work examining constructions of identity in health
and illness. Notions of identity are essential to trans individuals’ health; voice can play an important
role in both identity and health [
21
,
38
]. Despite this, it is important to recognize that voice is just
one element in how an individual presents themselves. Furthermore, voice alone cannot predict
how a trans person experiences the world, whether they are recognized as they desire to be, or
their health outcomes more broadly (it may not be a factor at all for some individuals).
3.3.2 eer and trans theory. The clinical literature on trans voice training paints a one-dimensional
picture of voice training that attens out the personal, social, and political complications of gender
expression. Such studies often limit their inquiry to the eectiveness of voice training for “trans-
sexuals” [
17
,
20
,
22
,
38
,
72
]. This language emphasizes a medical denition of transness [
70
]; in
other words, the studies’ recruitment pools appear limited to trans people who have undergone
medical gender transition (hormone therapies and/or surgeries). Not only is it unclear whether and
how to apply the results of the existing speech therapy literature to gender non-conforming and
non-binary people, this also shows how the production of academic knowledge about trans people
is structured by normative understandings of gender transition and expression.
Trans scholars have described how people must conform to particular social norms in order
to “successfully” present as their desired gender [
10
,
64
,
69
]. For example, a trans woman might
present in a more stereotypically feminine way than she otherwise would to secure access to
gender-conrming medical services [
64
] or to avoid attention from law enforcement [
3
]. But what
– and who – is lost through these normalizing forces, and who benets from them? Everyone – not
just trans people – are subject to regulatory gender norms, which are predicated on “the perceived
deception underlying transgressive gender presentations” [
10
]. Casting gender non-conformity as
deceptive has specic, sometimes lethal consequences for trans people [15, 71].
In his thorough analysis of vocal gender performance, Pennington writes that trans people
are used to represent “the performed nature or constructedness of gender, which only serves to
delegitimize their gendered identities while simultaneously rendering invisible and naturalizing
6
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
the gender construction of cisgender people” [
58
]. Pennington reverses this harmful dynamic by
focusing on the vocal (gender) performances of cis people, using transgender “passing guides” as
an analytical tool. As Pennington writes, trans passing guides are often created by trans people to
make “unconscious habits conscious again, so that a new set of gender vocalisms can be learned
and internalized” [
58
]. The existence of these community-made guides can be seen as tools of
assimilation, armation, and/or survival; trans people vary widely in whether, how, and when they
adopt gendered norms of speech in their everyday gender expression [
3
]. As Haimson [
34
] describes
through the concept of liminality, trans people in transition “exist multiply,” holding “multiple,
fragmented, and complex” identities both online and o. Haimson urges technology designers
to account for this complexity in their work [
36
]. When it comes to voice training technology,
however, the current options largely reduce vocal gender transition to an uncritical reproduction
of gendered stereotypes [4, 69].
3.3.3 Existing voice training technologies. Unlike passing guides, trans voice training apps are often
for-prot and developed by clinical speech therapists who are cisgender, white European/American
women [
51
,
52
]. As shown in prior work, these apps often perpetuate normative, racialized, and
classed gender categories [
4
]. EVA [
51
], for example, features a stereotypical pink/blue color scheme
(depending on whether one downloads the version for trans women or trans men, respectively),
and uses photographs of apparently white, auent, gender-conforming people as background
images. Functionally, the software assumes a singular and unchanging transition goal: a “female”
or “male” voice; user customization is non-existent. The speech therapist’s personal brand also
strongly inuences their app’s design and functionality, and thus the user experience. In the app
Christella VoiceUp, the app encourages users to “nd out how [therapist] Christella [Antoni] can
help you” using the “Antoni M2F Voice Change Model” [
52
]. The identity and qualications of
the speech therapist are highlighted through images, text, and video lessons (available through
in-app purchases). One app features an “About” page with her photo and qualications [
51
]. As
the deliverer of information, the speech therapist positions herself as an ambassador to the user’s
gender enlightenment.
These clinician-driven apps dier signicantly from other oerings. Voice Pitch Analyzer [
61
], a
popular free and open source voice training app for Android smartphones, allows users to read
a passage of text and see their pitch in comparison to normative gendered ranges. Although the
for-prot apps described above also provide this feature, Voice Pitch Analyzer is free (of charge,
and of gendered color schemes). It does not assume that the user has a particular gendered goal,
nor can the user specify one. Additionally, trans people interested in training their voices use a
number of no-frills apps that are not specically designed for trans people, but that simply provide
a visualization of the pitch or resonance patterns of the user’s voice.
As I have shown in prior work, trans participants described how their willingness to use a system
hinged on whether or not it interfered with their ability to make their own decisions about their
lives [
3
]. Normative gender roles and transition narratives inuenced how participants thought
about their own transition, and participants talked about how they are often marginalized in – and
distrustful of – social and medical institutions. Potential designs aiming to support trans people
must understand the systematic denials of agency that result from living in a transphobic society,
thereby facilitating the creation of artifacts that respect these concerns.
4 PROJECT SPECTRA
With the above context established, this section will describe Project Spectra, a collective of open
source developers working to build trans voice training software since July 2018. We begin by
describing the platform and practices under which we worked, what we created (along with why
7
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
and how), and reect on the process through the lens of community-based collaborative design.
We end by discussing what our work means in the context of the sociopolitical systems described
above. A full elaboration of Project Spectra’s functions and features is beyond the scope of this
paper (for the source code and app, please see [
2
,
68
]). We will touch on some of the major design
elements here only insofar as they shed light on the design process.
4.1 Autoethnographic Data Collection
This paper draws from my design memos to understand and communicate how Project Spectra
works, and my role within it. Autoethnography has been previously used to reect and report on
research processes, to push towards “a more just experience” for research collaborators [
7
]. With
this intention, this paper uses an autoethnographic approach, which ultimately seeks to “describe
and systematically analyze personal experience in order to understand cultural experience,” and
which “acknowledges and accommodates subjectivity, emotionality, and the researcher’s inuence
on research” [
27
]. Contrasted with ethnography writ large, Ellis writes, autoethnography does not
involve a researcher observing and documenting an “outsider” culture, but rather writing about
experiences “that stem from, or are made possible by, being part of a culture and/or by possessing
a particular cultural identity.”
While I worked with Project Spectra, I created 28 “design memos,” which were written and stored
in Google Drive and accessible to all Project Spectra members. Early on, entries were recorded
within this document on a weekly basis. Beginning in January 2019, memos were recorded on an
ad-hoc basis (sometimes multiple memos per week, as needed). The content of the memos cover
all aspects of the design process: technical/code issues, meeting notes, critical decision points,
questions and discussions related to voice training pedagogy and practice, speech processing
algorithms, and interface design/sketches. I also used the document as a space for theoretical
reection on our design process, its successes, and its challenges. I consider these design memos as
autoethnographic eld notes, which document events as I experienced them, and as “in-process
memos,” which “[allow] the eldworker to develop analytic leads and insights” [28].
I use these memos in an eort to provide an honest and respectful description of our work as
I experienced it, as well as to inform researchers and practitioners interested in designing trans-
competent software, trans voice training software, or online community-based collaborative design
more broadly.
4.2 Membership
Invitations to the Project Spectra team were extended when any person expressed interest in
joining; no technical or other experience was required. Potential members were contacted by
current members through social media networks, primarily Twitter and Discord
3
. Discord is a free,
proprietary chat client primarily geared toward gamers. Users can create “servers” containing any
number of chat channels, where members of the server can communicate via text, audio, or video.
Servers operate independently, but Discord users can be a member of multiple servers at once.
After initial contact, I typically met with the person (via phone, video chat, or text) and discussed
their backgrounds and goals, interest in the project and its current status, and ultimately asking
whether they would like to be involved and in what capacity. Either during or prior to this con-
versation, I invited them to look over some of our documentation, specically our Principles and
Goals (see below). I also explained the following:
•No amount of participation is required or expected by virtue of their joining the team.
•I am a graduate student who is doing this work as a component of my thesis project.
3https://discordapp.com
8
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
•
Our primary goal is to create this voice training app, but we also strive to create an environ-
ment of mutual learning and support.
Project Spectra members brought our own expertise and perspective to bear on the project in the
time and capacity we had available. As such, some members focused on contributing design mockups,
speech analysis algorithms, front end development, big-picture feedback, or some combination
of these. We also asked several people to provide feedback and guidance to the project either in
one-o or recurring timepoints, but they did not participate in regular communications. These
included speech therapists, HCI researchers, and trans people interested in voice training.
Although this project was approved by Northeastern University’s Institutional Review Board,
written informed consent was not required to be a part of the Discord channel and to participate
in group activities, and was not obtained. As a result, this paper does not reproduce quotations
from members. Information about group members, demographic or otherwise, was not formally
collected. Members also did not need to share their names or other aspects of their identity – though
they sometimes did – to participate in the group. Members did not receive any compensation for
their participation in group activities. All communications with group members and on our public
channels were in the English language.
In March 2020, current Project Spectra members were informally polled and asked to share
details about their age, gender, racial identity, and extent of their technical skills. Nine members
of the group responded to the poll. The mean age of respondents was 29 (SD = 6.91, range =
21-40), participants’ gender identities included transfeminine, non-binary, and gender questioning.
Respondents identied themselves as white or Caucasian (3), Asian (2), mixed/multiracial (3), and
East Asian (1). In terms of economic class, responses included upper middle class, to middle class,
and working class. Finally, respondents were asked to rate the extent of their technical skills from
1 (no coding experience) to 5 (professional/expert programmer). The mean score was 3.8 (SD = 1.2).
4.3 Collaboration Tools
We used a combination of freely available tools to collaborate online. Because there was no co-
herent set of tools or platforms determined at the outset, we explored potential options together,
sometimes discarding them completely if they stopped being useful or suitable to our needs. Project
Spectra’s main workplace is Discord, which was chosen because two large (>1000 members) trans
voice training communities already existed there. Our server contained general channels such
as “#workspace,” “#design,” and “#engineering,” and also separate channels for meetings, such as
“#2019-04-26-general.” Members also communicated outside of servers through direct messages.
Between July 2018 and November 2019, we convened six general meetings, two code review meet-
ings, and two design meetings. We also met during loosely scheduled “coworking hours” in which
members could drop-in and drop-out as they liked.
In addition to communicating asynchronously on Discord, we used Google Drive to share
documents, sketches, mockups, notes, contacts, and other resources. We also used Google Forms
to create and share user testing surveys. For code collaboration and version control, we created
a Github organization
4
, which houses public code repositories. Through Github, we also logged
issues and bugs and assigned tasks. All team members had – and continue to have – full ownership
access to the Github organization.
We started by using Sketchboard
5
for digitally sketching potential screens and speech data
visualizations, and for creating owcharts for how those screens would connect to each other. We
4https://github.com/project-spectra
5https://sketchboard.me
9
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
Fig. 1. App flowchart created using whimsical, May 2019. Each app screen or interaction is color-coded with
respect to our Experience Goals (see section 4.6). In addition, we use red arrows to highlight the “happy path”
that users would ideally follow upon opening the app for the first time.
abandoned Sketchboard and later switched to Whimsical
6
for owcharting, because we found
the automatic layout generation to be cleaner and less cluttered (see Figure 1). We also used the
freely-available tool Adobe XD
7
for wireframes and nal digital mockups because one of our
members was already familiar with it. Our mobile app was implemented in NativeScript-Vue
8
, a
framework for cross-platform development based on JavaScript; see Figure 2 for a comparison.
6https://whimsical.co/
7https://www.adobe.com/products/xd.html
8https://nativescript-vue.org
10
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
Fig. 2. Comparison of one app screen through development stages: wireframe (le), mockup (middle), and
implementation (right).
Because Project Spectra members are located all over the world, some established participatory
design activities – such as in-person design workshops and focus groups – were not feasible.
The following sections use the rst author’s design memo documents (in which I recorded major
decision points) to illustrate our design process.
4.4 Principles and Goals
Project Spectra crafted a “Principles and Goals” document in August 2018. This document was then
presented to all new members when they joined the group9. Its full text is below:
**This is a living document. As our members grow, this document should too. Feel free
to suggest additions or edits!**
We are a group of independent developers and designers seeking to build free & open-
source software for voice training. While we believe that anyone, regardless of identity,
should be able to use and benet from our work, we are specically interested in
supporting the self-determination of transgender & gender non-conforming people.
As individuals who have pursued voice training ourselves, we want to create software
that we would want to use. However, we also recognize the limitations of our own
perspective and background. Therefore, we intend for our software to:
•Respond to the concerns, needs, and lived experiences of other trans people.
•Put users in control of what aspects of the voice are trained, and to what end goal.
•
Incorporate and take advantage of current research and clinical practices, as well as
the expertise within our community.
9We also later adopted a version of the Contributor Covenant [26], a more formal code of conduct used in FOSS teams
11
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
•
Not marginalize users, or further harmful notions or expectations, with regards to
gender, race, sexuality, nationality, ethnicity, and ability.
•Be accessible to as many individuals as possible.
•Be freely available and open source, in perpetuity.
We intend for ourselves to:
•
Foster meaningful community participation, both digitally and in-person, around
the design and development of the software.
•
Co-create a safer space, in which all contributors to our projects are treated with
dignity and respect.
4.5 Programming Framework
Early in the design process, our team considered whether to begin our development by splitting o
of (or “forking”) an existing open source voice training app called Voice Pitch Analyzer [
61
], or
to start from scratch. In Design Memo 3, dated the week of August 3-10, 2018, I summarized our
discussion in the form of pros and cons for both options (see Table 1).
Critical to our decision to start from scratch were that “more people will have access.” VPA,
the existing open source voice app, while well-designed and useful, is only available on Android.
This decision was dicult, though, because VPA has a “massive” current user base who we could
access for testing out new features incrementally. Also, the existing app is rst and foremost a
pitch detector; adding or elevating non-pitch related features could “disrupt” those users who do
nd those features essential. The existing open-source codebase was not just Android-only, but
Android-specic — i.e., very little (if any) of it was platform-agnostic. Choosing VPA meant being
stuck with Android for the forseeable future, and that major refactoring and scratch work would
have to be done to port to other platforms.
This early decision solidied Project Spectra’s prioritization of access, as described in our Prin-
ciples and Goals document (see section 4.4). Ultimately, working o an existing app would not
only have constrained current VPA users’ autonomy – as they may have to deal with unwanted
changes to an app they were familiar with – but also constrain us as developers. We may have found
ourselves limited by the voice training approach of the original app, and tasked with “tting our
ideas into” a design space where our ideas were incompatible. Specically, we needed to contend
with the fact that “we don’t think pitch is that important,” an idea backed up by the clinical literature
[
17
]. In this way, our team resolved to carve out a new space for an app that would oer something
that the currently available options did not. As a result, we chose to use NativeScript-Vue, a freely
available framework that compiles to both Android and iOS.
4.6 Experience Goals
In January 2019, one of our group members decided to lead a discussion on Discord to formalize the
project’s “Experience Goals,” to serve as guideposts throughout our design process. In so doing, we
formalized our values in a manner similar to our Principles and Goals document, but more focused
on the design artifact, and the experience we wanted to evoke and support. From our conversation,
we distilled three goals, which were presented and nalized at our general meeting on 15 February
2019:
•Armation.
Users must feel supported and represented, and feel that their choices and
identities are respected and validated by the app.
•Playfulness.
The app should be welcoming and encouraging to users without seeming
condescending or childish.
12
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
Table 1. Summary of our group discussion about the pros and cons of starting our own app from scratch.
Start from scratch Fork VPA
PROS CONS PROS CONS
-Can develop cross-
platform, potentially
using the Flutter
framework (which is
Dart-based)
-Frameworks are
potentially unstable
(Flutter, for exam-
ple, is still in early
development)
-Have access to their
massive user-base for
testing
-Since our planned
changes are fairly
radical, they may
confuse/disrupt
users (but this could
be solved w/ an
opt-in beta test?)
-As a result of the
above, more people
will have access to
the app in the long-
term
-Coding may be
slower and more
dicult since some
members of the
team may have to
learn a new lan-
guage/environment
-And also greater ac-
cess to new users in
the short-term
-Only Android users
will have access to
our app
-Can still use VPA
code if we need it &
give credit
-Q: Will we be able
to do all the calcula-
tions we need to do in
whatever new frame-
work we choose?
-Have access to [VPA
developers] as a sup-
port
-Given that we don’t
think pitch is that
important, it may
make absolutely
no sense to retain
current VPA features;
which would disrupt
users who do like
those functions if
our changes do get
pulled in
-Don’t have to deal
with tting our ideas
into an existing app
design/voice training
approach
•Care.
Users should never feel strained, overworked, or overwhelmed. The app should project
a sense of clarity, restfulness, and trust.
Finally, we concluded that:
“Design should focus on simple workows with clear objectives and interpreted feed-
back. User experience should be as customizable as possible, with the user in control
of how the app interacts with them and refers to them, and this should be alterable
at any time. The ultimate experience goal of this software should be a ‘warm fuzzies’
moment!”
The “Armation” goal describes the agency we wanted users to have, which counteracts the
social forces against trans people (see section 3.3). As shown in Figure 3, our app prompts users
13
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
Fig. 3. Onboarding screens for the Project Spectra app, which show how our Experience Goals of “Airmation”
and “Care” were implemented. Users can choose and change their name and goals (le and right) at any
point while using the app, and the app emphasizes vocal health and wellbeing over achieving a predetermined
gendered voice goal.
for their names and voice goals when they rst open our app. Rejecting normative ideas and
narratives about linear gender transitions, we also provide easily accessible options for users to
change their names and goals at any time. On the goal selection screen, users choose whether
or not to compare their progress against a specic pitch goal, which is selectable in lieu of, or in
addition to, masculine/feminine/androgynous options.
Our Experience Goals recognized the often fraught relationship trans people have to voice
training: that it can be extremely stressful, time-consuming, confusing, and overwhelming. With
the “Playfulness” goal, we described our aspiration for the app to counteract this problem by
being “welcoming and encouraging” but not “condescending or childish.” To fulll this goal, we
considered designing a cartoon character or mascot to make the app more fun, and periodically
presenting supportive messages to users. Months later, these ideas would make their way into our
nal prototype.
In February 2019’s general meeting (and during the preceding weeks), we also concluded that the
app needed more voice exercises and an increased emphasis on vocal health. Voice strengthening
exercises (also known as Vocal Function Exercises, or VFEs) can benet users regardless of their
specic goals ([
29
]). The exercises encourage people to use a well-supported voice that is less
prone to strain. Our conversations with speech therapists conrmed that vocal health should be
kept “front and center,” and as a group we considered ways to encourage users to strengthen
their vocal cords and take breaks. As a result, we reected the change in our owchart (see Figure
1), which color codes elements of the design by our Experience Goals. This translated directly
to their incorporation in our digital mockups, and nally in our prototype design. This decision
directly corresponded to the “Care” goal, because it would work against users feeling strained and
overwhelmed.
14
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
The collective articulation of our goals strongly inuenced the design process. Not only were
these goals community-sourced, in that they came from queer and trans people directly, they were
also community-implemented.
4.7 User Testing
Our Principles and Goals document stated that “we want to create software that we would want to
use. However, we also recognize the limitations of our own perspective and background.” To help
us make design decisions, we repeatedly reached out to external groups and individuals whose
perspectives we valued. This included trans people who are interested in voice training, speech
therapists, and the individuals who responded to our user testing surveys. I also consulted members
of my dissertation committee, and presented their thoughts to the group as suggestions rather than
directives.
The Project Spectra team created and released two user testing surveys: the rst covered the
onboarding ow (n = 20), the second covered voice training exercises (n = 9). The surveys were sent
to two Discord channels populated by trans people interested in voice training (n = approximately
1500 and 1000), two Slack channels of HCI research groups at Northeastern University (n = 20 and
31), and several trans technology researchers who were interested in the project. As I wrote in
Design Memo 16 (dated 25 April 2019), we intended to get a “mixture of responses” from “potential
users and from design/technology researchers.” An internal survey (n = 5) was also released to
Project Spectra group members regarding the design of the app’s cartoon character mascot.
During design meetings in early April 2019, we nalized the introductory text of our rst user
test:
Project Spectra is a collective aiming to create free, useful, and respectful voice training
software for transgender and gender non-conforming people. Our work is guided by
our own experiences, but we seek input from others to make the best app we possibly
can. Your participation in this test will help us do that. Thank you very much for your
time and attention :)
As a tester, you will take the role of someone who has just installed the “Project Spectra”
app. You are interested in training your voice, but you do not know much about it.
The test should take less than 15 minutes.
Things to know about being a tester:
(1)
There are no right or wrong answers to the test – we are testing the software, not
you
(2)
Please share all your thoughts (your “inner monologue”), whether they are positive
or negative
(3) You will not hurt our feelings by giving your honest opinion on our work
Thank you again!
Project Spectra Team
User tests contained a series of mockup screens; each screen was presented one at a time alongside
a series of questions, such as “What do you think you need to do here to move forward in the
application?” or “What can you tell about your goal from this screen?” All questions solicited
open-ended text responses. In our general meeting on 27 April 2019, we summarized and discussed
preliminary results from our rst tester. In the notes, I wrote that:
“the UI patterns we employ such as entry boxes, drop downs, tip acknowledgement and
progress indication are
very clear and immediate
. also on the pros side, most respon-
dents felt that the
tips area in particular was very informative and delightful
.
I would say it’s our biggest area of positive feedback...on the constructive criticism
15
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
side,
some users felt that the encouragement phrases we selected were a little
patronizing
. this is directly against our goal of being supportive to our users, so this
is the biggest area in need of adjustment” (emphasis in original text)
As a result of the feedback our group received over the three surveys we sent out, we increased
the saturation of the color scheme, claried the text displayed to be “less jargony,” and made the
pitch goal visualization more intuitive (Design Memo 20, 31 July 2019).
4.8 External Consulting
In Design Memo 13 (dated 26 February 2019), I reproduced the notes from my meeting with a
Boston-based speech therapist, whose opinion on how we should proceed diverged from our
group’s current trajectory. One component of voice modication for some trans people is larynx
training, in which people alter the position of their larynx through repeated exercises. The trans
voice communities online, particularly on Discord, commonly recommend the exercise “Big Dog
Small Dog.” In this short exercise, one slowly transitions from panting like a small dog (near the
front of the mouth, the larynx should elevate) to a big dog (near the back of the mouth, the larynx
should descend). Because the exercise is so popular in our group, I had already added it to the app;
in Design Memo 5 (dated November 2018), I described the trans voice training community’s general
understanding that: “Raising [the] larynx leads to a brighter sound, reducing space in the vocal
tract. Conversely, lowering the larynx leads to a darker sound. Testosterone has an eect on the
vocal tract which lowers the larynx – for voice training in trans women, the intention is to correct
for this.” However, the speech therapist I spoke to believed that the larynx should never be held in
one position. In my notes, I summarized the speech therapist’s opinion as the following:
“The larynx should not be held in a certain position – this requires extra muscle use
and could lead to strain. Instead, the larynx should rise and fall naturally. However,
[the speech therapist] doesn’t insist that we drop the exercise from our plan. She says
there’s still a lot of unknowns in this eld and that her views are open to change. She
has seen people for whom larynx manipulation works, but she has also seen it hurt
people.”
This exchange sparked a discussion on our Discord channel about the dierences in voice training
practices between clinicians and trans people. Trans people who have speech therapists do not
always agree with them [
3
]. As our collaborator admitted, how trans people ought to train their
voices is not an exact science; as section 3.3 describes, it is also fraught with gendered norms
and expectations. The clinical eld is relatively young (the most comprehensive text for speech
therapists working with trans people was rst published in 2006, with subsequent editions released
in 2012 and 2018 [
1
]). Our group had to contend with this social context, and ultimately decided
that we wanted to privilege the lived experiences, practices, and knowledge of trans people, rather
than institutional knowledge about us.
Prior research has highlighted trans peoples’ distrust of research and medical institutions – and
with good reason [
30
] – and are actively forming their own knowledge bases drawing from our own
experiences. This does not mean that the medical standpoint is always wrong (or that trans people
are always right). Medical and health apps often position themselves as authoritative sources, which
obscures the contested and socially situated aspects of the information being presented. I named
this issue in Design Memo 13, and asked: “Is there a way to work against this in the design of the
app? A way of naming this issue so that we are fully transparent to our users?” This question, like
many others that came up during our process, was not addressed in our nal (albeit functional)
prototype.
16
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
4.9 Challenges Relating to the Group’s Direction
Stress related to my graduate school timeline led to adverse consequences within the group. Late in
the design process, I needed a working prototype of our app so that I could move forward with my
dissertation work, as per the requirements of my program. In Design Memo 18 (dated 18 June 2019),
I wrote: “I had a meeting with my dissertation committee today. They’re saying that in order for
me to graduate on-time, I need to have a usable prototype done by Thanksgiving (to leave adequate
time for pilot testing and debut-ing).” I then end by saying, ominously, “That’s about 5 months
from now.”
That fall, the group experienced an inux of new members through snowballing; new members
invited their own connections, and the group’s size increased from 10 to 20 members. One of them
had an idea for a new app, separate from the one described in this paper, and began to recruit team
members towards creating it. In Design Memo 25 (2 October 2019), I wrote:
“I recently experienced an interaction on the Discord that left me evaluating how I
respond to people in the group. Do I feel threatened or defensive when members come
forward with ideas that deprioritize work that I spearheaded (the current Spectra app)?
I was eventually able to speak more reasonably about how much I valued that member’s
initiative.
Edit (10/8): Members also suggested that the short-term priority should be to help
me nish my degree, and the long-term goal is to make something benecial to the
community. This aected me. I remember being up late and looking at my phone in
the dark, because of the time zone dierences, right as I was getting ready for bed.
I ended up sitting up and typing responses on my phone in the Discord app, saying
that making something benecial to the community is why I am here too – not just to
complete my degree. Here is what I said: ‘As far as my degree goes, really don’t worry
about it! That’s for me to deal with - I don’t want my academic requirements getting
in the way of what you all want to do...’
However, that doesn’t change the fact that the community of Project Spectra was built
specically around the constraints of my degree.”
An autoethnographic approach allows us to examine this situation as data, not just about me, but
also about the organization. From this interaction, it is clear that: (1) at least one member felt that
the group’s priorities should shift; (2) I felt worried that this would prevent the group from reaching
a suitable stopping point for the existing Spectra app (which would put my dissertation timeline
in jeopardy); and (3) this worry caused me, initially, to react negatively to the group member’s
initiative, despite that I had dedicated substantial eort to getting group members to participate
over the past year. As I reect in the following sections, this dilemma stemmed from how academic
design research is structured.
5 DISCUSSION
Our design process involved a combination of techniques from participatory design (PD) and free
and open source software (FOSS). I argue that in such localized contexts (such as a group designing
with and for itself), standardized and hierarchical models for design begin to lose meaning. As a
collective, we moved toward a bottom-up process where collective decisions dictated what methods
to use and when, how user research is conducted and interpreted, and what implementation
decisions are made. That said, the work was anything but straightforward: there were no shortage
of tensions, challenges, and power dynamics at play in the team, as reviewed below.
Throughout the design process, team members brought their unique experience and expertise and
acted on it. Contributors freely made signicant decisions about (and contributions to) our project
17
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
without needing approval or permission from a hierarchical system. Our always-connectedness
allowed spontaneous yet critical decisions to take place as needed in the moment, but dierences
in timezones meant that not everyone was available and online when spontaneous interactions
were taking place. Open-endedness was therefore a drawback as well as a strength.
Taking our group as a whole, I want to ask whether our daily practices aligned with the vision
and intention of a non-hierarchical, community-based design eort. In so doing, I answer Rosner’s
call to look at moments of breakdown and diculty as an important source of data [
62
]. Taking
a reective stance, I inspect my own complex positionality and multiple roles as a trans person
(and hence a target user), an organizer and member of Project Spectra, and an academic and HCI
researcher.
5.1 Relationships to Existing Groupwork Models
In this section, I describe our groupwork practices in relation to previously described frameworks.
Rather than name our process as yet another model, I argue that it is important to exibly choose
collaboration tools and methods, specic to the domain in question, that maximize contributors’
agency and ownership over the project.
Free and open source software (FOSS) development cultures have been the subject of extensive
research. Ducheneaut [
23
] conducted an ethnographic study of Python contributors through
their listserv email communications. By following individual developers’ trajectories, he found
that “successful contribution to an OSS project is much less about technical expertise than about
the construction of identities.” Building an identity for oneself involved attaining status through
material/technical contributions, as well as gaining the approval of a network of allies (particularly
of “core members” or leaders of the project). Python contributors were thus socialized into complex
norms of participation, both implicit and explicit. No “hand holding” or coaching was oered to
newcomers; rising through the project’s hierarchies required both technical skill and political
acumen. Deucheneaut writes:
“Despite the rhetoric surrounding Open Source, which basically argues that ‘anybody
can contribute,’ it seems instead that only those few participants who have managed to
dene and present themselves as ‘software craftsmen’ eventually reach the status of
developer in a project.” (p. 362)
Deucheneaut’s analysis tracks individual contributors – who are assumed to be men, judging by
his exclusive use of masculine identiers – as they compete for in-group status. Other research
on FOSS development culture adds nuance to this narrative by describing the organic formation
of subgroups [
16
] and tightly-coupled teams focusing on smaller tasks within a project [
55
]. The
barriers to participating in open source teams are cultural as well as technical, and uniquely
disadvantage women (see [
54
] for a comprehensive analysis). Wubishet [
73
] argues that “the
very same possibilities of participation that FOSS culture and practice provide often impede the
participation of lay users.” Because technical prociency is required to participate, FOSS systems
are seldom designed with end users in mind; design requirements are assumed to be “generally
understood,” leading to a discounting of the experiences and needs of end-users, in turn leading
to poor usability. The authors suggest that “technically capable and active core team members
usually have more authority and decision-making rights” and that end-user critiques are not taken
as seriously. As a result, FOSS software tends to be developed “by experts for experts.” Wubishet
and colleagues then suggest that participatory design (PD) can help FOSS projects overcome this
problem. In PD, they write, the focus tends to be on “mutual learning” and “active cooperation”
between developers and users. The key activities – workshops, brainstorming, and prototyping –
18
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
all typically take place in-person. In this way, designers can immerse themselves in a setting and
build substantive relationships with target users.
Although participants can directly inuence the design process without needing any technical
experience, the power dynamic between researcher and participant is left unaddressed; “experts”
remain the primary decision-makers, just as they do in FOSS (see Section 3.1). Under both frame-
works, developers have the last word in what ends up in their designs. Many decisions that go into
development in practice (such as how to represent or calculate a variable in the back-end) can only
be made by developers can make in the moment, and PD models obscure them, marking them not
as important as the user experience.
The commons based peer production (CBPP) model attempts to address these issues. It focuses on
“autonomy, democracy, justice... a shift from consumers to users, doing more for and by themselves,
and in a loose association with others.” According to Benkler [
13
], such projects have the following
major characteristics:
•Decentralization: authority to act does not rest with a central manager or organizer
•
Social cues and motivations coordinate joint action, rather than corporate hierarchy/stakeholders
•The project must be modular
•The modules should be ne-grained
•There should be low-cost integration mechanisms
In Design Memo 8 (dated 25 January 2018), I began to reect on how we work, and how that
inuences the artifact we are creating and our relationships to each other. I wrote:
“I believe that the CBPP model has direct relevance to Project Spectra, and can guide
us in our development. I think our project is modular in that there are clear compo-
nents: algorithms/speech analysis, back-end programming, UX/front-end design, voice
exercises. It should be easy, for example, for a person with low technical experience
to follow what’s happening with the project and contribute their ideas. Traditional
PD techniques can be applied during adoption and customization (evaluation phases),
because a functional system is at hand for end-users to work around. I got an email
from someone who really wanted to help out... I did a short interview with them to
hear about their experiences, and oered to keep in touch about prototypes (they have
an Android phone, so it should be easy to get that working). But what else could they
help with? What are other ‘integration mechanisms’ that could allow this person to
contribute ideas?”
Later, in a memo written on April 4, I attempted to more concretely address how our project
worked in relation to PD, FOSS, and CBPP (see Table 2). I wrote, “What model do we most conform
to in practice? Is this what we want? Although I would aspire to a CBPP model, I think that our
project contains elements of all three models.” Some of the qualities of the project described in
Table 2 arose despite my intentions. For example, team members referred to me as the “project lead”
even though I never claimed that title for myself. I inhabited that role based on my day-to-day
actions: coordinating and facilitating meetings, introducing new team members to the project (I am
their rst point of contact), and keeping documentation in order. I am also a contributor to the code
and the design, but those do not conform to a particular role within the project (we do not have
assigned roles in our team). I did not directly assign tasks; rather, things got done based on the
motivations, skillsets, and collective decision-making of team members. My role included scheduling
and facilitating meetings, drafting agendas, creating paper and digital mockups, analyzing user
survey results, and writing code. Beyond that, I internalized a sense of what people’s capacities were,
holding in my memory their general interest in the project and what they wanted to work on, trying
to create opportunities and situations for people to get involved and feel included, while at the
19
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
Table 2. Comparing groupwork models in the context of Project Spectra. CBPP is commons-based peer
production; PD is participatory design; FOSS is free & open source soware.
Quality of Project Spectra Associated group-
work model
Modular components (algo-
rithms/speech analysis, back-end
programming, UX/front-end design,
voice exercises)
CBPP
Not prot-motivated; most decisions
made collectively
CBPP
Non-technical individuals consulted us-
ing interviews/user testing/other meth-
ods, some of which are face-to-face
PD
Organized/managed by an central indi-
vidual (me)
PD
Open-source; team members involved
in implementation; asynchronous
FOSS
Some modules require high levels of
technical skill and background knowl-
edge
FOSS
same time not being pushy. This demanded signicant interpersonal skills and sensitivity; and I did
not always do this well. I felt a desire to act as a support for team members who were having a hard
time (for example, if someone cannot make a meeting because they are going through something, I
would reach out to ask how they were doing and if I could support them). Interpersonally, it was
dicult to maintain the level of care that I wanted to exhibit, especially if I did not know the person
very well. Though I believe we trusted each other, we never met in-person and we communicated
primarily over text channels (with the occasional voice and video call).
Taking the above reections together, it is clear that I was acting as a central organizer, despite
my intentions not to. As the next section elaborates, this had several cascading eects on our design
process.
5.2 Examining A Moment of Breakdown
Feminist epistemologies consider experience an important source of data; attending to “moments of
breakdown” and diculty can serve as a window into the design process [
62
]. By any measure, the
experience I documented in Section 4.9 was a moment of breakdown. Rapidly coming up against
a deadline, I felt pressure to meet the expectations that my dissertation committee and funding
sources laid out for me. Texting late into the night on our Discord channel, I did not think about
how to respond appropriately to this team member. I felt that I had failed because another member
suggested that the group should help me nish my degree before making something benecial to
the community. I felt ashamed because I felt that my behavior was impeding the very principles
to which I had aspired: to encourage open collaboration, to cede control and dissolve hierarchies.
It is interesting to consider how dierently I might have reacted if this interaction had occurred
20
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
during an in-person design session; I might have responded more thoughtfully, and I might have
known them and their goals and interests better. On the other hand, it seems less likely that this
interaction would have occurred at all: focus groups and other in-person design exercises rarely
allow participants to act collectively towards long-term agendas of their own choosing.
In order to address the gap between momentary and sustained collaboration in computing
research, we must also consider broader structural factors governing the production of academic
knowledge. Klocker [
48
] describes the challenges of doing a PhD while also conducting participatory
action research (PAR), a set of methods aligned with the community-based framework to which this
project aspired. Participatory researchers are “not supposed to pre-empt how projects will unfold,”
Klocker writes, and yet PhD students’ degree progress may be impeded by community consultation.
Despite this, Klocker takes a measured stance and suggests that building uncertainty into project
proposals from the outset could ward against time crunches down the line. She also notes that
tensions between individualism (doctoral work) and collectivism (participatory research) can arise
during a PhD, because the thesis is expected to be evidence of “individual research competence”; as
such, “co-authorship is unacceptable” [
48
]. This tension can “reinforce unequal power relationships
because [PhDs] are solely responsible for the task of putting collaborative research to paper....
Concerns also exist over the rightful ownership of knowledge produced by a team.” I faced this
tension not just during the design process itself, but also while writing this paper.
Klocker points to the lack of “support and guidance” and the “limited availability of literature
specic to PAR PhDs” in her eld of geography research. I would argue that despite HCI and
CSCW’s strong leanings towards participatory and community-based work, more scaolding in
this area is needed for HCI scholars, especially doctoral students and early career researchers. This
could take the form of articulating and reecting on methods, challenges, failures, and opportunities
for improvement in how we design with others. Following Harrington [
40
], such accounts must
reckon with the social, political, and institutional contexts at play.
5.3 Limitations
The present account of our collaborative design process is limited by several factors. First of all, when
Project Spectra was formed, I did not set out to study our design process. It was only upon reection
during the process that interesting and challenging “troubles” emerged. As mentioned early in the
paper, I did not formally obtain consent from team members to include their own reections here,
for example via in-depth interviews. Future work could make “studying the process” central to the
process itself, and include a more formal qualitative analysis of team members’ experiences.
Second, because demographic information was not formally collected from each member of the
group due to ethical obligations, it was impossible for this paper to provide a detailed characteriza-
tion of the individuals who participated in Project Spectra. The “transgender community” is not a
monolith, but this work attens dierences or dynamics related to race, gender, nationality, culture,
language, and economic class. For example, all communication on our chat channels was in English,
and we recruited members through English-speaking networks. Future studies of collaborative
design should consider intra-community power and privilege dynamics as central to the analysis.
Third, the design process could have been more open, both within and outside our Discord
channel. Design memo updates could have been posted directly to a public channel rather than to
a Google Drive document. This might have fostered more group ownership of the design memo
document, rather than it serving as a documentation space for the rst author alone. Discord,
despite its advantages, may have presented challenges to group members seeking to make sense of
conversations they have missed, even though all messages were accessible and searchable (as is the
case with other team communication channels [74]).
21
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
This work was also limited by the rst author’s academic environment, which, in some ways,
beneted the project. With my research stipend and university aliation, I was able to work
on Project Spectra full-time and had access to academic resources and collaborators. But these
ostensible benets also positioned me as a decision-maker and leader. Additional institutional
training for working with (and within) community-based teams – as highlighted by Asad [
6
] –
would have better prepared me to conduct this work. As described in section 4.9, the fact that this
work was conducted as part of an institutionally-mandated deliverable (my dissertation) had a
signicant eect on the design process. Future work could consider this issue at the outset, and
plan around academic timelines and constraints to the fullest possible extent.
5.4 Transformations
This paper attempted to show how academic research contexts can reinforce power dierentials and
hamstring community collaborations. But can these problems be overcome, and if so, how? Mountz
and colleagues argue for “slow scholarship,” and “a fundamental restructuring of the university as a
workplace and learning environment” [
56
]. The restructured academy would value care work, labor
organizing and activism, collaborations, and collective authorship/ownership. Slow scholarship
“raises the question of what counts and for whom and expands our community of care beyond
those in the academy.” How would the theory and practice of “community-based” design change in
a restructured academy? How can we begin to live these values now?
Academic institutions often pride themselves on their contributions to local communities and
economies, but these contributions are rooted in the exploitation of an expanding underclass of
contingent workers (adjunct and non-tenure track faculty, who comprise upwards of 70 percent of
the academic labor force [
5
]) and graduate student workers. Further, local activists have argued that
the community contributions claimed by universities do more harm than good. Taking Northeastern
University (my graduate institution) as an example, neighborhood developments and renovations
have resulted in gentrication and a reduction in aordable housing availability [19, 65].
Examining at the underlying economic relationship between the university and the city reveals
more. Although Northeastern University does not need to pay property taxes due to its non-prot
status, the City of Boston requests payment in lieu of taxes (or PILOT) totaling $11.4 million. Of that
sum, the university paid $1.7 million and claimed an additional $5.7 million in “community benets,”
[
65
] including a nearby park renovation [
53
]. Eectively, the university undertakes gentrifying
renovation projects – in which neighborhood residents do not have any meaningful democratic
participation – to claim them as a PILOT tax write-o.
What does this have to do with community-based collaborative design? In the example above,
the relationship between my university and local community is primarily extractive; Massachusetts
State Representative Nika Elugardo, whose jurisdiction covers Northeastern’s campus, said that
“we need to shift the culture from a dominance model to a partnership model” [
19
]. Academic
community-based work is necessarily inuenced by this culture of dominance and extraction [
40
];
transforming it requires a massive shift, not only in institutional culture, but also in structure and
governance.
As Alvarez argues [
5
], the academic labor force is essential to this transformation. Imagine
a democratically-run university, with neighborhood councils, faculty unions, and student-run
cooperatives collectively setting the priorities for teaching, research, and development. Deep,
enduring ties to the surrounding community emerge organically from this arrangement, which
would pave the way for collaborative research eorts that respond to the immediate needs and
interests of the people. Online collaborative studies would also be improved this way. We envision
a more interconnected and publicly accountable university, which would have more resources
and opportunities for researchers to be trained and supported in doing community-based work
22
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
thoughtfully and ethically. This is only one possible vision out of many, but nothing is possible
unless we organize to change the status quo.
5.5 Process Recommendations
Individual researchers can only act within imperfect systems; changing these systems will require
collective action. My recommendations for researchers and practitioners interested in community-
based collaborative design are thus both individual and structural. I summarize them below, and
point to locations within the paper where each point is elaborated on:
•
Consider autoethnography as a method (via journaling/memoing) to reveal biases, con-
tradictions, and emotional challenges arising within the design process. Encourage your
collaborators to do the same. (Individual, see Section 4.1.)
•
If considering online tools (such as Discord and FOSS), weigh the benets and limitations
they would bring to the process before deciding – as a group – if they are appropriate. Tools
should be chosen on the basis of whether and how they would aect collective ownership
and control of the project. (Individual, see Section 4.3.)
•
Ask your institution to provide robust training and resources for conducting community-
based research, especially if you are in a department where such approaches are not commonly
carried out. (Structural, see Section 5.3.)
•
Organize with people both inside and outside the academy to address systemic marginal-
ization. Expanding “our community of care beyond those in the academy” [
56
] requires
recognizing the ways that the academy harms those outside it. For example, a researcher at-
tempting to work with low-income communities surrounding their university should consider
whether the university has policies of expansion that are displacing those same communities.
(Structural, see Section 5.4.)
6 CONCLUSION
Community-based collaborative design allowed Project Spectra members to work against dominant,
agency-stripping gender norms. Prioritizing agency in our app from the beginning, we supported
users specifying and changing their goals at any time. Within our organization, we intended to
support members’ agency by fostering meaningful (and not mandatory) participation based on our
own skills, interests, and backgrounds. We sought feedback from individuals outside our group,
such as speech therapy practitioners, and recognized that they possessed unique training. However,
we also did not elevate their knowledge above and beyond that of the broader community, especially
if they hailed from a clinical institution. That being said, our work as a group was not immune to
contradictions arising from my position in academia.
This paper attempted to answer calls within HCI for a “reorienting” and “restructuring” of PD,
but more research on alternative working models is still needed. Researchers can use established
groupwork models – such as PD, FOSS, and CBPP – as methodological guides to design; we can then
ask how we can (and should) work with others, and what design methods are appropriate in a given
context. Evaluative questions guided by feminist methodologies can reveal the relationships, habits,
stories, and breakdowns that structure our design projects. This paper showed the importance of
reecting, via autoethnographic eld notes, on the researcher’s own positionality and inuence on
the research.
Coleman [
18
] describes how open source software developers act collectively but reject “politics,”
considering it a failed enterprise. Conversely, it seems, HCI researchers embrace political analyses
and approaches but struggle to collectively challenge the oppressive systems that govern neoliberal
academia. As a case in point, the academic context of this research, and my participation in it,
23
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
sometimes beneted but ultimately hampered the extent to which our design process could embody
a bottom-up and self-driven ideal. To address this issue, we must organize toward political, economic,
and cultural shifts in the structure and governance of academic institutions.
ACKNOWLEDGMENTS
The authors would like to thank all the members of Project Spectra. Additionally, Zheanna Erose and
Lillith Whitmann both provided critical feedback and guidance to Project Spectra during our design
process. Thanks to the Discord channels TransVoice and Scinguistics and to all the anonymous
individuals who completed our user tests. The rst author would also like to thank Liz Polcha for
sharing “slow scholarship” with me, and Halcyon Lawrence, Stephan Pennington, Barbara Worth,
Michelle Borkin, and Meryl Alper for supporting me and my ideas during grad school. This work
was nancially supported by the National Institutes of Health (Grant #5F31DC016804-02) and the
National Science Foundation’s Graduate Research Fellowship Program.
REFERENCES
[1]
Richard K Adler, Sandy Hirsch, and Jack Pickering. 2018. Voice and communication therapy for the transgender/gender
diverse client: A comprehensive clinical guide. Plural Publishing.
[2]
Alex Ahmed, Bryan Kok, Coranna Howard, and Klew Still. 2020. Project Spectra: A Voice Training App for Transgender
People. https://doi.org/10.5281/zenodo.3824662
[3]
Alex A Ahmed. 2018. Trans Competent Interaction Design: A Qualitative Study on Voice, Identity, and Technology.
Interacting with Computers 30, 1 (jan 2018), 53–71. https://doi.org/10.1093/iwc/iwx018
[4]
Alex A Ahmed and Anna Lauren Homann. 2018. Conguring the Trans Voice: Gender, Race, and Class in Mobile
Voice Training Applications for Transgender People. In The 19th Annual Conference of the Association of Internet
Researchers. Montreal, Canada.
[5]
Maximillian Alvarez. 2017. Contingent No More: An academic manifesto. https://thebaer.com/the-poverty-of-
theory/contingent-no- more The Baer. Accessed 2020-08-25.
[6]
Mariam Asad. 2019. Pregurative design as a method for research justice. Proceedings of the ACM on Human-Computer
Interaction 3, CSCW (2019). https://doi.org/10.1145/3359302
[7]
Moya Bailey. 2015. # transform (ing) DH Writing and Research: An Autoethnography of Digital Humanities and
Feminist Ethics. DHQ: Digital Humanities Quarterly 9, 2 (2015).
[8]
Liam Bannon, Jerey Bardzell, and Susanne Bødker. 2018. Introduction: Reimagining participatory design-Emerging
voices. ACM Transactions on Computer-Human Interaction 25, 1 (2018), 1–8. https://doi.org/10.1145/3177794
[9]
Eric P.S. Baumer and M. Six Silberman. 2011. When the implication is not to design (technology). Conference on Human
Factors in Computing Systems - Proceedings (2011), 2271–2274. https://doi.org/10.1145/1978942.1979275
[10]
Toby Beauchamp. 2019. Going stealth: Transgender politics and US surveillance practices. Duke University Press, 8–9.
[11]
Diana Beirl, Anya Zeitlin, Jerald Chan, Kai Ip Alvin Loh, and Xiaodi Zhong. 2017. GotYourBack: An Internet of Toilets
for the Trans* Community. In Proceedings of the 2017 CHI Conference Extended Abstracts on Human Factors in Computing
Systems - CHI EA ’17. ACM Press, New York, New York, USA, 39–45. https://doi.org/10.1145/3027063.3049272
[12] Ruha Benjamin. 2019. Race After Technology: Abolitionist Tools for the New Jim Code. Polity Press, 217–239.
[13]
Yochai Benkler and Helen Nissenbaum. 2006. Commons-based peer production and virtue. Journal of political
philosophy 14, 4 (2006), 394–419.
[14]
Cynthia L. Bennett and Daniela K. Rosner. 2019. The Promise of Empathy: Design, Disability, and Knowing the “Other”.
In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI ’19). Association for Computing
Machinery, New York, NY, USA, Article 298, 13 pages. https://doi.org/10.1145/3290605.3300528
[15]
Talia Mae Bettcher. 2006. Appearance , Reality and Gender Deception: Reections on Transphobic Violence and the
Politics of Pretence. Violence, Victims, Justications: Philosophical Approaches (2006), 175–200.
[16]
Christian Bird, David Pattison, Raissa D’Souza, Vladimir Filkov, and Premkumar Devanbu. 2008. Latent social structure
in open source projects. Proceedings of the ACM SIGSOFT Symposium on the Foundations of Software Engineering
January (2008), 24–35. https://doi.org/10.1145/1453101.1453107
[17]
Lisa Carew, Georgia Dacakis, and Jennifer Oates. 2007. The eectiveness of oral resonance therapy on the perception
of femininity of voice in male-to-female transsexuals. Journal of Voice 21, 5 (2007), 591–603.
[18]
Gabriella Coleman. 2009. Code is Speech: Legal Tinkering, Expertise, and Protest among Free and Open Source Software
Developers. Cultural Anthropology 24, 3 (aug 2009), 420–454. https://doi.org/10.1111/j.1548-1360.2009.01036.x
24
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
[19]
Sean Philip Cotter. 2020. Roxbury leaders: Northeastern has lost its way. https://www.bostonherald.com/2020/01/12/
roxbury-leaders- northeastern-has- lost-its- way/ The Boston Herald. Accessed 2020-08-25.
[20]
Georgia Dacakis, Jennifer Oates, and Jacinta Douglas. 2012. Beyond voice: Perceptions of gender in male-to-female
transsexuals. Current opinion in otolaryngology & head and neck surgery 20, 3 (2012), 165–170.
[21]
Shelagh Davies, Vikt Oria, Viktória G Papp, and Christella Antoni. 2015. Voice and Communication Change for Gender
Nonconforming Individuals: Giving Voice to the Person Inside. International Journal of Transgenderism 16, 3 (2015),
117–159. https://doi.org/10.1080/15532739.2015.1075931
[22]
P Descloux, S Isoard-Nectoux, B Matoso, L Matthieu-Bourdeau, F Schneider, and V Schweizer. 2012. Transsexuality:
speech therapy supporting the" voice" of transformation. Revue de laryngologie-otologie-rhinologie 133, 1 (2012), 41–44.
[23]
Nicolas Ducheneaut. 2005. Socialization in an open source software community: A socio-technical analysis. Computer
Supported Cooperative Work: CSCW: An International Journal 14, 4 (2005), 323–368. https://doi.org/10.1007/s10606-
005-9000- 1
[24]
Florian Echtler and Maximilian Häußler. 2018. Open source, open science, and the replication crisis in HCI. Conference
on Human Factors in Computing Systems - Proceedings 2018-April (2018), 1–8. https://doi.org/10.1145/3170427.3188395
[25]
E. Kale Edmiston, Cameron A. Donald, Alice Rose Sattler, J. Klint Peebles, Jesse M. Ehrenfeld, and Kristen Laurel
Eckstrand. 2016. Opportunities and Gaps in Primary Care Preventative Health Services for Transgender Patients: A
Systematic Review. Transgender Health 1, 1 (2016), 216–230. https://doi.org/10.1089/trgh.2016.0019
[26]
Coraline Ada Ehmke. 2014. Contributor Covenant. https://www.contributor-covenant.org/version/1/4/code-of-
conduct
[27]
Carolyn Ellis, Tony E Adams, and Arthur P Bochner. 2010. Autoethnography: An Overview. Forum Qualitative
Sozialforschung / Forum: Qualitative Social Research 12, 1 (2010), 273–290. https://doi.org/10.17169/fqs-12.1.1589
[28]
Robert M Emerson, Rachel I Fretz, and Linda L Shaw. 2011. Writing ethnographic eldnotes. University of Chicago
Press, 123–127.
[29]
Marylou Pausewang Gelfer and Bethany Ramsey Van Dong. 2013. A preliminary study on the use of vocal function
exercises to improve voice in male-to-female transgender clients. Journal of Voice 27, 3 (2013), 321–334.
[30]
Danielle M. Giort and Kelly Underman. 2016. The relationship between medical education and trans health disparities:
a call to research. Sociology Compass 10, 11 (2016), 999–1013. https://doi.org/10.1111/soc4.12432
[31]
Jaime M. Grant, Lisa A. Mottet, Justin Tanis, Jack Harrison, Jody L Herman, and Mara Keisling. 2011. Injustice at Every
Turn: A Report of the National Transgender Discrimination Survey. Technical Report. https://doi.org/10.1016/S0016-
7878(90)80026-2
[32]
Collin Green, Alex Eiser, Irene Tollinger, Lanie Castro, Christian Ratterman, Alonso Vera, and Guy Pyrzak. 2009.
Leveraging open-source software in the design and development process. Conference on Human Factors in Computing
Systems - Proceedings (2009), 3061–3074. https://doi.org/10.1145/1520340.1520433
[33]
Critical Platform Studies Group, Lilly Irani, Niloufar Salehi, Joyojeet Pal, Andrés Monroy-Hernández, Elizabeth
Churchill, and Sneha Narayan. 2019. Patron or Poison?. In Conference Companion Publication of the 2019 on Computer
Supported Cooperative Work and Social Computing - CSCW ’19. ACM Press, New York, New York, USA, 111–115.
https://doi.org/10.1145/3311957.3358610
[34]
Oliver Haimson. 2018. Social Media as Social Transition Machinery. Proc. ACM Hum.-Comput. Interact. 2, CSCW,
Article 63 (Nov. 2018), 21 pages. https://doi.org/10.1145/3274332
[35]
Oliver L Haimson, Jed R Brubaker, Lynn Dombrowski, and Gillian R Hayes. 2016. Digital Footprints and Changing
Networks During Online Identity Transitions. In Proceedings of the 2016 CHI Conference on Human Factors in Computing
Systems - CHI ’16. ACM Press, New York, New York, USA, 2895–2907. https://doi.org/10.1145/2858036.2858136
[36]
Oliver L. Haimson, Dykee Gorrell, Denny L. Starks, and Zu Weinger. 2020. Designing Trans Technology: Dening
Challenges and Envisioning Community-Centered Solutions. Conference on Human Factors in Computing Systems -
Proceedings (2020), 1–13.
[37] Donna J Haraway. 2016. Staying with the trouble: Making kin in the Chthulucene. Duke University Press.
[38]
Teresa LD Hardy, Carol A Boliek, Kristopher Wells, and Jana M Rieger. 2013. The ICF and male-to-female transsexual
communication. International Journal of Transgenderism 14, 4 (2013), 196–208.
[39]
Christina N. Harrington, Katya Borgos-Rodriguez, and Anne Marie Piper. 2019. Engaging Low-Income African
American Older Adults in Health Discussions through Community-based Design Workshops. Proceedings of the 2019
ACM Conference on Human Factors in Computing Systems (2019), 1–15. https://doi.org/10.1145/3290605.3300823
[40] Christina N. Harrington, Sheena Erete, and Anne Marie Piper. 2019. Deconstructing community-based collaborative
design: Towards more equitable participatory design engagements. Proceedings of the ACM on Human-Computer
Interaction 3, CSCW (2019). https://doi.org/10.1145/3359318
[41]
Lilly Irani. 2018. “Design Thinking”: Defending Silicon Valley at the Apex of Global Labor Hierarchies. Catalyst:
Feminism, Theory, Technoscience 4, 1 (2018), 1–19. https://doi.org/10.28968/cftt.v4i1.29638
[42] Lilly Irani. 2019. Chasing Innovation: Making Entrepreneurial Citizens in Modern India. Princeton University Press.
25
CSCW ’20, October 17–21, 2020, Minneapolis, MN Ahmed, Kok, Howard, & Still
[43]
Lilly Irani, Janet Vertesi, Paul Dourish, Kavita Philip, and Rebecca E. Grinter. 2010. Postcolonial Computing: A Lens on
Design and Development. Proceedings of the 28th international conference on Human factors in computing systems - CHI
’10 (2010), 1311. https://doi.org/10.1145/1753326.1753522
[44]
Sandy E. James, Jody L. Herman, Susan Rankin, Mara Keisling, Lisa Mottet, and Ma’ayan Ana. 2016. The Report of the
2015 US Transgender Survey. Technical Report.
[45]
Os Keyes. 2018. The misgendering machines: Trans/HCI implications of automatic gender recognition. Proceedings of
the ACM on Human-Computer Interaction 2, CSCW (2018). https://doi.org/10.1145/3274357
[46]
Os Keyes, Josephine Hoy, and Margaret Drouhard. 2019. Human-Computer Insurrection: Notes on an Anarchist HCI.
In Proceedings of the 2019 CHI Conference on Human Factors in Computing Systems (CHI ’19). Association for Computing
Machinery, New York, NY, USA, Article 339, 13 pages. https://doi.org/10.1145/3290605.3300569
[47]
Vera Khovanskaya and Phoebe Sengers. 2019. Data Rhetoric and Uneasy Alliances: Data Advocacy in US Labor
History. Proceedings of the 2019 on Designing Interactive Systems Conference - DIS ’19 (2019), 1391–1403. https:
//doi.org/10.1145/3322276.3323691
[48]
Natascha Klocker. 2012. Doing Participatory action research and Doing a PhD: Words of encouragement for prospective
students. Journal of Geography in Higher Education 36, 1 (2012), 149–163. https://doi.org/10.1080/03098265.2011.589828
[49]
Sara LeGrand, Kathryn Elizabeth Muessig, Tobias McNulty, Karina Soni, Kelly Knudtson, Alex Lemann, Nkechinyere
Nwoko, and Lisa B Hightow-Weidman. 2016. Epic Allies: Development of a Gaming App to Improve Antiretroviral
Therapy Adherence Among Young HIV-Positive Men Who Have Sex With Men. JMIR Serious Games 4, 1 (2016), e6.
https://doi.org/10.2196/games.5687
[50] Sara LeGrand, Kathryn E. Muessig, Alyssa Platt, Karina Soni, Joseph R. Egger, Nkechinyere Nwoko, Tobias McNulty,
and Lisa B. Hightow-Weidman. 2018. Epic allies, a gamied mobile phone app to improve engagement in care,
antiretroviral uptake, and adherence among young men who have sex with men and young transgender women
who have sex with men: Protocol for a randomized controlled trial. Journal of Medical Internet Research 20, 4 (2018).
https://doi.org/10.2196/resprot.8811
[51] VoxPop LLC. 2020. EVA: Transgender Voice App. http://exceptionalvoiceapp.com/
[52] Speechtools Ltd. 2020. Christella VoiceUp. https://speechtools.co/christella- voiceup
[53]
Greg St. Martin. 2018. Northeastern to open state-of-the-art community park in Boston. https://news.northeastern.
edu/2018/08/02/northeastern-prepares-to-open- state-of- the-art-community-park-in-boston/ News Northeastern.
Accessed 2020-08-25.
[54]
Christopher Mendez, Margaret Burnett, Hema Susmita Padala, Zoe Steine-Hanson, Claudia Hilderbrand, Amber
Horvath, Charles Hill, Logan Simpson, Nupoor Patil, and Anita Sarma. 2018. Open source barriers to entry, revisited.
(2018), 1004–1015. https://doi.org/10.1145/3180155.3180241
[55]
Eunyoung Moon. 2016. Do open projects ’break the mirror’?: Re-conceptualization of organizational congurations in
Free/Libre Open Source Software (FLOSS) development. Proceedings - 11th IEEE International Conference on Global
Software Engineering Companion Proceedings, ICGSEW 2016 (2016), 73–76. https://doi.org/10.1109/ICGSEW.2016.18
[56]
Alison Mountz, Anne Bonds, Becky Manseld, Jenna Loyd, Jennifer Hyndman, Margaret Walton-Roberts, Ranu Basu,
Risa Whitson, Roberta Hawkins, Trina Hamilton, and Winifred Curran. 2015. For slow scholarship: A feminist politics
of resistance through collective action in the Neoliberal University. Acme 14, 4 (2015), 1235–1259.
[57]
Joyojeet Pal. 2017. CHI4Good or Good4CHI. Proceedings of the 2017 CHI Conference Extended Abstracts on Human
Factors in Computing Systems - CHI EA ’17 (2017), 709–721. https://doi.org/10.1145/3027063.3052766
[58]
Stephan Pennington. 2019. Transgender Passing Guides and the Vocal Performance of Gender and Sexuality. In The
Oxford Handbook of Music and Queerness. 1–44. https://doi.org/10.1093/oxfordhb/9780199793525.013.65
[59]
Guilherme C. Pereira and M. Cecilia C Baranauskas. 2010. Codesigning emancipatory systems: a study on mobile
applications and lesbian, gay, bisexual, and transgender (LGBT) issues. SBC Journal on Interactive Systems 9, 3 (2010),
80–92. https://www.seer.ufrgs.br/jis/article/view/80234
[60]
Tonia Poteat, Danielle German, and Colin Flynn. 2016. The conation of gender and sex: gaps and opportunities in
HIV data among transgender women and MSM. Global public health 11, 7-8 (2016), 835–848.
[61]
Purr Programming. 2020. Voice Pitch Analyzer. https://play.google.com/store/apps/details?id=de.lilithwittmann.
voicepitchanalyzer&hl=en
[62] Daniela K Rosner. 2018. Critical Fabulations: Reworking the Methods and Margins of Design. MIT Press.
[63]
Morgan Klaus Scheuerman, Stacy M. Branham, and Foad Hamidi. 2018. Safe spaces and safe places: Unpacking
technology-mediated experiences of safety and harm with transgender people. Proceedings of the ACM on Human-
Computer Interaction 2, CSCW (2018). https://doi.org/10.1145/3274424
[64]
Julia M. Serano. 2008. A matter of perspective: A transsexual woman-centric critique of Dreger’s "scholarly history" of
the Bailey controversy. Archives of Sexual Behavior 37, 3 (2008), 491–494. https://doi.org/10.1007/s10508-008-9332- 2
[65]
Boston Herald Editorial Sta. 2020. Northeastern should stop shorting Roxbury. https://www.bostonherald.com/2020/
01/14/northeastern-should- stop-shorting- roxbury/ The Boston Herald. Accessed 2020-08-25.
26
Online Community-based Design for Trans Voice CSCW ’20, October 17–21, 2020, Minneapolis, MN
[66]
Denny L. Starks, Tawanna Dillahunt, and Oliver L. Haimson. 2019. Designing technology to support safety for
transgender women & non-binary people of color. DIS 2019 Companion - Companion Publication of the 2019 ACM
Designing Interactive Systems Conference (2019), 289–294. https://doi.org/10.1145/3301019.3323898
[67]
Angelika Strohmayer, Jenn Clamen, and Mary Laing. 2019. Technologies for social justice lessons from sex workers on
the front lines. Conference on Human Factors in Computing Systems - Proceedings (2019), 1–14. https://doi.org/10.1145/
3290605.3300882
[68]
Project Spectra Team. [n.d.]. Project Spectra. https://github.com/project-spectra/ Github Organization. Accessed
2020-04-13.
[69]
Tourmaline, Eric A. Stanley, and Johanna Burton. 2017. Known Unknowns: An Introduction to Trap Door. In Trap
Door: Trans Cultural Production and the Politics of Visibility, Tourmaline, Eric A. Stanley, and Johanna Burton (Eds.).
MIT Press/the New Museum, Cambridge, MA/New York, NY, xv–xxiv.
[70]
Evan Vipond. 2015. Resisting Transnormativity: challenging the medicalization and regulation of trans bodies. Theory
in Action 8, 2 (2015), 21–44. https://doi.org/10.3798/tia.1937-0237.15008
[71]
Aimee Wodda and Vanessa Panl. 2015. "Don’t Talk to Me about Deception": The Necessary Erosion of the Trans-Panic
Defense. Albany Law Review 78, 3 (2015), 927.
[72]
Virginia I Wolfe, David L Ratusnik, Furman H Smith, and Gretajo Northrop. 1990. Intonation and fundamental
frequency in male-to-female transsexuals. Journal of Speech and Hearing Disorders 55, 1 (1990), 43–50.
[73]
Zegaye Seifu Wubishet, Bendik Bygstad, and Prodromos Tsiavos. 2013. A Participation Paradox: Seeking the Missing
Link between Free/Open Source Software and Participatory Design. Journal of Advances in Information Technology 4,
4 (nov 2013), 181–193. https://doi.org/10.4304/jait.4.4.181-193
[74]
Amy X. Zhang and Justin Cranshaw. 2018. Making sense of group chat through collaborative tagging and summarization.
Proceedings of the ACM on Human-Computer Interaction 2, CSCW (2018). https://doi.org/10.1145/3274465
27
