Keywords

1 Introduction

HCI subdomains are increasingly taking into account approaches towards emancipation. Bardzell and Bardzell [3] define emancipatory HCI as “research or practice oriented toward exposing and eradicating one or more forms of bondage and oppression.” Participatory Design (PD) is a traditional emancipatory branch, with roots in the political concerns of Scandinavian workers facing the insertion of computers in the workplace. It focuses on the knowledge about an issue from people whose lives are affected by it.

LGBT people are historically an oppressed group in most of Western societies, facing violence in physical, verbal, legal, and affective forms, among others. Such struggles are faced by LGBT people in current Brazilian society, as well. The country is home to half of the killings of transgender women in the world [10] and to 1 death of a LGBT person each 27 h [4]. Not only the numbers themselves are alarming, but also the cruelty present in such crimes, which often include sexual abuse, torture, and mutilation. One emblematic case was the killing of Dandara dos Santos in Fortaleza, a travesti beaten to death by men in a street of the city of Fortaleza, who later posted the video online in Facebook in February, 2017. Although such characteristics seem remarkable signs of hate crimes based on gender identity or sexual orientation, Brazilian law lacks specific definitions of LGBT-phobia causing such incidents to blend with the country’s high homicide rates. Congressmen also make harder for such law to be made, since the country is also facing a rise of political conservativeness and religious influence in politics.

The project where this work is inscribed aims to develop a novel system to support LGBT people and provide them with means to survive and empower themselves. In order to do this, we adopted a socially-aware approach, based on PD and Organizational Semiotics (OS). The result of the activities is a new Android mobile application called LGBTrust, which articulates formal and informal aspects of the fight against LGBTphobia strengthening a group of users constituted of people and partner institutions.

The fight against LGBTphobia is inherently complex – it involves immediate defense against life-threatening events, education to raise (self-)awareness, and support to collective action. When developing a system to tackle it, one risks embedding such relations in bewildering interactions or neglecting some component in a simplistic product. John Maeda [8] developed a framework to study simplicity in “design, technology, business, [and] life.” The framework is based on 10 laws ranging from straightforward design principles to “deep” conceptual aspects, from information presentation to the dialectic simplicity-complexity relationship.

This work discusses the design rationale of LGBTrust through the lens of simplicity laws. Section 2 provides the theoretical foundations needed to comprehend the work. Section 3 details our codesign instance, from recruitment to evaluation. Section 4 discusses how simplicity underlined the application design, drawn upon an evaluation by HCI experts. Finally, we discuss our findings and possible future directions in Section.

2 Theoretical Foundations

2.1 Philosophical Stance

Scientific works are based on a set of assumptions that shape how the scientist sees the world. In his seminal work, Kuhn [6] names such sets “science paradigms.” One can think about paradigms in terms of ontology (how one regards reality), epistemology (how one regards knowledge), and axiology (how one regards values). For each of these, a subjectivist or an objectivist stance might be taken. While the former might assume that reality is universal, fully apprehensible, and not influenced by personal values, the latter regards reality as a personal construct, shaped by our subjective experiences and values as well.

Ponterotto [9] summarizes four major paradigms according to such aspects: positivist, post-positivist, constructivist-interpretativist, and critical-ideological. It must be stressed that these classifications intend to guide decisions and to explain core characteristics of each approach, but in practice the paradigms contributions are often blended. More important than to automatically adopt a fixed set of such contributions is to be able to coherently adopt the stances more suited to the specific quest.

In this project, our assumptions fit better in the critical-ideological paradigm. In our view, reality is framed and constructed by socio-historical processes and collective interaction. Therefore, what we can learn from it is dependent of our own feelings, culture, and values. Furthermore, the dynamics of power in society creates oppressed or disenfranchised groups, whose emancipation or empowerment is the purpose of science development.

2.2 Socially-Aware Computing (SAC)

In order to achieve our critical goals, we adopted a codesign methodology, defined as “the action of jointly working with people, using diverse artifacts (…) to clear up meanings they build to what a product may become, engender a shared vision about the product and involve the parties, especially the most interested (…) in the design process.” [1] Codesign is the core of the SAC framework [2], which aims to articulate knowledge and experience from diverse interested parties into a socially meaningful artifact.

SAC is rooted in the theory of OS [7]. In OS, an organization is seen as an information system (IS) composed by three nested layers (each one is an information system by itself). The most external layer is the informal IS, comprised by the organizational culture, values, beliefs, expectations, commitments, and others. The middle layer is the formal IS where bureaucracy instantiates the previous layer into norms, rules, laws, and regulations. The inner layer is the technical IS where materials and artifacts mediate processes in the previous ones. This scheme is depicted at Fig. 1 in the form of the “semiotic onion” (SO). In SAC, (co)design activities are intended to “peel” the onion carrying social knowledge to a novel technology which will, in turn, affect and influence the outer layers.

Fig. 1.
figure 1

(Co)design activities and their inscription in the SO.

Full size image

In SAC, different interested parties meet in workshops where they engage in PD activities to collectively construct artifacts which will guide the system development. Due to this, it can be named a “semioparticipatory” approach. From the point of view of the critical-ideological paradigm, OS theory is compatible with the assumed ontological and epistemological stances, since it advocates for a reality constructed by responsible agents’ actions and experienced with the mediation of signs [7], following the tradition of Peircean semiotics. The participatory approach is also suited to lessen our own biases’ influence and to carry meaningful knowledge from people affected by LGBT-phobia.

2.3 Maeda’s Laws of Simplicity

The laws of simplicity (LOS) were first published in a homonymous book by John Maeda [8], where he presents a framework of simplicity ranging from design to life. The laws might be grouped in three sets of recommendations: laws 1–3, laws 4–6, and laws 7–9, spanning from “basic” simplicity immediately applicable in design to “deep” simplicity, which approaches more subjective or complex conceptual aspects. Law 10, “the one,” is a summary of the others. Next, we present a brief explanation of the 10 laws.

Law 1 (Reduce) says that “the simplest way to achieve simplicity is through thoughtful reduction.” This reduction is guided by the SHE acronym: shrink, hide, and embody. Law 2 (Organize) states that systems components must be organized to make it seem fewer by implementing another acronym, SLIP: sort, label, integrate, and prioritize. It is related to information visualization and also mental categorization processes as described by Gestalt theory. Law 3 (Time) also uses the SHE acronym to balance the tradeoff between reducing the time spent in a task as well as the feeling of spending time in a task.

Law 4 (Learn) says that “knowledge makes everything simpler.” It also has an acronym, BRAIN: “Basics are the beginning; Repeat yourself often; Avoid creating desperation; Inspire with examples; Never forget to repeat yourself.” It also advocates for the culturally-aware use of the relate-translate-surprise functions of design, which should first create a sense of familiarity in the person interacting through a translation of this familiarity in a service or component, and, ideally, insert a little surprise. Law 5 (Differences) stresses the dependence between simplicity and complexity – one needs the presence of the other, ideally in a rhythmical way where one is enhanced instead of cancelled out. Law 6 (Context) closes the medium simplicity set stating that “what lies in the periphery of simplicity is definitely not peripheral.” It highlights the tradeoff between the boringness and meaningfulness of familiarity and the thrill and danger of being lost.

Law 7 (Emotion) stresses the need of provoking emotion, even though it might require a move towards complexity. Law 8 (Trust) deals with the balance between the ease obtained by what the system knows about you and the control resulting from what you know about the system. Law 9 (Failure) highlights there might be “flaws” in the framework – some things could (or should) never be made simple.

Finally, Law 10 (The One) summarizes everything: “simplicity is about subtracting the obvious and adding the meaningful.” The 10 laws are also directly related to each other – emotions might aid learning, which reduces time to perform other activities; context provide situatedness in the differences dynamics; and so on.

3 Codesign Activities

3.1 Recruitment

The recruitment for SAC activities was made online, via calls for participation in Facebook groups dedicated to LGBT issues. The posts called participants interested in the subject or engaged in social activism to join a research aiming to develop a novel mobile application to fight and prevent LGBTphobia. In order to achieve a balanced stratified sample, volunteers were randomly picked from the interested groups. The final group of participants was comprised of 24 peopleFootnote 1: 3 genderqueers (1 bisexual, 1 pansexual and 1 homosexual), 1 homosexual transgender man, 2 transgender women (1 heterosexual and 1 bisexual), 5 cisgender heterosexual women, 2 cisgender heterosexual men, 4 cisgender bisexual women, 2 cisgender bisexual men, 1 cisgender lesbian, and 4 cisgender gay men.

3.2 Overview

The activities were split into two phases – Organization and Context Analysis, which aimed to understand the LGBTphobia context experimented by participants and its relations with technology, and Codesign, which involved techniques to create and evaluate the application. Each workshop was named after a relevant character for the LGBT community, chosen by participants at the end of the meeting. Besides in-person meetings, volunteers could also engage in online warm-ups available through the Consider. It website, a public online debate tool. In these warm-ups, one or two ideas emerged in a workshop were explored prior to the next one. Not all volunteers engaged in both forms of contribution, but every one joined at least one activity, virtual or not.

In the first workshop, Alan Turing, volunteers and researches met for the first time and participated in a storytelling activity, where experiences related to LGBT issues and activism were shared. In the next workshop, David Bowie, two systems were explored (the Espaço Livre app, which intends to create a map of homophobia in Brazil, and the website of the Federal Chamber of Deputies) and discussed in terms of how they (could) aid the fight against LGBTphobia. The third workshop, Ellen Page, bridged both phases by analyzing the network behind a prospective system and listing interested parties using a stakeholder diagram and their respective issues on the application.

In the fourth workshop, Dandara, the concept of the system was constructed after brainwriting and braindrawing activities. The paper prototype was transformed into a digital prototype for evaluation in workshop Cássia Eller. Finally, open issues on the features conceived for the application were discussed in workshop Laerte. Two evaluations were performed – an evaluation of simplicity with HCI experts and an evaluation based on cultural values in the last workshop, Freddie Mercury.

3.3 LGBTrust

The resulting application was named LGBTrust after Laerte workshop. It aims to build a safe environment for people to collectively articulate pillars of the fight against LGBTphobia, such as education, protection, empathy, and sociability. Its main features are:

  • An information portal, with news, external links, and other content related to LGBT issues

  • The share of experiences, which could be 3 types: mobilizations (collective engagements such as manifestations, meetings, events, etc.), stories (personal narratives intended to relief emotional pain, motivate people going through similar issues, etc.), and reports of violence or prejudice episodes.

  • A panic button, which sends a pre-configured message to pre-defined contacts and nearby users via SMS or notifications push.

  • A ask for help section where people can directly reach registered partners such as NGOs and activists to ask for assistance in ongoing issues.

4 An Analysis of Simplicity

The evaluation of simplicity took place in between Laerte and Freddie Mercury workshops. The group of HCI experts was composed by UNICAMP students and teachers. 9 participants joined the activity. An application installer was made available in a cloud storage and participants were instructed to download and install it. Then, participants were distributed in 3 groups and instructed to navigate the application according to a scenario assigned to each one. Scenario 1 was a person in need of orientation after witnessing or experiencing a discrimination episode; scenario 2 was a person willing to share an experience or goal related to LGBT issues with other people; and scenario 3 was a passerby who had identified an imminent danger nearby. For each scenario, a task was defined to introduce users to the application; after finishing the task, participants were free to explore other interactions. The tasks were, respectively, to register and ask for aid to partners, to register and share an experience, and to login and ask for help. A debriefing was realized in the end.

4.1 Navigation and Structure

In the braindrawing activity, a map screen was defined as the landing page, containing the panic button in an easy to access area and buttons to the main features. In the final version, general navigation is performed in two bars: a top one containing the application logo, the panic button, a help button, and an icon for a general menu, and a bottom bar with icons to the information portal, timeline, map, ask for help, and profile pages. The evolution of the landing page is shown in Fig. 2.

Fig. 2.
figure 2

From left to right, screenshots of the landing page in the paper and digital prototypes and evaluated application.

Full size image

Experts’ feedback pointed out that although it is easy to master the use of the application, in accordance to Law 4 (Learn), this multi-menu navigation was onerous. In order to improve it, some suggested removing items of the bottom bar, following Law 1 (Reduce), and grouping the panic button with the others, according to Law 2 (Organize). However, these recommendations were not consensually agreed. For instance, the repositioning of the panic button might violate Law 8 (Trust), by making it easier to be triggered by accident. Also, the bottom navigation bar as-is allows one-click access to all core functionalities of the application. By hiding these features, one might misbalance the embodiment of qualities stated by Law 1 (Reduce) and the background awareness required by Law 6 (Context).

Nevertheless, one suggestion was consensual – the removal of the help button in the top bar. When clicked, the help button displayed an overlay window with information about the currently displayed page. Experts pointed out that the button could be hidden in the main menu pursuing Law 1 (Reduce), also preventing a violation of Law 2 (Organize), due to the presence of multiple components with the label “help.” Instead of this navigation-aware help, the first-access tutorial could be reformulated to provide a global vision of the application, still contributing to Law 4 (Learn) and avoiding user to feel directionless, according to Law 6 (Context).

4.2 Share of Experiences

In the Laerte workshop, two alternative exploration tools were planned for user content: a map and a timeline. The presence of hate content in social media boosted debates on security concerns such as malicious people tracking targets, exposition of personal data, and prejudice broadcast. Such debates resonate with Law 8 (Trust) and resulted in mechanisms such as the possibility of reporting and anonymously creating content.

The timeline similarity with Facebook news feed was said to contribute to Law 4 (Learn) and its layout was highlighted by comments in Law 2 (Organize). In the map screen, each type of content was represented by an icon figure, proposed in the first digital prototype (a raised fist for mobilizations, a speech balloon for stories, and a loudspeaker for reports). In the version presented for evaluators, no identification was presented in the timeline, which was also criticized according to Law 2 (Organize). The different kinds of content were also mentioned as a contribution to Law 6 (Context).

New content could be created in the timeline screen, by fulfilling a form requiring the type of content, a place, a date and time, a summary, a description, identifier tags, and whether it should be anonymous. The form was also mentioned to violate Law 1 (Reduce), while some Android chosen components such as date/time and location pickers were praised for contrasting a complex data with a simple interaction in terms of Law 5 (Differences). In order to simplify the form, it was suggested to transform the radio buttons containing the type of content in different floating buttons which could be shown when the main one is clicked and to display it also in the map screen.

Other concerns around Law 8 (Trust) were discussed during the workshops – since the panic button might alert nearby users, it is necessary to prevent a false sensation of security when triggering it. Thus, a button was added in the map screen to display how many users were nearby. This button would also be hidden in the floating button in this screen.

4.3 Registration

Hate content also motivated concerns about registration. After Laerte workshop, it was defined that the registration would be available in two ways – after an invitation and as a partner. The latter was still not implemented for the evaluation. For the former, one must receive an invitation code from an already registered user via e-mail or SMS. Then, the registration is a 4 step process split in 4 different screens: first, the user insert the invitation code; if valid, the user is invited to provide the phone number to be associated with the account; then, the system sends a second phone code via SMS and asks the user to insert it in the third step; finally, the user is requested to provide full name, e-mail, password, and to agree to terms of use.

Experts mentioned the registration was too lengthy to complete due to its many steps, violating Law 3 (Time). Registering in the application is a sensible issue in the perspective of Law 8 (Trust), since it must assure as much as possible that the user is real, identifiable, and well-intentioned. It is an example of application of Law 9 (Failure), since the verification is inherently complex and impossible to be fully simplified without losing the security expectations. However, it is possible to simplify its current form according to some given suggestions. Firstly, the system could retrieve phone number or e-mail information automatically from the code generation, not needing to ask the user to insert it. The system could also detect SMS receiving and instantly validate the phone code. The perception of time could also be softened by providing a “big picture” of the process via a progress bar or the unlocking of options in a one-screen multistep form.

4.4 Help Calls

The application provides two ways of asking for help – through a panic button and a contact form with partners. For the panic button, the main concern during the workshops was to provide a fast mean to access it – resembling Law 3 (Time) – and to avoid mistakenly triggers – resembling Law 8 (Trust). Besides placing it in the top bar, a chronometer was added to the panic screen – until the chronometer finishes, the user would be able to hit the “cancel” button and stop the panic call. The first debated version of the other kind of help placed it as another type of user content and allowed users to ask and offer help among them. Again, Law 8 (Trust) was somewhat approached since some raised the concern about malicious or unprepared people attending the calls. It was decided to put users in contact only with registered partners, resembling Law 9 (Failure) by considering such activity too complex to be simplified by a direct contact between users.

The overall simplicity of both screens was mentioned while discussing Law 5 (Differences) due to its contrast with the complexity of user generated data. Also, the chronometer used along the panic button was complimented according to Law 3 (Time) and the exhibition of a list of registered partners in a separate tab also according to Law 8 (Trust).

The headline “Preciso de ajuda” (Portuguese for “I need help”) in the call for aid screen was criticized for being confusing with the intention of asking help via the panic button. While some experts suggested merging both, others pointed the need of the panic button to be easier to trigger and a separate icon and suggested it was more an issue of labeling, approaching Law 2 (Organize). Others mentioned the absence of a third way of asking for help, which was not urgent as a panic call, but also not so sensitive to depend on a trusted partner, as an oversimplification violating Law 9 (Failure).

Observations were also made regarding what happens after the panic call is triggered. In its current version, the application displays a pop-up window informing the call was sent to user’s contacts. Some experts argued that it violates Laws 6 (Context) and 9 (Failure) for not showing the user whom the request was sent to, neither providing ways to tell when the call was accidentally triggered. Suggestions included to display the list of contacts in the panic screen (it is currently displayed only in the profile page), to manually select who should receive the call, and to display notifications as people receive the message. While the two first suggestions might increase context awareness, they could also violate Law 1 (Reduce) by adding extra information arguably meaningless in a moment of desperation. Furthermore, Law 3 (Time) would also be affected. A possible middle ground would be to have a single notification opened in a sort of “panic state,” allowing more complex interactions such as to cancel the call or to share current location but not adding complexity to the trigger itself.

4.5 General

When evaluating Law 7 (Emotion), the application was considered comfortable and suitable for the sentimental background when sharing experiences or asking for help. However, the design was criticized for not directly evoking emotions, for instance, using emojis. The application aesthetics was praised, including icon and color choices. When summarizing the findings in Law 10 (The one), experts mentioned the distribution of features along the screens, the sensation of security, and the ease of use.

The overall averages of grades given by HCI experts for laws 1–10 were, respectively, 3.4, 3.5, 3.9, 4.1, 4.0, 4.5, 4.0, 4.1, 3.5, and 4.4. The grades are depicted in Fig. 3.

Fig. 3.
figure 3

Average of grades for each LOS.

Full size image

5 Discussion

All LOS received grades above 3, with Law 10 (The one) exceeding 4, which suggests the application has successfully achieved the goal of simplicity. The most frequent compliments regarded the application layout, the safe environment it provides, its ease of use, and the articulation of multiple parts of a complex context. As of the most recurring drawbacks, we highlight the (over) complexity of forms, the confusing contextual help, and the misleading labeling of help calls.

No detailed presentation of the application was given prior to the evaluation and just one HCI expert in the group also joined the workshops process. While the lack of familiarity arguably privileged an impartial view of the application, it also opened room to conflicting suggestions – for instance, one participant mentioned it should be possible to share more types of content, besides the available. Thus, the analysis and debriefing of observations also required filtering the comments so that concerns, values, and interests developed in workshops were not overwritten by “outsiders’” contributions. Consequently, the results of the evaluation are somewhat constrained in technical comments. The contribution of HCI experts who also are part of the codesign cycle could be further explored in other works.

Even though the LOS could be applied in other domains, as reflected in Maeda’s book subtitle - “design, technology, business, life,” they are more common in design contexts. Due to the long timespan of workshops, we preferred to make just one meeting for final evaluation and focus it on cultural values rather than adapting the framework for a general audience. Therefore, subjective reflections on the critical role of simplicity were assigned to the leading researchers rather than the subjects themselves. We believe the involvement of subjects would require some training, since the association of laws titles and statements is not always immediate and might be confusing even for experts (e.g. Law 9 (Failure) which was incorrectly regarded as bugs-related by one evaluator). It must be noted that Maeda brings plenty examples not related to design in his book. Future works might further explore the contribution of non-technical participants of the codesign cycle in evaluating simplicity as well.

Since oppressions are multifaceted and often intertwined [5], the fight against them is inherently complex. The LOS were a proper framework for evaluating and reflecting on the application in such context, specially due to its stress of the relation between complexity and simplicity. The “deep simplicity” set shaped features in terms not only of what could be done, especially using Law 9 (Failure) but also what should be done, raising concerns around privacy, comfort, and autonomy. Finally, it must be noted that a future redesign does not imply in an end point to the process. The production of new signs via interaction with and through the application favors the concept of perpetual beta rather than final versions.

6 Conclusion

Such as other social concerns, the fight against prejudice is complex because it involves multiple parties, with different interests often intertwined with other kinds of oppression. In this work, we analyzed the development of a novel application using the lens provided by Maeda’s LOS. An evaluation with experts was also performed, not only raising successful instances or violations of Maeda’s laws, but also suggesting possibilities for the redesign cycle. Moreover, we verified the LOS potential influence in the conception and ideation of social applications, adding to its most direct use in design. Ongoing work in this project involves analyzing cultural aspects in the LGBTrust, as perceived by the involved people using it.