Why UX Will Get Worse Before it Gets Better

Why UX Will Get Worse Before it Gets Better

Rebecca Bilbro | Thursday, Jun 10, 2021 |  UX Technology

The things we make are not user-friendly by accident; we have to make them that way. And that’s hard. For most of the time people have been making things, we’ve been mainly concerned with making them user-friendly for just us. And, even if the last few decades of app development have brought more focus to the importance of empathy (especially if it helps you capture market share), the last few years have forced app developers to acknowledge the continued pervasiveness of white privilege, gender privilege, and class privilege in UI/UX. Unfortunately, as our efforts to become more intentional and empathetic as technologists continue in the coming years, there is another problem we have barely considered that will become a major threat to compassionate, egalitarian, and even subversive app development. Spoiler: it’s our cloud infrastructure.

The Voice of the User

While its originator is by no means a shining example of empathy, Linux was the first major success in community-built software primarily because its development model embraced the voice of the user. Innovation, wrote Eric Raymond in 1997, “mostly takes place in the open part of the tool where a large and varied community can tinker with it.” Until that point, in tech, the only real model of development expected direction to be determined in a top-down fashion. The problem is that the people at the top were often not tuned into what users actually needed, or the problems they were encountering when they tried to use an OS or other software tool. This, perhaps more than anything else, is what started the open source movement. And while many of us have been discouraged from OSS development platforms because we don’t conform to others expectations of what a developer looks like, there are nonetheless a growing number of black, brown, women and non-binary contributors to OSS, simply because it is often a faster, if still imperfect, path to self-expression.

Obvious as this observeration may seem, the voices of increasingly diverse users are not automatically included in the design of technology. In 1998, one year after Raymond wrote those words about the importance of users, Congress amended the Rehabilitation Act (originally published in 1973) to require Federal agencies to make all electronic and information technology accessible to people with disabilities. By the time I started working in the Federal government in 2011, making sure web content was “508 compliant” was a common refrain, though usually a painfully uncomfortable afterthought.

Now, roughly 10 years later, it finally feels like user-centered design is accelerating. I’ve long since moved away from the public sector, turning instead towards the tech startup world to follow my passion for data science, machine learning, and artificial intelligence. UI and UX have become a huge part of the conversation. We’ve come a long way from considering only the legally-mandated accessibility issues (supposing incorrectly that these are largely a solved problem) toward gender inclusivity in app development, and, only very recently, towards acknowledging white privilege in product/app design. Even so, this shift in focus to all users, instead of just users who look like us, has been slow and stilted. As UX Researcher Vivianne Castillo explains:

The UX Research Industry’s Achilles Heel rests in our inability to discuss, acknowledge and absolve the effects of unchecked white privilege and male privilege within our leadership, organizations, conferences, and research.

Of the UI/UX field’s reluctance to engage in discussions of white privilege, Castillo writes:

What we have instead is the constant repackaging and selling of best practices and ideas about how to “do” research faster and better without the call to carefully think about the biases and values we are unknowingly weaving into our research and the direct impact it has on the individuals and families exposed to the experiences and products we help create.

As a machine learning practitioner and data product developer, I strongly agree with Castillo’s view; my field is similarly confronting many issues with white privilege, bias and ethics. And yet, I worry that even with the gains we are making with developing more inclusive UIs and reflecting on the ethics of our ML, we are missing out on an opportunity to address another systemic problem that, as Castillo says, we are unknowingly weaving into our applications, in their very infrastructures.

Distributed UX Fails

If you’re a techie working in app development, you probably identify as one of the following: “backend”, “frontend” or “data science”. Possibly this is one of our failings, that we have created these artificial silos for the problems that concern our data systems, the user-facing components of our applications, and the non-deterministic algorithms that stitch them together. This view isn’t doing us any favors, and it certainly doesn’t help our users. In fact, apps suffer greatly from the dissociation of these components. You can’t build a backend if you don’t understand how the data is going to be queried, just as you can’t build machine learning models without considering how the users are going interact with them. The backend is everyone’s problem.

The recent failures of companies like Trivia HQ and of apps like Niantic’s Pokémon Go belie the strong interconnectedness of the backend and the user’s experience. As Slidebean writes of Trivia HQ’s spectacular crash-and-burn:

Livestreaming an interactive game through a mobile phone is hard. Very hard. Interactivity needed to be instant, especially if the questions are timed. But sometimes, as many users complained, clicking on an answer did nothing and time ran out. Which meant that users were kicked out. Other times, the quiz just didn’t work at all. So, when it crashed, which it did often, the hosts worked hard to keep the frustrated players from leaving before the problems were solved.

Pokémon Go was plagued with similar UX challenges that were also caused by underlying problems with the app’s distributed data storage. Akhil Dakinedi wrote:

It seems fine on paper, but once you see the extremely fast pace at which these battles take place, you start to notice the problems. The app, in its launch state, isn’t very responsive or fluid. It’s being plagued by constant server issues and unstable location tracking.

People wanted to like the game, but it’s not fun to play a game that’s laggy and slow, especially one that relies on interactivity and AR. Wrote Amber Stechyshyn:

Pokémon Go is exciting and fun and the biggest new thing, but you will find people describing it just as often as slow, frustrating, and buggy. It was released quickly, hacked even quicker to allow for those outside the US to play it ahead of time, and has had server issues ever since.

Ultimately while the failures of apps like Trivia HQ and Pokémon Go may manifest in the UI, they come down to problems with commerical cloud storage offerings. As Dr. Benjamin Bengfort writes,

The launch of the augmented reality game Pokémon Go in the United States was an unmitigated disaster. Due to extremely overloaded servers from the release’s extreme popularity, users could not download the game, login, create avatars, or find augmented reality artifacts in their locales. The company behind the platform, Niantic, scrambled quickly, diverting engineering resources away from their feature roadmap toward improving infrastructure reliability. The game world was hosted by a suite of Google Cloud services, primarily backed by the Cloud Datastore, a geographically distributed NoSQL database. Scaling the application to millions of users therefore involved provisioning extra capacity to the database by increasing the number of shards as well as improving load balancing and autoscaling of application logic run in Kubernetes containers.

This isn’t to say that the problem is inherent in GCC in particular; says Dr. Bengfort:

Niantic’s quick recovery is often hailed as a success story for cloud services and has provided a model for elastic, on demand expansion of computational resources. A deeper examination, however, shows that Google’s global high speed network was at the heart of ensuring that service stayed stable as it expanded, and that the same network made it possible for the game to immediately become, available to audiences around the world.

The problem is that commercial cloud offerings, while technically available around the world, do not offer a consistent experiences to all of those users. In fact, your UX is always strongly coupled to geographic boundaries, whether it’s hosted on Google, AWS, Azure, Alibaba, or any of the other cloud platforms. And that’s the problem — what happens when we want our app to be truly international?

The original launch of the game was in 5 countries – Australia, New Zealand, the United States, the United Kingdom, and Germany. The success of the game meant worldwide demand, and it was subsequently expanded to over 200 countries starting with Japan. Unlike previous games that were restricted with region locks, Pokemon GO was a truly international phenomenon and Niantic was determined to allow international interactions in the game’s feature set, interaction which relies on Google’s unified international architecture and globally distributed databases. Stories such Niantic’s deployment are increasingly becoming common and medium-to-large applications now require developers to quickly reason about how data is distributed in the wide area, different political regions, and replicated for use around the world.

Why UX will Get Worse Before it Gets Better

Some may think that games are low stakes. So what if we raise the stakes and consider not only global games, but global communications and policy?

In February 2020, something went wrong in Iowa. The Democratic caucuses leveraged a new voting app that was designed to enable voters to choose a presidential nominee. But the results were delayed, and when they came in, they were inconsistent. Offically blamed on an unspecified “coding error”, the app developed by Shadow, Inc (now BlueLink) almost certainly suffered from both eventual consistency and latency issues, classical distributed systems problems that were not afforded near sufficient attention in this case.

In Iowa the result was mistrust, conspiracy theories, and a general lack of confidence in a voting system that is already struggling to improve UX. Imagine what the result of a voting failure like this would have been had it occurred on the global political stage, such as the UN or WHO, where trust is already beginning to dissolve. Indeed, international technology is only becoming more controversial, with the Huawei ban in the UK and the US’s love/hate relationship with TikTok only the latest examples.

Games and voting systems are just the tip of the iceberg. On a global scale, think of the apps and infrastructure we rely on from payments to logistics to communications.

Linux, but Make It Distributed

We’ve begun to confront the systemic racism, sexism, classism, ableism, and heteronormativity baked into our favorite applications, our approaches to tech hiring, and our industry best practices.

We also need to agree that user experience is inextricably linked to the backend, or as Tyler Treat puts it, “Distributed systems are a UX problem”. People who are geographically further away from where we make our apps are going to have a worse UX.

And then perhaps we need to go a step further. In the same way that programmers started coming together to build a better, open, operating system, perhaps we need to think about what it means to break up with your corporate cloud provider on an even bigger scale.


About This Post

Written by:

Share this post:

Recent Rotations butterfly

View all

To LLM or Not to LLM (Part 2): Starting Simple

Sick of hearing about hyped up AI solutions that sound like hot air? 🧐 Let’s use boring old ML to detect hype in AI marketing text and see why starting with a simple ML approach is still your best bet 90% of the time.

Building an AI Text Detector - Lessons Learned

The LLMs boom has made differentiating text written by a person vs. generated by AI a highly desired technology. In this post, I’ll attempt to build an AI text detector from scratch!

May 15, 2024

To LLM or Not to LLM: Tips for Responsible Innovation

We’re seeing a proliferation of Large Language Models (LLMs) as companies seek to replicate OpenAI’s success. In this post, two AI engineers respond to LLM FAQs and offer tips for responsible innovation.

Enter Your Email To Subscribe