Today I got a parking ticket because of a very ordinary chain of events.
I was taking my daughter to nursery during her adaptation period and parked where we usually park on weekends. On weekends, parking there is free, so I had never really asked myself how you pay for it on a weekday.
It turns out the answer is: through an app.
To pay, the flow looks something like this:
Download the app → Verify email → Verify phone number → Add payment details → Add licence plate → Choose parking type → Find the exact parking zone → Pay
You can probably tell from the length of that flow that when you are taking your little daughter to nursery during her first days of adaptation, your mind is not exactly focused on configuring a parking app.
So I skipped the flow.
I parked, took my daughter inside, and left. Later, I got an €8 fine. And, strangely enough, part of me was almost grateful for how frictionless the parking experience had been in that moment.
I did not need to understand the system.
I did not need to register.
I did not need to configure anything.
I just parked and went where I needed to go.
The friction did not disappear.
It simply appeared later - as a fine and another half an hour spent figuring out how to pay it.
As someone who designs digital products, I kept thinking about this. We often treat automation as if it automatically removes friction.
But sometimes automation does something else:
it moves the work from the system to the user.
A person at the parking lot could have taken my payment. A barrier could have asked me for one simple transaction at exactly the right moment.
Instead, the automated system required me to understand how it works, provide context, configure myself as a user, make several decisions, and complete the right flow before I could perform a very simple task: park a car.
This raises a few questions that feel increasingly relevant far beyond parking.
When is onboarding actually necessary?
What is the bare minimum of data we need from a new user?
How much context should a user have to provide before the system can help them?
And when we automate a process, are we actually removing work - or just redistributing it?
This becomes especially important in AI products. We talk a lot about human in the loop in the context of control, oversight, approvals, and safety.
All of that matters.
But there is another role the human can play. Sometimes the human is there to absorb complexity.
They know how the system works.
They know what information matters.
They know which exception applies.
They know what to ask next.
And instead of making the user understand the entire system, they translate that complexity into a simple interaction. Remove that human, and the complexity does not necessarily disappear. Someone still has to deal with it.
Very often, that someone becomes the user. And this is where the question of delegation becomes more interesting.
If an AI product is supposed to take more work off the user’s plate, then simply removing people from a workflow is not enough.
The product has to absorb the work they were doing too.
Otherwise, we may call the experience automated while quietly increasing the user’s cognitive and operational load.
So perhaps one useful question for AI product teams is not only:
What can we automate?
But:
When we remove the human from the loop, who inherits the work that human used to do?
If the answer is “the user,” we may not have removed friction at all.
We may have just moved it.