How tech culture impacts how we understand ourselves through apps
In the last 20 years, the tech world has transformed parts of humanity into one-dimensional digital zombies. Sadly, you can hold me personally responsible. Let me tell you why. It started in 1995, when I was 12 years old, and our household got access to the web. An internet connection was needed because my parents had an advertising agency located in an office next to our house. The World Wide Web allowed my folks to send documents to print shops without having to drive there in person.
My parents’ agency did things like branding, marketing campaigns, and product packaging designs. In the mid ’90s, my parents’ clients understood that the internet was ‘the next big thing.’ They said that ‘they had to do something with the internet.’ In other words, they wanted a website. There was no real strategy behind the need to have a website. Online presence was a goal in itself. And I could help them fulfil this goal.
As a nerdy teenager, I taught myself to write HTML and design interfaces. With my newly acquired skills, I was able to build websites for my parents’ customers. In reality, these companies would give me one of their paper brochures and tell me to ‘make this a website.’ The very first corporate websites were just elaborate business cards: a description, a photo, a list of their services, and contact details.
The interactive web
My teenage years in the ’90s, and my role as (what was then called) a webmaster, gave me much satisfaction. Over the following years, the web changed. Websites became more interactive. Webshops and social media emerged. Users could now also actively participate. They could add content and communicate with one another.
Perhaps the first interactive system I designed was a portal that enabled companies to offer health services to their staff. Through this platform, workers could get free gym memberships. Of course, on the platform, staff members could monitor their health progress. More significantly, their bosses could also scrutinise the overall fitness of their workforce. The platform enabled the company to measure the relationship between HR investments and sick leave. Where does the sweet spot lie between paying for health services and reduced costs related to staff absences? At the time, I thought I was designing a health platform, but what I was really designing was workforce optimisation.
Web Design to User Experience
Over time, my job title changed from Web Designer to User Experience Designer. I got an updated, fancier title that looks cool on a business card or LinkedIn. My role suggested I wasn’t just designing websites anymore. Somehow, I was designing experiences. I was crafting how people interact with a digital product and how they interpret the interfaces and information they are exposed to.
In other words, I was designing comprehension and behaviour. Or… was I producing something even more fundamental? Was I perhaps designing how people see themselves? Or even more elemental, was I nudging people into becoming someone different?
As the technical possibilities of the web advanced, my work became more and more concerned with what happened after a website was launched. The website itself wasn’t about the finished product. The industry began tracking what people did with it. Tools such as Google Analytics allowed companies to see how far people scrolled, how long they stayed on a page, and which actions they completed. Suddenly, the behaviour of website users could be analysed in detail.
My job shifted from making websites look and feel nice, or, as I would say at the time, cool, to optimising how people interacted with them. The importance of aesthetics was being overtaken by concepts like conversion optimisation.
The role of the metric
At the level of the tech worker, my own productivity started to be monitored. This was done through corporate frameworks like Agile and software, especially Atlassian products. I delivered story points and maintained velocity instead of just (giving my boss the illusion I was) working hard. All of a sudden, I was dealing with standups, tickets, and dashboards.
Because a website wasn’t seen as a finished product anymore, features could be added or optimised at any time, based on new insights from metrics. Time-boxed projects became ongoing trajectories without a specific end. Clients wouldn’t pay for a finished website, but would purchase an ‘envelope of time’ designers and engineers could spend on ongoing improvements. Project management turned into product management. This way, teams could quickly respond to changing requirements. Teams became agile.
Measuring the website became part of a larger move in which success was defined by performance metrics. In addition to being measured myself through story points and velocity, this calculative logic moved into the product. The metrics that guided companies became metrics inside apps. The metrics that governed workers transitioned into metrics that influenced users.
A website became something that could be continuously measured, tested and improved. This seemed totally sensible. Why wouldn’t we want to know whether our designs worked and how we could improve? These are valid questions. However, there is a downside to measuring. It defines what counts as knowledge. What can be measured becomes a particular form of authority. The things captured in Google Analytics become more important than aspects of the user that can’t be metrified.
Companies use (Agile) frameworks to measure workers. Workers build products that measure users. Users then measure themselves (and each other).
The blind spot of the metric
When I entered the tech industry, the web was still relatively young. Websites became platforms, projects turned into products, and analytics were embedded in decision-making. Measurement moved from being something that was ‘interesting’ and was used occasionally to a form of knowledge that structured every aspect of my work. Metrics became what we would see as ‘true’.
A metric tells something about reality. More significantly, it selects what part of reality becomes visible. Not only for the company and tech teams, but also for the users. Other things may still exist. Yet, they become harder to see. The number of story points you deliver shows something about your contribution, but it doesn’t take into account the support you gave your colleague or the time you spent on the phone with a client. For the user, a 10,000-step achievement might indicate a healthy person, but the metric doesn’t show what the person drank or ate that day.
Agile, product, and user metrics allow for classifying employees and products. User-targeted metrics do that too. They make it possible to categorise, rank, and compare users. An Uber rating helps the platform assess passengers and drivers. One user with a rating of 4.86 doesn’t mean much, but when millions of users are rated, it gives a lot of information. Metrics turn complex human beings into comparable profiles and enable platforms to make decisions.
Body or code
Let’s look at the user a bit more in detail to illustrate how metrics affect them. What happens when metrics become the primary way through which users understand themselves? In that case, the metric begins to compete with our real lived experience. I discovered this personally when I started using Fitbit. I had been having problems with my sleep, and I thought a health app could help me understand what on earth was going on. At first, I wanted to see on which days my sleep was worse. What was the cause of these bad nights? Maybe Fitbit could help me.
The old me would wake up and simply decide how I felt. If I had slept badly, I might take it easy in the morning. If I felt rested, I would probably do an early morning workout. My experience of my own body was the primary source of information. There was no score telling me whether I had slept well or badly.
The Fitbit-me looked at my app the moment I woke up. My night was translated into data. Sleep duration, time to fall asleep, deep sleep, REM sleep, and all that jazz are displayed on a screen. I might be told that I slept for 6 hours 39 minutes and that my sleep score was 68. Fitbit could tell me that I had less deep sleep than usual, or that my sleep was below my personal average.
When Fitbit would tell me I had a few nights of poor sleep, I would start to get nervous. I knew ‘for a fact’ I needed a good night’s sleep because I had a few bad ones. I considered Fitbit a more reliable source of information than my own perception. The metric became my reality. Obviously, going to bed feeling stressed will not lead to better sleep. I would go to bed early but lie awake for a long time.
Finding truth in a health wearable is different from being rated as an Uber driver or having work tracked in Jira. Although all three forms of knowledge rely on metrics, the metrics influence how we understand ourselves differently.
When I look at my Fitbit score, I might doubt my own bodily experience. I can wake up feeling rested, but if the app tells me that I had a bad night. I might consider the score more reliable than my own feeling. The metric changes how I interpret myself.
For a taxi driver, the Uber rating reflects how other people evaluate them. A driver may therefore adjust their behaviour to avoid a poor rating. The metric creates an incentive to behave in a certain way.
In Jira, story points and velocity make work visible within an organisation. Yet, they cannot capture everything that makes someone a valuable colleague. Helping a struggling teammate may contribute to a team’s success but is not included in story points. This way, workers may prioritise what counts as measurable output over what matters in the work itself.
The way the metric functions is thus different, depending on the context. What connects these examples is that each makes a particular aspect of life visible. Only a selected part of reality becomes meaningful. Based on this meaning, people change their behaviour. They change how they sleep, drive, or work. They understand their sleep or work through the metric.
The homo metricus
So what happens when we allow a metric to determine how we understand ourselves? Let’s go back to our work as UX designers. I have spent most of my professional life designing things that mediate how people understand and act in the world. For a long time, I thought the important question was whether my interfaces were easy to use. Whether they provided a good User Experience.
Then I started wondering whether they were doing something more fundamental. Maybe technology doesn’t just change how we do things and what we do. Maybe it also changes how we understand what/who we are.
The metrics inside our workplaces, our apps, and our wearables may seem to be nothing more than useful representations of reality. But, once metrics become part of the environments in which we act, they can also become part of how we understand ourselves.
This sounds abstract, but it isn’t. Users care about how many people liked their story, what their credit score or Airbnb rating is, or how long their Duolingo streak is. Users accept metrics imposed by the tech platform as part of their daily routine. What do you do when your follower count stagnates, you deliver fewer story points than usual, or see your Uber passenger score fall?
Eventually, we may find ourselves living according to metrics that we helped create by contributing data. I call the person produced by this environment the homo metricus.
The homo metricus is someone who understands and governs itself through algorithmically defined metrics.
Obviously, I didn’t set out to become a homo metricus. No one does. But that doesn’t mean that we aren’t a homo metricus in some way or form. We take some of the metrics that tech platforms (including Atlassian) introduce awfully seriously. (Read more about the homo metricus in this post).
The role of the designer
When I entered the tech industry, the web was a collection of pages. In fact, there was even a directory that aimed to list all the websites in the world. Over time, websites became platforms, projects became products, and analytics became embedded in decision-making. Measurement moved from something we used occasionally to a way to structure our work. The metric then travelled from the tech company to the user. Users began measuring themselves and each other.
This doesn’t mean that metrics are bad, per se. Metrics can make things visible that would otherwise be hard to see. They can help us understand our behaviour and improve what we do. However, we might occasionally forget that a metric is only a representation of a part of reality. Things not captured by the metric still exist.
Be honest with yourself… How intensely do you look at numbers? As a tech worker, how much do you care about your story points, velocity, 360-feedback score, etc. As a designer, how much do you look at churn rate, conversion numbers, and A/B tests? As a user, how much do you look at metrics provided by Uber, Instagram, Fitbit, Duolingo or any other app you use frequently?
As UX designers, one thing is to acknowledge how we are governed by (Agile) numbers. We should also be very mindful of the limited reality that metrics create. Everything that is not captured by the metric still exists. Ultimately, we, as UX designers, need to understand how the metrics we add to products change how people behave. We are not designing experiences. We are designing how people understand the world and themselves. We are designing the homo metricus.
So how can we design a UX that reduces how much the user relies on metrics without eliminating their benefits? We can’t remove the metric. It’s often a big part of the UX and helps the company to achieve its business objectives.
However, we can give the metric less authority. The Fitbit app, for instance, could show the sleep score together with the user’s own self-reported idea of how rested they feel. Jira could acknowledge the value of helping colleagues instead of treating completed story points as the only indication of contribution.
In real life, people can take off their wearable because they get tired of always seeing their steps. These options can also be added to the UX itself.
As designers, we can search for ways that give the metric more open to interpretation. This less metric-centric UX will leave room for parts of life that can’t be quantified. It may still give the metric authority, but not the only one.
This article is ultimately about how business metrics become metrics that are embedded in apps. We, as designers, should analyse where the metrics we introduce come from and what they are intended to achieve. How do they contribute to the performance metrics of our business? Is the metric the only way this objective can be achieved? Or are there alternatives?
As UX designers, we might be able to decide which metrics are dominant, and which alternatives could be available. Through our UXs and metrics, we are helping shape how people understand themselves. Let’s not make them fully developed homo metrici. What solutions or adjustments would you propose?
This article covers a very limited message of my upcoming book with the working title “Homo Metricus — How smartphone apps change what it means to be human.” In the upcoming period, I will post more insights to explore the relationship between humanity, tech platforms, and metrics.
Sources
My ideas are partially a contemporary bastardisation/reinterpretation of Michel Foucault’s later work. Other philosophical theories that cover related social problems can be found in the writings of Alain Supiot, Gilles Deleuze, and Herbert Marcuse.
UX designers are not designing interfaces, they design personalities was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
