What Tokyo Can Teach Us About Building Better Software

By Dave Fuller, Managing and Technical Director, Accent Design

Key takeaways

• The best systems need no manual. Tokyo's rail network is navigable without reading Japanese because its structure is consistent and its information arrives at the point of decision.
• Rules work when people can see why they exist. Good software constraints guide users rather than punish them.
• Integration should be designed in from the start, not bolted on afterwards.
• Automation belongs where it removes friction; people belong where judgement and care matter.
• Quiet space and thinking time are infrastructure, in a city, in an interface and in a business.

We have all used a system that fights us. The form that rejects your phone number because of a space. The CRM that needs a training day before anyone dares touch it. The "integration" that turns out to be someone copying figures from one screen into another every Friday afternoon.

At Accent, we spend our working lives designing, building and fixing the systems businesses run on: websites, bespoke software, client portals and the integrations that hold them together.

Over the years I've worked with organisations that study Japanese culture, including building a website for the Sainsbury Institute for the Study of Japanese Art, but I'd never experienced Japan first hand. So when I spent two weeks in Tokyo on holiday this September, I didn't come home thinking about the sights. I came home thinking about systems.

Greater Tokyo is home to around 33 million people, making it the third largest city in the world according to the United Nations' World Urbanization Prospects 2025. Yet it is calm, clean, punctual and remarkably easy to use, even if, like me, you can't read a word of Japanese. That isn't luck. It is the result of thousands of small, deliberate decisions about how people actually behave.

It would be easy to put all of that down to culture and decide it could never work here. Culture certainly plays its part, and you can't import a culture wholesale. But most of what makes Tokyo work isn't mysterious. It is design: clear rules, consistent structure and a constant focus on the person using the system. Those principles travel. They work just as well in a CRM in Norwich as on a railway platform in Shibuya.

If you build, buy or run software, there is a lot to learn from it. I'd break it down into three parts, the city (the software), its people (the users) and its services (the functionality), followed by two lessons that tie them together: putting technology in its place, and making room for quiet.

The city: a system nobody had to explain

Our first trip across the city was from Shinagawa, where we were staying, to Shibuya. I'd expected to spend half an hour staring at a map; instead we were on the right platform within five minutes, just by following the line colours and station numbers.

That wasn't because I'd studied one of the most complex rail networks in the world. It was because the network was designed so I didn't need to.

Every line has a colour and a letter code. Every station has a number. Shinjuku on the Yamanote Line, for example, is simply JY17. You don't need to read or pronounce the station name; you need to know which number you're heading for. This wasn't an accident either. JR East rolled the scheme out across its Tokyo stations in 2016, explicitly to help international visitors ahead of the Olympic Games, adding station names in Chinese and Korean alongside Japanese and English (SoraNews24). The subway operators had already been doing the same.

In other words, someone looked at the users who were struggling and redesigned the system around them. And the information appears exactly where you need it, at the moment you need it. Not before, not after.

That is good software architecture in a nutshell. Consistent patterns, predictable labels and information delivered at the point of decision. When a system is well structured, the user never has to see the structure. They just get where they are going.

The question for us: could a new member of your team use your system on day one without a training session? If not, the problem probably isn't the person.

The people: rules that make sense the moment you meet them

Tokyo has plenty of rules, but very few of them feel like rules. Markings on the platform show you where the doors will open and where to queue. Most people stand on the left of the escalator. You don't take phone calls on the train. There are surprisingly few public bins, yet the streets are spotless, because people simply take their rubbish home with them.

It took me about a day to notice I hadn't seen a single bin, and another day to realise I'd started carrying my own rubbish back to the hotel without thinking about it.

None of this is enforced by warning signs on every wall. It works because each rule is obvious once you meet it, and because it clearly benefits everyone, including you. After a few days you find yourself wondering why you ever did it any other way.

Good software constraints work the same way. Sensible defaults, clear validation, a layout that guides you towards the right action rather than punishing the wrong one. If your users need a pop up explaining a rule, or keep breaking it, the rule is probably badly designed. People will follow a system happily when it is clearly on their side.

The question for us: are the rules in your system obvious and helpful, or are they enforced by error messages and frustration?

The services: parts that work with each other, not against

One small IC card, tapped on a reader, gets you through the ticket gates of competing rail companies, onto buses, and pays for a drink from a vending machine or lunch from a convenience store. Different operators, different businesses, one seamless experience. As a visitor you never see the joins.

Compare that with how many businesses run day to day. A website that doesn't talk to the CRM. A CRM that doesn't talk to the accounts package. Spreadsheets bridging the gaps, and people quietly acting as the glue. Each system might be fine on its own, but together they work against each other.

A recent project of ours shows what that costs. A client firm held its consultations on a video call platform, kept documents in a separate file store and ran its client records in a CRM, and nothing connected them. Of more than 4,000 recordings, only 61 had been booked through the CRM. The rest were linked to a client only by a name typed into the meeting title, and with more than 3,700 names shared by more than one client record, matching by name was little better than a coin toss. Finding what had been said to a client, for a complaint, a compliance review or a handover, meant hunting for the recordings and sitting through them.

So we joined the parts together. Recordings are now copied every hour into the firm's own storage, transcribed overnight on its own server and filed against the right client, with the video beside a searchable transcript. What used to take hours of watching is now one click and a text search, and every client meeting has a transcript, something that never realistically happened when typing up a one-hour meeting took several hours by hand. As the project brief put it, "for a two-hour consultation, finding what was said is the actual task."

Integration isn't a feature you bolt on at the end. It is a decision you make at the start, about how information should flow between the parts of a business so that people can get on with the work that matters.

The question for us: how much of your team's week is spent moving information from one system to another?

Technology in its place

Tokyo is often described as futuristic, but what struck me most was how unforced the technology felt. Ticket gates open in a fraction of a second. Many restaurants have you order and pay at a machine by the door, so the kitchen gets on with cooking. Vending machines are everywhere.

Yet there are people wherever people make a difference. Station staff are visible and helpful. And on the railways, staff still use a deliberately low-tech practice called shisa kanko, or "pointing and calling": physically pointing at a signal or gauge and saying its status out loud. It looks theatrical, but a 1994 study by Japan's Railway Technical Research Institute found it cut mistakes on a simple task by almost 85 percent (The Japan Times).

That is a human verification step, deliberately kept in a highly automated system because it works. In software we'd call it a confirmation step, a code review or a checklist, and it is just as easy to strip out in the name of speed.

We applied the same thinking on the recordings project above. When we checked 811 recordings that had been filed under shared names, 271 turned out to be on the wrong client. So shared names are no longer matched automatically; the system puts them on a list for a person to assign. Automation handles the volume, and a human makes the judgement call.

That balance matters more than ever. At Accent we use AI every day: Claude Code helps us build and update client websites, and a developer reviews every change. It is the same principle as pointing and calling. Automation does the work; a person checks it. The lesson from Tokyo is not "automate everything". It is "automate the right things". The best technology disappears into the experience. The worst is bolted on because it was possible, not because it was useful.

The question for us: is your automation removing friction, or just moving it somewhere else?

The quiet spaces matter as much as the busy ones

Within 30 minutes of arriving at our hotel in Shinagawa, we were standing at Sengaku-ji, the temple where the 47 Ronin are buried. The noise of the city simply died away. Birds were flying down and landing on the graves in front of us, almost guiding us around. It was the closest experience I've had to a spiritual moment, and it was a short walk from one of Tokyo's busiest stations.

That contrast is everywhere. Tokyo doesn't treat calm as wasted space. It treats it as essential infrastructure.

Software needs this too. Not every screen should be a dashboard of alerts and flashing numbers. White space, focus and calm interfaces let people think.

And businesses need it most of all. In Japanese business culture there is a well known practice of laying careful groundwork and building consensus before a decision is made. Decisions can take longer, but once made they tend to stick, and they are carried out with confidence. Work is important, but thinking time, consideration and choosing the right option are just as important, often more so.

In software terms, that is the discovery phase: understanding how people actually work before writing a line of code. It is the part most often squeezed when budgets are tight, and the part that most often decides whether a project succeeds.

The question for us: do you give yourself time to choose the right option, or only time to build the first one?

Software at its best shouldn't feel like software

Tokyo works because it was designed, and continually refined, around real people: how they move, what they need, where they get stuck and when they need a moment of peace. It doesn't ask its residents and visitors to adapt to the system. The system adapts to them.

That is the standard we should hold our software to. Not the most features, not the newest technology, but the system that is obvious to use, where the parts work together, where the rules make sense and where technology sits naturally alongside the people using it.

Five questions to ask about your own systems

1. Could a new member of your team use it on day one without a training session?
2. Are its rules obvious and helpful, or enforced by error messages and frustration?
3. How much of your team's week is spent moving information from one system to another?
4. Is your automation removing friction, or just moving it somewhere else?
5. Do you give yourself time to choose the right option, or only time to build the first one?

If you winced at one or two of those, you're not alone. And if your systems feel more like a rush hour you have to fight through than a city that carries you where you need to go, we'd love to talk.

About the author

Dave Fuller is Managing and Technical Director of Accent Design, a Norfolk based agency providing web design, bespoke software development and security services. In 27 years of website and web application development, Dave has built the internal database systems that run Spectra Packaging and Broadway Colours day to day, parts and customs web applications for KLM UK Engineering, scheduling and reporting systems for Norwich Anaesthetists Group, an emergency theatre booking system for EmergencyList, and a bespoke CRM for the UK landlord community Property118. Alongside that, he has delivered websites for organisations ranging from Norwich City Council, the Cambridgeshire Police and Crime Commissioner and the Sainsbury Institute for the Study of Japanese Art to international wildlife tour operators such as Birdquest, Limosa and Greentours. Since 2012 alone he has worked with more than 250 clients, many of whom, including Property118, Agency Express and Spectra Packaging, have been with Accent for over a decade. He is particularly interested in how well designed systems can give people back time to do their best work.

A Note on How This Article Was Produced

The editorial position taken here is Dave Fuller's own, drawn from nearly three decades of hands-on work. AI tools were used to help summarise research and to shape the author's views into a working draft. Every claim was verified, and the final text was reviewed and edited by a person, who takes responsibility for it.

Sources

• United Nations Department of Economic and Social Affairs, World Urbanization Prospects 2025 press release, November 2025
• SoraNews24, JR East to introduce numbering system at all stations in Tokyo, April 2016
• The Japan Times, Pointing and calling on JR (shisa kanko), October 2008