Based on a LinkedIn post originally published on 17 March 2026
Living in different countries teaches you that every society has a user interface.
I do not mean only websites, mobile applications or ticket machines. The interface includes every point at which a person interacts with the systems around them:
- public transport;
- government services;
- healthcare;
- banking;
- postal services;
- utilities;
- and the administrative processes of everyday life.
These systems reveal how a society understands the relationship between institutions and the people who depend on them.
One of my largest surprises after moving to Germany was how complex and unintuitive some public-facing systems could feel—particularly public transport.
A system may be internally logical and still be confusing to everyone who does not understand the organisation behind it.
The promise and the experience
When we first moved to Germany, we decided to rely heavily on trains for intercity travel.
On paper, the proposition appeared strong. A substantial rail network connected cities and regions, and travelling by train seemed preferable to driving for many journeys.
Our practical experience was more complicated.
Journeys could involve:
- several train changes;
- connections vulnerable to delays earlier in the journey;
- schedules that were not always maintained;
- long waiting periods;
- and small rural stations offering little protection from difficult weather.
In a country with cold winters, some stations consisted largely of exposed concrete platforms. They performed the basic function of allowing passengers to board and leave a train, but provided little comfort when a connection was delayed.
This distinction between functional and usable matters.
FUNCTIONAL SYSTEM - Train stops at the platform - Ticket can technically be purchased - Route exists - Timetable is published USABLE SYSTEM - Connections account for realistic delays - Waiting conditions are safe and tolerable - Ticket choices are understandable - The passenger knows what to do next
A system can satisfy every formal requirement in the first list while failing to provide the experience described in the second.
The ticket-machine problem
One particular journey stayed with me.
After a long train trip—which had taken longer than travelling by car—I needed to buy a bus ticket for the final part of the journey.
I stood in front of the available ticket machines and tried to determine which option I needed.
I could not make the process work.
Eventually, I had to stop strangers and ask for help. The explanation was that there were two different machines:
- one for local buses;
- and another for non-local buses.
That distinction presumably reflected the structure of the transport system: different authorities, operators, tariff zones or contractual arrangements.
But none of that was relevant to the immediate objective of the passenger.
I did not want to understand the transport-governance model. I wanted to enter my destination, see the price, pay and travel.
Internal structure leaked into the interface
The two-machine arrangement is an example of implementation detail becoming a user requirement.
Internally, the transport environment might resemble this:
Transport authority A
|
Local operator
|
Local tariff and ticket system
Transport authority B
|
Regional operator
|
Regional tariff and ticket systemThose distinctions may be necessary for governance, revenue allocation and service management.
The user’s mental model is much simpler:
I am here. I need to go there. What ticket do I need?
The interface should translate between those two models. Instead, the passenger was expected to understand the institutional structure before being allowed to complete a basic transaction.
Administrative categories are not user intentions
Organisations naturally divide work into categories.
They create regions, departments, service classes, ownership boundaries and contractual areas. These structures are needed to operate complex systems.
But a user normally approaches the system with an intention rather than an administrative category.
ADMINISTRATIVE VIEW USER INTENTION --------------------------- ---------------------------- Local or regional service Reach a destination Responsible authority Complete an application Tariff classification Pay the correct amount Internal service owner Resolve a problem Required legal procedure Obtain a valid outcome
Good service design accepts the user’s intention and resolves the internal classification on their behalf.
Poor service design asks the user to classify themselves correctly before the system will help them.
Familiarity hides friction
What struck me most was not only the complexity. It was how normal the arrangement appeared to everyone familiar with it.
People adapt.
They learn which machine to use, which zone applies and which exception matters. After repeating the process enough times, they stop seeing the knowledge as something the system requires from them.
The friction becomes invisible to experienced users while remaining fully present for visitors, new residents and anyone using the service infrequently.
A system can appear intuitive to the people who have memorised its exceptions. That does not make the system intuitive.
This creates a dangerous feedback problem. The people most frequently consulted about the system may be those who have already adapted to it. They can explain how it works, but may no longer notice why it is difficult.
Complexity must live somewhere
Complex services cannot eliminate all complexity. Transport networks genuinely include different operators, routes, tariffs, schedules and regulations.
The design question is where that complexity should be handled.
One option is to place it in front of the user:
User identifies operator
|
User understands zone
|
User selects ticket system
|
User calculates required product
|
User completes paymentThe other option is to make the service absorb more of it:
User enters destination
|
System identifies route and operators
|
System applies zones and tariff rules
|
System presents valid ticket and price
|
User paysThe complexity still exists, but it is managed by the component with the information required to resolve it.
The same principle applies to technology platforms
This is not only a public-transport problem.
Internal technology platforms frequently expose their organisational structure to developers in the same way.
A team that wants to deploy a service may be required to understand:
- which infrastructure team owns each component;
- which cloud account or subscription model applies;
- which security group approves a particular control;
- which pipeline variant matches the target environment;
- and which sequence of tickets activates the service.
The platform may technically offer every required capability, but the developer experience remains fragmented because the user must assemble the workflow from internal ownership boundaries.
A platform should expose a coherent capability, not a guided tour of the organisation chart that produced it.
Reliability is also part of user experience
A clear ticket interface does not solve every transport problem. The complete user journey also depends on whether connections are realistic and delays are handled effectively.
A journey planner may calculate a route correctly while allowing too little time for a transfer. When the first train is late, the technically valid itinerary becomes operationally useless.
This resembles a distributed system whose components are individually available but whose end-to-end service fails because the timing assumptions between them are unrealistic.
Train A available
Train B available
Published connection valid
|
v
Train A delayed
|
v
Transfer window disappears
|
v
End-to-end journey failsUsers experience the journey, not the availability statistics of each individual component.
The same is true in IT. A service composed of healthy components can still fail its user if the complete path is slow, confusing or dependent on unrealistic assumptions.
Design for the unfamiliar user
One of the strongest tests of a system is whether a capable person can use it without possessing hidden institutional knowledge.
This does not mean that every advanced function must be self-explanatory or that documentation is evidence of failure. Complex professional systems legitimately require learning.
But ordinary user intentions should not require unnecessary knowledge of implementation details.
A public-transport ticket machine should help a traveller purchase a valid journey. A government portal should help a resident complete a procedure. A developer platform should help a team deploy and operate software safely.
In each case, the service should translate intention into the internal structures necessary to fulfil it.
Ask where the confusion lives
When users repeatedly require help, it is tempting to respond with more instructions, training or documentation.
Sometimes that is appropriate. But repeated confusion should also trigger a design question:
Does the user lack necessary knowledge?
or
Has the system transferred its internal complexity
to the person least equipped to resolve it?If the second explanation is correct, a better manual will only document the problem more clearly.
The real improvement requires changing the interface, workflow or ownership model so that the system performs more of the translation itself.
Good systems do not eliminate complexity by pretending it does not exist. They place complexity behind an interface that lets people achieve their objective without first learning how the institution is organised.
Where relevant, factual and regulatory references were checked against the sources cited in the article. AI assistance does not replace professional legal, regulatory, financial or technical advice, and the final selection, interpretation, opinions and conclusions presented here remain my own.
Comments
Post a Comment