Smart Cities Only Become Smart When People Actually Use Them

The smartest idea in the room can still fail after launch

One of the most useful stories in the smart-cities session was not a success story. A developer described a barcode-based system for maintenance requests and local deliveries. On paper, the idea sounded efficient. In practice, residents barely used it and the system was difficult to maintain.

That example captures a common problem in transformation programmes: we are very good at assessing whether a technology can work, and much less disciplined about assessing whether people will actually use it in the context of everyday life.

Adoption is part of the service

The developer's response was revealing. Their current handover approach includes instructional videos in multiple languages, a helpline and an on-site concierge. Those are not peripheral communication activities. They are part of the service design.

A resident experiences a smart-city service through the full journey: hearing about it, understanding it, activating it, getting help when it fails and deciding whether it is worth using again. If those moments are not designed, the technology is effectively unfinished.

Whole-life cost should shape the design from day one

The session also highlighted the tension between ambitious initial designs and the budgets that eventually force trade-offs. The important point was that decisions should not be made only against capital cost. Developers also need to consider the service charges and ongoing costs residents will carry after handover.

That creates a more mature definition of 'smart'. A feature that is impressive at launch but expensive to maintain, difficult to support or rarely used may make the development less intelligent over its lifetime, not more.

The city is an integrated service environment

Another part of the discussion described a community where home, work, school and shops are within a short walk, reducing unnecessary mobility. Achieving that experience requires more than an app or a technology platform. It requires government policy, developer delivery and investor capital to be orchestrated around the way people actually live.

This is why smart-city work is ultimately a systems problem. Infrastructure, digital services, mobility, customer support and the operating model need to reinforce one another. If any one of those layers is designed in isolation, the resident feels the gap.

Start small enough to learn

The session closed with a pragmatic view: avoid starting with overly complex solutions and learn at smaller scale. That does not mean thinking small. It means reducing the cost of learning before a model is replicated across a city or portfolio.

A small deployment can reveal whether the problem is real, whether people adopt the service, what support is required and what it costs to operate. Those are the questions that determine whether a smart-city solution is scalable in practice.

What I took away

The real smart-city execution gap sits between strategy and everyday use. Closing it requires service design, onboarding, operational support and lifecycle economics to be treated as design criteria from the beginning rather than post-launch fixes.

For major developments and destination programmes, the goal should be simple to state even if it is difficult to deliver: make the physical environment, digital layer and service operation work as one experience from day one.

Five ideas worth carrying forward

• Test whether people will use the service, not only whether the technology works.
• Design onboarding and support as part of the core proposition.
• Evaluate whole-life operating cost before committing to features.
• Coordinate physical, digital and service layers around the resident journey.
• Pilot at a scale that allows real learning before wider rollout.