Designing voice AI and EV charging with no precedent to copy.

Context

DEWA was already more than an electricity and water utility.

Its Smart Platforms unit was building the digital layer around everyday life in Dubai: energy management, electric mobility, connected devices, voice interfaces, and smart-city services.

The ambition was unusually forward-looking for a government organization.

The difficult part was that the products did not fit into established categories.

A voice assistant for a utility could not simply copy a retail Alexa skill.

A public EV-charging service could not be designed as a mobile screen alone.

A Smart Living platform could not wait for every interaction pattern to become conventional before adopting it.

The work sat between systems:

• Government service and consumer product
• Voice and visual interface
• Software and physical infrastructure
• English and Arabic
• Innovation concept and operational reality
• Platform convention and emerging behavior

There was no complete playbook.

That meant the product team had to define the experience while defining the category.

The Real Problem

Each project appeared to have a different interface problem.

The Alexa skill needed conversational flows.

Green Charger needed a booking and charging experience.

Smart Living needed new mobile patterns.

But the deeper problem was the same across all three:

The visible interface represented only a fraction of the product.

A voice response depended on account data, authentication, device capability, language, and the user’s ability to understand information without seeing it.

An EV-charging screen depended on whether the charger was available, connected, physically accessible, and functioning when the driver arrived.

A government mobile feature depended on operational systems, public trust, accessibility, platform conventions, and millions of users with different levels of technical confidence.

Designing the screen without designing the surrounding system would produce a polished failure.

The product challenge was to make every layer behave like one coherent service.

My Role

I joined DEWA’s Smart Platforms innovation unit as User Experience Lead.

My remit covered three concurrent initiatives:

• DEWA’s Arabic and English Amazon Alexa experience
• Dubai’s Green Charger public EV-charging network
• The evolution of the DEWA Smart Living platform

The combined budgets exceeded $2 million.

My role crossed:

• Product discovery
• Service and interaction architecture
• User research
• Voice and conversational design
• Arabic and English experience design
• Right-to-left graphical interfaces
• Mobile product design
• Hardware–software journeys
• Operational dashboards
• Field validation
• Emerging-platform strategy

I worked with engineering, product, project management, operations, QA, Amazon’s technical teams, and DEWA’s innovation leadership.

I was not the owner of DEWA’s wider digital portfolio or the physical charging network itself.

My responsibility was to make the new services coherent from the user’s first intent through the operational systems required to fulfill it.

Decision 01 — Do not force a visual service into voice alone

The initial Alexa proposition appeared straightforward.

Users could ask for:

• Their electricity balance
• Water consumption
• Billing information
• Account status
• EV-charging information

The first instinct was to treat it as a voice-only experience.

That would have reduced implementation complexity and matched the dominant Echo Dot use case at the time.

It would also have produced an incomplete product.

Utility information is often numerical, comparative, and tabular.

Users might be comfortable hearing a balance.

They were less likely to retain:

• Monthly consumption comparisons
• Detailed billing breakdowns
• Multiple account values
• Charging information
• Trends over time

Voice was strong for intent and retrieval.

It was weak for dense information.

I pushed for a multimodal product:

Voice-first on audio-only devices
Voice + visual on supported screens
English + Arabic across both modes
Right-to-left graphical interaction

This required designing two connected interaction systems.

The voice layer needed to work independently.

The visual layer needed to clarify and extend the spoken response without becoming a separate application.

A user could ask naturally, hear the answer, and then inspect the detail.

The decision introduced more technical and design complexity.

It required working with Alexa Presentation Language, learning emerging RTL capabilities, and solving Arabic graphical-interface problems with limited regional precedent.

But it also matched the service to the information.

The principle was:

Use voice to reach the answer. Use the screen when understanding requires structure.

The product launched as the GCC’s first Arabic Amazon Alexa skill and a regional first for bilingual APL and right-to-left implementation.

[ + ]

Decision 02 — Treat Arabic as interaction architecture, not translation

Supporting Arabic was not a matter of translating English prompts.

Voice and graphical interaction both changed.

In voice, Arabic introduced:

• Dialect variation
• Different ways of stating account and billing requests
• Code-switching between Arabic and English
• Numeral and currency phrasing
• Confirmation and repair patterns
• Different expectations of formality

On visual devices, right-to-left design affected:

• Reading order
• Component alignment
• Navigation direction
• Data hierarchy
• Number presentation
• Mixed-language content
• The relationship between spoken and displayed information

A translated English flow would have remained structurally English.

The Arabic experience needed its own conversational and graphical logic while preserving functional parity.

I designed the dialogue branches, confirmation patterns, fallback behavior, repair flows, and visual responses across both languages.

The challenge was not simply making Arabic work.

It was preventing the bilingual system from becoming two products with unequal capability.

That required a shared intent architecture with language-specific interaction behavior.

The product lesson was:

Localization changes the words. Product parity requires redesigning the interaction.

[ + ]

Decision 03 — Design EV charging around certainty before arrival

Green Charger initially appeared to be a transactional product.

The expected journey was:

Find charger
Arrive
Authenticate
Plug in
Charge
Pay

That model assumed the difficult moment happened at the charger.

Our work showed that the anxiety began earlier.

Drivers wanted to know:

• Is the charger available?
• Is it working?
• Will it still be available when I arrive?
• Can I access the site?
• Which connector do I need?
• How long will charging take?
• How will I be billed?
• What happens if the session fails?

The product was not only selling access to electricity.

It was selling certainty.

That changed the journey.

We designed the service from before arrival through after departure:

Before arrival

• Charger discovery
• Availability
• Location and access information
• Pre-booking
• Compatibility

On arrival

• Geofence-based recognition
• Unlock and authentication
• Charger identification
• Connection guidance
• Failure recovery

During charging

• Session status
• Time and energy information
• Notifications
• Support

After charging

• Completion
• Session history
• Monthly billing
• Account integration

The most consequential decision was pre-booking.

Without it, the user could drive across Dubai and arrive at an occupied or unavailable charger.

No amount of interface polish at the station could repair that failure.

Booking required additional service logic and operational coordination.

It also addressed the highest-cost uncertainty in the journey.

The charger was not the beginning of the product. The decision to drive there was.

[ + ]

Decision 04 — Test the service where the infrastructure could fail

A mobile prototype could validate whether users understood the flow.

It could not validate whether the product worked.

The real experience depended on:

• Charger connectivity
• Physical location
• Hardware state
• Geofencing accuracy
• Network reliability
• Site access
• Backend synchronization
• Billing records
• Operational monitoring

I joined QA and technical teams in the field to test the service at physical charging locations.

This changed the nature of product evaluation.

A failure could originate in the interface, the device, the network, the backend, or the operational process.

To the user, those distinctions did not matter.

The product had failed.

The internal operations dashboard therefore became part of the experience architecture.

Operations teams needed to see:

• Charger availability
• Connectivity
• Active sessions
• Faults
• Location status
• Performance patterns

The customer-facing product and the internal operational product were two sides of the same service.

A driver could only trust the availability shown in the app if operations could detect and resolve failures behind it.

The principle was:

Reliability is a product feature, even when the user never sees the system producing it.

Leading the Platform Pattern Cycle

The Smart Living platform created a different kind of decision.

Government apps often adopt new interaction patterns after consumer products have made them familiar.

The delay reduces risk.

It can also make essential public products feel structurally outdated.

DEWA had enough reach and product maturity to operate differently.

We explored and introduced emerging mobile patterns, widgets, and connected-device concepts earlier than was typical for regional government services.

The goal was not novelty.

It was platform parity.

Users did not lower their expectations because the service came from a utility.

They compared the experience with the strongest consumer products on their phones.

That meant evaluating new patterns before they became mandatory:

• Would users understand them?
• Did they improve access to high-frequency information?
• Could they reduce effort?
• Would they remain stable as platform conventions matured?
• Did their value justify early implementation risk?

Some patterns shipped.

Others, such as a broader smartwatch companion, entered the roadmap but did not fully mature during my tenure.

The important shift was organizational.

Innovation was treated as a product decision requiring evidence, not a design demonstration.

[ + ]

Outcome

Three innovation initiatives moved from concept into working product and infrastructure.

DEWA Alexa

• Launched as the GCC’s first Arabic Amazon Alexa skill
• Delivered bilingual English and Arabic voice interaction
• Added graphical support on compatible devices
• Implemented right-to-left APL experiences
• Received CNN coverage at launch
• Established a regional reference for Arabic utility voice services

Green Charger

• Supported a public network of approximately 400 chargers at the time
• Connected discovery, pre-booking, geofencing, charging, and billing
• Integrated the EV journey into the wider Smart Living platform
• Connected customer experience with internal operational monitoring
• Treated charging as a continuous service rather than a terminal transaction

Smart Living

• Adopted emerging mobile patterns ahead of typical government timelines
• Introduced widgets and faster access to high-frequency services
• Expanded the roadmap toward more connected-device experiences
• Maintained stronger parity with consumer-platform expectations

The most important outcome was not that the projects were “innovative.”

It was that they shipped across real constraints:

• Public infrastructure
• Legacy systems
• Bilingual interaction
• Physical hardware
• Government-scale service expectations
• Emerging platform technology

A prototype can demonstrate an idea.

These products had to survive contact with Dubai.

What I Would Do Differently

I would have built post-launch instrumentation into every initiative from the beginning.

The projects were strong on:

• Discovery
• Product definition
• Interaction architecture
• Delivery
• Launch

They were weaker on longitudinal measurement.

For Alexa, I would want a clearer view of:

• Which intents became habitual
• Which language users preferred by task
• Where voice-only interactions failed
• Which queries moved users toward visual devices
• How use changed after the novelty period

For Green Charger, I would want to measure:

• Booking-to-arrival conversion
• Failed arrival journeys
• Charger availability accuracy
• Geofence success
• Session-completion rates
• Repeat charging behavior
• How network expansion changed user confidence

For Smart Living, I would want to know:

• Which early platform patterns created durable behavior
• Which were adopted because they were useful
• Which were used only because they were new
• Whether widgets reduced task time or simply moved entry points

The missing layer was not more launch data.

It was product-learning infrastructure.

Innovation teams are naturally rewarded for introducing something new.

A mature innovation function should be rewarded for proving whether the new behavior lasted.

I would pair every new-category launch with:

A six-month measurement plan
Explicit adoption and retention hypotheses
Operational reliability metrics
Language and device segmentation
Kill, redesign, and scale criteria
A named owner for post-launch learning

The product lesson is:

A category first is valuable only if the organization learns what happened after everyone stopped calling it new.

Product Lessons

01  The visible interface is often the smallest part of a public-service product.

02  Voice is excellent for intent, but dense information still needs visual structure.

03  Arabic product parity requires interaction redesign, not translated English flows.

04  EV charging begins when the driver decides to travel, not when the cable connects.

05  In hardware–software systems, operational reliability is part of the user experience.

06  Internal dashboards and customer interfaces may be different surfaces of the same product.

07  Government products are judged against consumer expectations, not government precedent.

08  Emerging patterns should be adopted because they reduce effort, not because they signal innovation.

09  A launch proves that a product can exist. Instrumentation proves whether it should continue.

10  New-category product work is the discipline of designing the system before the category has agreed on its rules.

Closing Note

/* the service behind the interface */

> The voice needed a screen.
> The charger needed a booking system.
> The app needed an operational layer.

> Every time the product looked simple,
> the system behind it was doing the hard work.

// infrastructure becomes an experience at the moment a human depends on it