Picture this. You live in a colder-than-freezing place, and design and manufacture a jacket for your usage. It’s a pretty good jacket, and so you ask your local friends if they like it. They do like it, and you end up manufacturing and selling jackets to your whole neighborhood, then town, and state.

You’re doing great, and so you decide to go international. You sell to markets in places with similar climates as yours, and the business does well. Then you expand all over the world, and suddenly find that the jackets don’t sell as well. You’re confused, but push on. You keep offering your winter-friendly jackets in tropical countries, and never realize why your jackets don’t sell as well.

In the industry, this is loosely what is known as ‘universal design’, the idea that something can be designed such that it works for everyone, across a whole spectrum of potential users. Obviously from the above example, you can tell how I feel about it.

In this story, and in some other cases, a universal design fail can just be passed off as silly or misguided, but ultimately benign. Users and non-users alike can simply laugh at some failed product or misfitting marketing, and move on. But in more severe cases, universal design can lead to inaccessible products that often exclude the most historically marginalized populations, most commonly users with disabilities. And in some extreme cases, products designed and built in one environment but deployed in another, can spell death for users in contexts in which they were not designed. Just ask Drs. Advaith and Ajmal Asif, of Kerala, India.

At 12.30am on Sunday the 1st of October in the Gothuruth area of Kerala’s Ernakulam district, the two, and three other friends, were driving back from late-night shopping. Completely in their senses and not under the influence of alcohol, Dr. Advaith was relying on navigation software to get through an unfamiliar area. They were following the navigation which was indicating that they should go through what appeared to be a waterlogged street, a common feature in the Indian monsoons. Without thinking twice about it, Dr. Advaith drove on the suggested route, and found themselves going into a river. The car began sinking and although three of the five were able to come ashore safely, Dr. Advaith and Asif lost their lives underwater. All because of their reliance on a service that is globally renowned, but ultimately not designed for their context: Google Maps.

This is not even the first instance of Google Maps leading users horrifyingly wrong into life-threatening or ultimately deadly situations. The first author themselves has lived experience of Google Maps directing them on to an unfinished flyover in India. Faulty directions took a family in New South Wales, Australia off the highway onto a dirt road that left them stranded in the Australian outback where they were stranded for two days, drinking water from puddles until they were rescued by a wide community search. A Spanish tourist in Rio de Janerio was shot and nearly lost their life after driving into notorious gang territory after Google Maps led them astray en route to the Christ the Redeemer statue. Tourists and hikers in the Italian town of Baunei were continuously misled on to secluded mountain roads instead of their intended tourist destinations over a 140 times in the span of a few months, leading to locals putting up signs saying “No Google Maps” in various parts of town. Even in the American contexts, Google Maps can mess up in terrible ways. In September 2022, a man in Hickory, North Carolina was directed by Google Maps to drive across what turned out to be a broken bridge that had collapsed almost a decade ago. The man fell to his death and his widow sued Google for the incorrect information, despite the fact that Hickory residents had suggested edits to Google Maps to indicate that bridge as broken two years prior to the incident.

Google Maps was designed in and by American researchers, based on the CIA-supported acquisition of geospatial data company Keyhole, the company whose satellite technology pioneered Google Earth. Designed and tested mostly in American contexts, Google Maps was made available to the rest of the world based on this satellite coverage, which disproportionately captured American/Western places and was geared towards gridlike city designs like a lot of American/Western cities. To expect that it would work the same in remote corners of India, Australia, Kenya, or other places that are not built the same as the places where it was trained is not only inaccurate, but also deeply dangerous.

Unfortunately, such design is not uncommon, and Google Maps is far from the only proponent of the one-size-fits-all model. The modern craze of LLMs and tools like ChatGPT across the world is demonstrating how well it performs in languages like English and contexts like the US, but the performance curve quickly tapers off in different languages and contexts, especially ones that are traditionally underprivileged. This pattern of designing in one context and shipping across others, without consideration for the difference in cultures, traditions, and practices, is an unfortunately common but symptomatic practice of designers with high degrees of privilege. Either intentionally or otherwise, designers can wield their privilege to design and deploy their products across different contexts without proper groundwork, living under the myth of universal design.

If you’re reading this and are a designer (we’re all designers, either by intuition or by practice), I implore you to consider the contexts in which you are designing, and whether your own mental models align with them. In cases where they do not, try working with the local communities for whom you are designing, talking about their specific needs and use cases. Work with them as ‘humans’, and not ‘users’: treat them as real people with real lived experiences, rather than users to extract information from. Most importantly, test in local contexts and think about how you can maintain and fix errors.

None of this is necessarily novel information: the existence of my field of Human-Centered Design predates a lot of these thoughts that I am putting out here. But I felt this to be an important story to tell, both in the honor of the people who lost their lives as they relied on products marketed to them but not designed for them, and for those who might yet be working to design what they intend to be universal design.

Dear Reader,

I’m not who you are, and what your story is. But if you’re here, you’re likely an early career academic, or at least someone slowly gaining institutional power in whatever capacity you’re working in. In this note, I’m writing about my own unease and anxiety in exercising my little institutional power, as evidenced in my context of having to write rejection emails.

Let me start with some context. As I write this, I am an international student to the US, from Calcutta, India, and as such am subjected to systems of power and privilege that I’m sure other people in similar situations might understand. In this more specific context, I am a rising 4th year Ph.D. candidate in the department of Human-Centered Design and Engineering at the University of Washington, Seattle. As a part of my program and indeed my training as an independent academic researcher, I am required to organize and lead research groups with students of all levels across my University.

I led my first research group in the second quarter of my first year, a small group of 4 students in an online-only quarter. Although I have advertised for and led several groups since, I have been fortunate so far to have been in situations where applicants self-selected themselves for participation based on my criteria and times, such that I’ve never had to send out rejections to applicants. Not until now.

This quarter, I advertised a self-directed research group, inviting upper-division undergraduate and Master’s students to participate in 1-on-1 research with me. The goal of this group is for students to pitch me research questions and methods that align with my own interests, such that I can support and mentor them in their research endeavors. I am to gain experience and practice mentoring budding researchers in pursuit of my eventual goals of becoming a University-level professor, while students would stand to gain skills and potential traction in their career goals after graduation. As a solitary student leading this group while also trying to prepare for my Dissertation proposal and graduate from this Ph.D. on time while also managing my own teaching commitments, I advertised the group as having the capacity to accept 5–6 individuals or projects.

In the six days the application was open, I received 22 applications. 22.

While also dealing with personal and non-academic situations, I have been severely anxious over the past few days, in this evaluatory role that I knew would one day come, but I expected to be more prepared for it. I keep asking myself what authority I, as a young early-career academic who would not have been here without the opportunities I have been given when I was in these applicants’ shoes, have to turn down their requests for a similar shot. At the same time, there remains the overwhelming impostor syndrome that I still have not been able to shake off, the feeling that I have no right to be providing them any research mentorship or indeed give them skills to further their careers which they could and should seek elsewhere.

But finally, after I did make a few decisions, came the uneviable task of writing rejection emails. Anyone who knows me, knows how difficult I find it to say no. In academia and in life, I have built a habit of always saying yes to people and things without sometimes considering my own capacity to execute what I signed up for why also practicing self-care. Indeed, I did very seriously consider saying yes to all my applicants and bring on the same pressure again, a decision that would have undoubtedly set me up for a brain-shattering year with little sleep and self-care, a decision that people who love and care about me did not let me take. To not do that, meant that I had to teach myself to write rejection emails.

I started as my anxiety and impostor syndrome taught me to, by reading the long list of rejections I’ve personally gotten. If you’ve got one, and I’m sure you have, you’ll know what I’m talking about. “Thank you for your application,” “large number of applications,” “unable to move forward with your application,” etc. etc. etc. Copy-pasted, done-to-death, overused text, sent out in mass-generated emails. Reading them reminded me of the feelings of failure and disappointment I’ve gone through over the years, and yet, when I started writing mine, I found myself going back to those words.

After several hours of hand-shaking anxiety and several thousand words backspaced, I landed on a format I was satisfied with. Copy-pasted and common rejection text, followed by a section explaining why I was unable to accept their application while still providing them motivation to keep pursuing their research goals. I have attached one of them here.

I do not know how these will land, to be honest. I am writing this article immediately after queuing the last one up for tomorrow morning, and I could be making a mistake in my choice of structure. I do not know.

I’m writing this in the hope that you, my reader, a potentially early career individual with low (but hopefully, rising) institutional power being made to exercise it, can find comfort in the fact that you’re not alone in this. For people like us who have grown up with low power/privilege and have been on the receiving end of power decisions being left feeling how unfair it is, the resolve to not do the same when you gain power is strong but difficult to execute. There is so much research on how people with low power being the ones who exercise the most caution and are the most cautious, but not nearly enough on how not cared for they are as they overextend themselves to provide care for people with lower privileges under the auspices of institutions driven by capitalistic motivations. This work is hard, I feel it, and if you’ve done it before, you probably know that. But as people who have been lower on the ladder, we must hold on. These are growing pains, and make no mistake that they are painful, but these are good pains to have, pains which honor the struggles we have come through and the care we can provide ourselves and others who come after us.

I hope that we continue to be mindful in exercising the power, however little you may have, and in ways that are not overextending yourself. And if you’re ever having trouble writing rejection emails or generally reconciling your application of said power, I hope you come back to this, or reach out.

Data Science has been defined as “ a set of fundamental principles that support and guide the principled extraction of information and knowledge from data.” It is a practice of combining several fields, such as statistics, mathematics, computer science, information science, to examine data sets (often, large data sets) for knowledge production. Everywhere we look around us, data science is silently operating — on our phones, in our classrooms and workplaces, and everywhere else.

Data Science is concerned with the aggregation and interpretation of datasets. Consider, for example, your entire history of tweets, or Facebook posts. An algorithm can easily be designed to scrape (i.e. collect) those tweets and all the associated metadata, such as timestamps, location, numbers of likes and retweets, etc. Now imagine this information being collected for everyone you know, and everyone they know. Millions of data points about all of their tweets, collected and condensed into one large database.

But what of the contents in those tweets? Sure, the algorithm will collect their character/word counts and maybe, if some more sophisticated metrics are applied, even measure things like affect (i.e. nature of emotional expression) or language proficiency, among other things. But what do these algorithms know of the individual, the real you, that you poured out into these tweets? Will they truly understand your 16-part tweet gushing about Taylor Swift’s latest album? Will they know exactly how hard you cried at the end of Supernatural? Will they understand your very niche interpretation of Loss? Will they understand why you keyboard-smashed “AGUEROOOWRIIRIBVHXAEAOC” on May 13 2012? Will they? Can they?

Human-Centered Data Science attempts, through a combination of qualitative and quantitative metrics, to honor the “compelling and inspiring stories of individuals in the sea of aggregated data at scale.” The interdisciplinary field attempts to incorporate and contextualize the often-invisible but very real people creating data points, as it attempts to give every datum a voice to tell its own story.

A part of this process is to acknowledge some sense of uncertainty, and subjective interpretations of meaning and context. But Human-Centered Data Science is okay with this. As Marcia Bates writes, “If we use, rather than ignore, the special traits of humans in the design of human-computer interfaces for information systems, we may find our abilities enhanced in unpredictable and creative ways.” Human-Centered Data Science is about embracing this unpredictability, and truly letting the data take researchers on a journey.

The Human-Centered Data Science process also considers the ethics, potential biases and harms that can occur from the process of aggregating and operating on large sets of human-generated data. Such considerations are important and essential to the research process, now more than ever.

I therefore submit to you that the way forward in Data Science is a Human-Centered one, with the view of adequately respecting the humans underneath each cell in those large spreadsheets. I leave you with the invitation to check out the upcoming book on Human-Centered Data Science by the founders in the field, and hope that you will consider incorporating such methods into your practice.

As we walk in to the new year, we do so in the now very-precedented times of living under the scourge of the Coronavirus pandemic. However, many college students and instructors now find themselves in an unpredictable situation with a massive sense of deja vu: not knowing what the mode of instruction will be. Personally, I start the Winter quarter today at the University of Washington, Seattle where the University has made the decision to implement remote learning for the first week of the quarter and then reassess the situation after that. Similar decisions have also been made at other universities like Harvard, Stanford, Duke, Northwestern, and many others.

The greatest difficulty this uncertainty is posing for me is determining the types of activities and content I will present in the class that I’m teaching this quarter. I find myself uncertain whether to plan for a fully remote, hybrid or mostly in-person format of learning. What is even more difficult is that the situation might rapidly change as the quarter goes on, as the state continues to monitor the infection and case rates.

If you’re an instructor teaching a college course this Winter and find yourself in a similar predicament, here are some tips I’ve put together to prepare content that is easily pivotable between remote and in-person learning.

Consider pre-recording lectures

I’ve personally found great benefit in pre-recording lectures for these uncertain times. This works for both in-person and remote settings because students can then consume the content at their own pace (usually at 2x speed, if I’m being honest) and class time can then be used for a shorter overview of some of the important highlights of the content and providing clarifications / answering questions on the material. This mode also somewhat equalizes students and instructors' access to Internet infrastructure and bandwidths, and helps manage attention spans.

Consider using Miro boards for activities that would normally involve sticky notes

Perhaps the remote learning software that I have used the most is Miro, a good alternative to using sticky notes for class or other activities. Even in in-person settings, I believe that Miro can be an effective tool where sticky notes would otherwise be used. This makes it easier to retain the information documented, which otherwise would have an extra step if physical sticky notes were being used.

I hope this is helpful to some of you, and I look forward to hearing what works for you in your classes! Hang in there, we’re going to get through this.

If you’ve been following technology news over the past week, you might have noticed Amazon Alexa’s latest fiasco, in which the smart assistant recommended the ‘penny challenge’ to a 10-year old child. When asked to suggest a ‘challenge to do’ by the child, Alexa recommended to “plug in a phone charger about halfway into a wall outlet, then touch a penny to the exposed prongs”. The child’s mother was on hand to prevent the child from carrying this out and risking a dangerous electrocution, as she later narrated the incident on Twitter. This tweet was circulated by other users as news agencies also picked it up, leading to a statement by Amazon where they announced updates to Alexa to prevent it from recommending such dangerous activities in the future.</p>

However, close inspection of this incident could reveal that this issue is larger than Amazon applying a quick fix to prevent such recommendations in the future. This incident is an evidence of loose content moderation, letting dangerous content seep through filters and be picked up in searches by Alexa.

To understand this further, let us take a quick look at how Alexa answers our questions. For instance, when a user asks Alexa, ‘what is a dragon?’, it is equivalent to them conducting an Internet search. Alexa, as a competitor to Google, uses Bing’s search engine instead. It performs the search and speaks out the top result, starting with the name of the source. It also crowdsources information and answers to questions it does not know how to respond to, through its platform Alexa Answers. These responses are routinely vetted by “a combination of automated systems, community members, and Alexa Answers moderators” and only after being approved do they go ‘live’.

The trouble with searches and crowdsourcing information is that if a large-enough group of people search for or participate in something on the Internet, that surge in activity pushes the content high up the relevance index and brings it to the notice of content crawling algorithms. There is no room in the algorithms to decide whether it should pick it up, they must act on the rapid user buy-in. Take the penny challenge for example. It rose as a TikTok trend in 2020, with several hundreds of users attempting the challenge and receiving thousands of collective views. It makes sense that search algorithms observing this massive amount of engagement would pick up such content during these surge periods.

However, it would then fall on human content moderators to act as a line of defense, recognizing the dangers of recommending such content. This is the sad reality of the content moderation industry, as it takes an incredible psychological toll on the individuals who daily view disturbing and possibly traumatizing content for a living. It is quite possible that some content slips through the cracks, and I cannot blame them for it.

To Alexa’s credit, it did do a better job the last time a massively dangerous challenge went viral, profusely asking users to not do the Tide Pod challenge. However, its failure to censor against the penny challenge reflects that there is work to be done. Amazon’s response to this resulted in some ‘updates’, which users claim results in Alexa not answering the question ‘tell me a challenge to do’, the original question at fault. This cannot be the overall solution, as there can be several other questions that can recommend dangerous content to users. This incident brings to light a larger problem of content moderation and indexing, which will likely need broad changes to how content moderation is currently done and how algorithms select answers to recommend.

I’m sure some of you will understand what I mean when I talk about the emotion of cleaning out the final item on your to-do list of the quarter. It’s a mixture of joy, satisfaction, relief, excitement and so many others that I cannot name.

A few weeks ago, I wrote a mid-quarter review highlighting the beginnings of my in-person experience of grad school, after spending my first year completely in the confines of my then-apartment. I wanted to take this present opportunity to finish that story, now that the busy second half of the quarter has passed.

Over the course of this quarter, I have met and had an in-person conversation with a new person for at least 50 days, after which I stopped counting. These conversations were rich and stimulating, even if they were first meetings and on subjects that only one of us had any knowledge on. Especially rewarding have been conversations where other people spoke to me about their interests or ongoing work, with excitement and passion in their eyes and mannerisms. I didn’t retain most of this information, but in those moments, I remember feeling incredibly alive.

The highlight of my quarter invariably has to be my prelim presentation, my first milestone of the PhD process. The presentation was an opportunity to learn about the work of other students in my cohort, as well as presenting my own. I met a lot of researchers within our department for the first time through this presentation, and received valuable feedback that I’m sure will help me become a better researcher.

Another important aspect of this quarter was teaching my first in-person class, an introduction to Human-Centered Design. It was a tricky experience to manage a hybrid course, with our students being split about 50/50 in-class and online. However, they found ways to succeed and do good work while managing the circumstances of the transition to in-person learning, and I’m incredibly proud of their work!

Overall, I can say in no uncertain terms that this quarter will be remembered as a success. I look forward to going full steam ahead for next quarter, and a relaxing break!

Jk, here’s my todo list for break. Wish me luck!

As my first in-person quarter of grad school at the University of Washington wraps up, I’m taking this opportunity to look back at one of the largest components of my past quarter: teaching a hybrid class.

Since my second quarter at UW, I have been a Teaching Assistant for an undergraduate course in my department, titled ‘HCDE 318: Introduction to User-Centered Design’. The course offers a hands-on experience of the user-centered design process as they take on a 10-week group project from ideation and user research to hi-fi prototype and user testing. While my first two quarters of teaching this course was fully online, Fall 2021 brought about the exciting prospect of an in-person/hybrid model.

The preparation for the course started a week before the first day of class, when the professor and I met to discuss alterations to the formerly-remote course to the hybrid format. This was made smoother by the fact that this was the same professor with whom I had been teaching the past two quarters, meaning that we had already established a good rapport with each other. This made the conversation about planning a lot smoother, and the upcoming difficulties easier to manage.

At the very onset, we faced the challenge of setting up the hybrid classroom. The room was one of the department's Educational labs, designed for highly collaborative project-based courses. It consists of two independent projectors, screens, speakers, whiteboard walls and tables, and an assortment of prototyping supplies. We were also granted access to a hybrid-meeting accessory: the Meeting Owl Pro. The mic, camera and speaker device would be integral to developing the hybrid experience since it was capable of following a speaker as they moved around.

We envisioned a setup where one of us would setup and display the Zoom room on one screen, and the other would display the instructional content on the other screen, while also screen-sharing on Zoom. However, this was far easier said than done. After six hours of combining our three engineering degrees and consulting with the department’s Computing Manager, we were able to come up with a reliably-replicable process of setting up the classroom on a regular basis within a short amount of time.

As TA, I took up the bulk of the responsibility of managing the setup. On the first day of class, I arrived half an hour early, nervous to execute the fragile setup in a live setting. It went off without a hitch, as we observed a fully in-person attendance. As the quarter progressed, the true capabilities of our hybrid setup were tested as the class self-organized into a 50–50 split across in-person and remote attendance. On some days, there were technical difficulties, some of which were not resolvable at the given time, but we adapted to the situation and still managed to pull off a successful class.

A big chunk of the credit for what I would like to think was a successful quarter is down to our students. They adapted wonderfully to the hybrid situation, leveraging the appropriate affordances for their benefits at any given time. When the technology was being difficult, they were accommodating. When we were doing in-class group time, in-person and remote students working on group projects found innovative ways to coordinate and work together. If not for their patience and contributions, the quarter would not have been successful.

As I reflect on the hybrid teaching environment this past quarter, I look back upon some of the successes and failures of my first time doing this. I look forward to learn from this experience and create a better learning environment next quarter, as I become lead instructor for this course!

It was 8.15 in the morning, and my stack of pancakes had just come off the skillet. I brought them to my little table by my bed and said, “Alexa, I’m eating.” It responded, “okay,” and did nothing. I said it again. “Okay,” Alexa said, and did nothing. My usual morning routine was suddenly broken, my smart lights were not responding to Alexa, and I was frustrated.

It took me two full hours after this experience until I found out what was happening, due to an unrelated incident which allowed me to connect the pieces together. When my class noticed that Canvas was down, that’s when I discovered that it was a MUCH larger issue: an outage of Amazon Web Services (AWS).

As I talked to more people and read up on some conversations on the Internet, I came to realize the scale of this outage and how many different services and groups of people it was affecting. Further reading and exploration on the web showed just how many services, such as Disney+, Netflix, Tinder, Venmo, CashApp, Xfinity, Verizon, and Amazon delivery systems, were affected. This led me to ask: how many users of these services were able to easily trace back the source of their issues to the AWS outage? More broadly, how much do we know about where our data goes and what processes it undergoes before we get results?

To me, this is a design flaw in most of these systems and services. A well-designed system should allow, according to Nielsen’s Heuristics, should allow users to adequately recognize, diagnose and recover from errors, across all types of errors. None of the systems that failed on me yesterday (my smart lights, Canvas and later my Amazon deliveries) informed me a) why the errors were occurring at a high level or b) offered me avenues to explore and diagnose the root causes.

Even if these errors are considered to be once-in-a-lifetime and definitely not part of the daily experience of interacting with these systems, it is worth building in information to address such situations. Not only would it bring less anxiety on a user having tried every possible solution available at their respective disposals, it would also be a more transparent effort in letting users know where their data streams flow and allow for informed consent when they choose to opt-in to such services.

Algorithmic bias and prejudice is nothing new to those who have been following the research along these lines over the past decade or so. The reality of natural language as source data is oftentimes in its subjective nature, and also representative of a particular country, culture, sociological and colloquial factors — and of course, its prejudices and stereotypes. In this article, we aim to explore these biases as perpetuated by Google Translate, one of the most common language translation tools used across the world from the lens of gender.

Google Translate utilizes a Neural Machine Translation system which aims to translate sentences as a whole, instead of their composite part, in a similar fashion to humans manually translating between languages. It aims to apply broader human contexts to translation, which is likely the cause of its encoding of biases. Since such systems are trained on human-validated data, it is likely that human biases and understandings of gender stereotypes are embedded deep into the systems’ workings. This not only results in creating a system that is biased on a translation level, it also reinforces the very existence of it by continuing a vicious cycle of human-to-machine transfer of subjective knowledge, where the foundational conceptions of ethics and morality are lost in the mathematics.

We will demonstrate this by employing translations into our mother tongue: Bengali/Bangla. Without delving into much detail about the constitution of languages, one key differentiating feature between English and Bengali is in their usages of pronouns. While the English language employs different gendered pronouns (‘he’ / ‘she’) and gender-neutral pronouns (‘they’ / ‘them’), Bengali uses only gender-neutral pronouns: সে (pronounced ‘shey’) ও (pronounced ‘o’) , and others. Thus, gendered and gender-neutral English texts can easily be translated into Bengali without loss of information, and translating texts containing gender-neutral pronouns can easily be translated into gender-neutral English. However, the contrary is often difficult, as it is almost conditioned in our English grammar to assign gendered pronouns, even while translating from a gender-ambiguous language.

This distinction is, unfortunately, also carried by Google Translate. When translating from our native tongue to English, it not only assigns gender to gender neutral pronouns, it does so by enforcing a large range of gender stereotypes. Below are a few examples of this activity.

Example 1:

In this example, there is no additional information in the Bengali source text to infer preferred gender pronouns of the person or persons being written about. But, Google Translate affixes the gender stereotypes that doctors and those who go to work must be men, while those who cook and clean and care for the kids should be women. Theoretically looking, this translation is not incorrect — the NMT has assigned a gender to every pronoun, and there are a few permutations to do so. However, a reasonable expected translation could be ‘They are a doctor. They cook and clean. They take care of the kids. They go to work’ — but the absence of this social sense make it unlikely for the models (and its creators) to understand that quantifiable accuracy does not capture social politic.

Example 2:

Like the previous example, the translation once again enforces a gendered stereotype in this example: that marriage is between a man and a woman, where the man asks for the woman’s hand in marriage. Yet, in the Bengali text, there is no such additional context about the people in question. The sentence in Bengali could easily have been referring to a woman asking the question, or between gender non-binary individuals. The lack of LGBTQ representation in all aspects of life, including artificial intelligence shouldn’t be lost on us.

Example 3:

In this final example, the translation embodies the gender stereotype that it is the masculine role to be a protector, shielding and caring for the feminine. As you can probably guess by now, the original sentence in Bengali makes no such claims of gender of the protector. It is fair to say that the data from which the Google translate learns from, is sufficiently fit into the parameters of male-female power dynamics that does exist in our society. Possibly the concept of accuracy and performance metrics need a broader, more involved technique than pure numbers.

This prejudice in Google Translate can and has been demonstrated to apply to a variety of languages with similar absences of gendered pronouns: Finnish, Turkish, Hungarian, Filipino, Malay, and Estonian, among others. In response to such discoveries by users, Google announced gender-neutral translations in 2020, which claims to be better at detecting the difference between gender-specific and gender-neutral contexts. However, these present results show that a lot more work is yet to be done before this problem can be resolved.

It is also prudent to end the article with this thought: where does the onus of creating unbiased, ethical and constructive artificial intelligence lie — on mathematics or on humans themselves?

Prior to my phone forcing the new Android 12 update on me, I had read some of the reviews and, suffice it to say, I was not excited about it at all. Now that I’ve used it for a week, I will attempt to explain some of its design shortcomings through a designer’s lens. I decided to write this now and not immediately after the update, because I wanted to fully explore the new features and also maybe detach myself from immediate feelings of anger about some features.

As a student in Human-Centered Design and Engineering, the principles and guidelines of good user-centered design are important lenses through which I view any designed artifact. In this article, I will highlight 3 ways in which the new Android 12 UI is not well designed. I will be using, for my analysis, 3 of Nielsen’s Heuristics, a list of 10 broad rules-of-thumb for good design.

First, a note on my positionality. I consider myself a veteran Android user, having used Android devices for the past 7 years. I use a Google Pixel 5a, a family of devices towards which the new update seems to be focused towards.

1. Visibility of system status: This heuristic dictates that an interface should always keep the user informed of its status, or allow the user to infer the state through quick and appropriate feedback.

Android 12’s status bar is an example of this heuristic being violated when there are notifications. In previous versions, swiping down the notification would either enlarge the notification and condense the icons, or vice versa i.e. display the text on the icons and condense notifications. However, a long swipe on Android 12 (Figure 1) pushes notifications off the screen and fills it with the enlarged status bar, making it so that the user can easily miss notifications or simply not be aware of them. It is impossible to tell from the image below but at the time of this screenshot, I have 12 unread notifications.

2. Consistency and Standards: A system that is consistent and follows standards will follow product and industry conventions, allowing users to easily figure out which words/actions mean the same things.

A major change from previously consistent standards in this UI is the process of switching from Wifi to Mobile Data, something I do several times a day in transit. The previous versions had two clear, distinguishable buttons on the notification dropdown that could be turned on/off with one click (Figure 2). In the new version (Figure 3), it is not clear on how to achieve that task. It took me a while to figure out that the UI now condenses those two tasks under the umbrella ‘Internet’ button, and clicking it takes me to a sub-menu where I can turn off Wifi and turn on Mobile Data, thus increasing the number of clicks while making the operation less discoverable than before.

3. Aesthetic and minimalist design: Interfaces should be minimalist in their design so as to not overwhelm the user, while also being aesthetically pleasing.

Okay, maybe this one is a stretch, but I really dislike the giant clock that Android 12 forces users to have on the lockscreen (Figure 4). It takes up a LOT of screen space and is a marked difference from previously minimalist lock screen designs. While I understand that a large clock may be desirable and much more accessible to some users, what I dislike the most about this design is the fact that the size of the clock cannot be customized. This has forced unhappy Android 12 users to get creative, leading to emergent design ideas of keeping unread notifications on the lockscreen to reduce the size of the clock.

I write this article in the hope of contributing to the user community’s displeasure about some or all of these features, and the dream of Android developers recognizing avenues for improvements that their users desire.