← back to posts

Cities as Interfaces

Jan 5, 2026 ยท 5 min read

I just got back from my first solo trip to Europe. Three weeks, six cities, no plan. First time on that continent, first time travelling alone, first time being somewhere where I couldn't fall back on anyone else's schedule or preferences. Just me and the next decision.

It turns out navigating a foreign city alone teaches you the same things as designing a system from scratch.

No documentation

When you arrive in a city you've never been to, you don't have context. You don't know which neighborhoods are walkable, which metro lines actually connect, which restaurants are real and which ones exist only for tourists. You're dropped into a live system with no onboarding and no README.

This is exactly what it feels like to inherit a codebase. Or to join a company and try to understand how things actually work versus how the org chart says they work. The map is not the territory. The documentation is not the system.

In both cases, the only reliable strategy is the same: walk around. Explore. Get lost on purpose. Touch things. Make small mistakes in low-stakes environments until the mental model starts to form.

Wayfinding is design

Some cities are beautifully designed. You step out of the train station and you just know where to go. The streets make sense. The signage is clear. The rhythm of the place pulls you in the right direction without you noticing. Other cities fight you at every turn. The exits are wrong, the maps are outdated, the logic is invisible.

I kept thinking about this in terms of the interfaces I build. Every dashboard, every internal tool, every web platform, it's a city someone has to navigate. And the question is always the same: does the user know where they are, where they can go, and how to get back?

Good wayfinding in a city and good UX in software share the same principle: reduce the cost of being wrong. Make it easy to try, easy to recover, easy to find your way back. The worst cities, like the worst interfaces, punish exploration. The best ones reward it.

Alone with decisions

The solo part mattered more than I expected. When you travel with someone else, decisions are shared. Where to eat, when to move, how long to stay. You negotiate, compromise, defer. Alone, every decision is yours. Every outcome is your responsibility.

That sounds heavy but it's actually freeing. You learn how you actually make decisions when nobody is watching. What you gravitate toward when there's no social pressure. What you skip. What you linger on.

I noticed I like slow mornings and late nights. I like eating at the bar instead of a table. I like walking more than taking transit. I like getting slightly lost because the recovery is where the interesting things happen.

These are small things. But knowing them about yourself, knowing your actual defaults rather than your assumed ones, that's useful in every context. Including building software. Knowing your instincts lets you trust them when the stakes are higher.

The return

I came back to Abu Dhabi in January with a head full of ideas and a phone full of notes. Not about the sights. About the systems. How Amsterdam handles cycling infrastructure. How Barcelona layers old and new architecture without either one losing its identity. How a tiny restaurant in Lisbon runs a perfect operation with three people and zero technology.

Every city is a system. Every system is a set of design decisions made by people who had constraints, priorities, and blind spots. Travelling alone forces you to read those decisions instead of just moving through them.

I build technology for a living. But the best lessons about how people interact with systems, I learned by being a stranger in a city with no plan and no backup. Sometimes the most useful thing you can do for your work is leave it behind for a while.