Subjectivity by design
How product decisions shape behaviour, and who they end up making of the user.
We are used to thinking that a product serves a user who already exists: a person has needs, the product meets them. The longer I work, the more often I see the opposite. The product produces its own user, shapes habits and the very lens through which you look at yourself. That is what I call subjectivity by design. A subject engineered together with the interface, in the same commit as it.
The interface offers a role
Every interface quietly offers you a role, and you try it on before you notice. The feed offers you the part of a consumer of an endless stream. The productivity dashboard invites you to become the manager of your own life, where each day turns into a line in a report. These roles are not neutral, they train a particular relation to yourself. Work with a tool long enough and you start to think in its categories outside it too.
You can see this even in internal tools that nobody counts as a product. A couple of years ago I built an admin panel for a support team at the bank. We argued over something small: whether to show the operator a timer counting how long they had kept a case open. The product manager wanted the timer, it "disciplines" people. We added it. A month later operators were closing tickets faster, and some of them half-finished, just so the number would not go red. We had no intention of teaching people to cut corners, but the interface we assembled offered them exactly that role: a sprinter against a stopwatch. The role turned out to be stronger than any instructions.
A metric that changes the one it measures
To show a person a metric is to change their behaviour. A step counter changes how you walk. A follower count changes what you publish. The effect is well known: measurement interferes with the measured. Product teams know this and use it, sometimes on purpose, more often out of habit. The decision "let's show the user their statistics" is always also the decision "let's nudge them to behave so the statistics go up".
I ran one A/B test I still think about. We were checking whether a public counter of completed goals in an internal service would lift engagement. The variant with the counter won on every metric we looked at: people came back more often, they finished what they started. We shipped it, of course. Some users would later mention setting themselves smaller tasks so the counter would climb faster, and finding it left an odd feeling. The metric won on the dashboard and, along the way, quietly rewrote how a person set their own goals. By the numbers it was a clean win. I am still not entirely sure it was a win.
The flag left switched on
There is a story that has become almost a parable for me. In Unleash, the feature-flag platform I lived with for a long time as an engineer and tech lead, we turned on a flag for an experiment and forgot to turn it off. It stayed on for more than a year. Technically that is debt: a dead branch, a stray if that everyone's eyes slide past in code review. But the interesting part is elsewhere. Over that year the flag stopped being an experiment and became the environment. Users got used to the behaviour we had once meant only to measure. The team got used to it being there. When someone finally raised the idea of switching it off, there was nothing to switch off: a temporary hypothesis had turned, over a year, into "how things have always been here".
In code review a flag like that looks like nothing, a line to delete. In product terms it is a decision about which people find it more natural to become. A feature flag is honest precisely because it makes the arbitrariness visible: here is the switch, here is the date, here is who flipped it. And still we leave switches on for years with no ill intent, simply because nobody complains that way and the metrics do not dip. A subject is assembled out of forgotten flags like this no less than out of grand product strategies.
The entrepreneurial subject on screen
Most often products cast one and the same figure, the very one I write about in other texts. The user is encouraged to be proactive, to optimise themselves, to compete, to treat their life as a project with KPIs. Gamification, streaks, ratings, goals: this whole infrastructure moulds the person into a small entrepreneur of the self. There is no conspiracy in it. This figure is simply convenient for engagement, it generates on its own the actions we will later show on the growth chart.
People push back at me here: aren't you overstating it? The user is an adult and free, you can ignore a streak, switch off a counter. The objection is fair, and I do not think the interface programmes anyone directly. But the freedom here is asymmetric. Turning off a streak is an effort against a default the team polished for months and propped up with data. We impose no ban. We buff the path of least resistance, and most people walk down it. The freedom to step off that path remains, yet it costs a person extra friction, and removing friction in our own favour is exactly what we are good at.
The designer's responsibility
Hence a conclusion uncomfortable for the industry and for me: in designing a product you also design the subject who uses it. There is no reason to freeze up over that, but it does call for honesty. About a feature we usually ask whether it is convenient and whether it engages. It is worth asking something else too: who it makes of the person, and what it quietly trains them out of.
I do not think products should stop influencing behaviour. That is impossible, the influence is built into the very idea of an interface, any default turns someone into something. I think that influence should at least be kept in view. And yes, I am the engineer who added the timer, shipped the counter and left flags switched on, so I am not writing from a pulpit. Subjectivity by design happens either way. One question stays open: do we design the subject while looking them in the face, or do we get them as a side effect of chasing a chart that has to point up by Friday.