← All work

Mobility · Consumer UX · Field Operations

Coup
Mobility

A Bosch-owned e-moped fleet operating across three European cities. I held two distinct mandates: redesigning the consumer ride experience from the ground up, and building the field operations platform — from a blank page — that kept 5,000 scooters on the road.

Product Designer

Berlin · Paris · Madrid

Consumer ride app · Dispatcher dashboard · Field worker app

User research · Concept design · Greenfield product build

Coup Mobility
5,000
Electric mopeds across
three European cities
2
Distinct products designed —
consumer app & ops platform
Built
Field ops tool created from
scratch — nothing existed before
3
Cities. One platform.
Hundreds of field workers.

The brief

A product people loved.
An experience that hadn't
caught up yet.

Coup was genuinely ahead of its time — fully electric, free-floating mopeds operating across Berlin, Paris and Madrid before the category existed in any meaningful sense. Backed by Bosch and growing fast, the product had real traction. Riders chose it not because the app was exceptional, but in spite of it.

The consumer experience had been built for speed — to get the fleet live. What remained was a functional but uninspiring ride flow that didn't reflect the quality of the product it was selling. That was the first mandate: a full redesign of the consumer application, focused on making every moment of the ride — from finding a scooter to ending the journey — feel as considered and effortless as the scooters themselves.

The second mandate was more foundational. Behind the scenes, Coup's field operations were running on improvisation — WhatsApp groups, spreadsheets, and runners with no reliable way to receive assignments, log maintenance, or report issues. Each scooter that sat offline longer than it needed to represented direct revenue loss, multiplied across thousands of vehicles and three cities.

No tool existed to manage any of this. I was brought in to design and build it. The field operations platform — dispatcher dashboard and field worker app — was a greenfield brief, and one that demanded understanding not just the UX but the operational reality of people maintaining vehicles on the street, in all weather, under time pressure.

01

The consumer ride app

Redesigning for quality.
Not just function.

The existing app worked. Riders could find, unlock, and end a ride. But the experience was transactional in the worst sense — it got out of the way rather than enhancing the journey. For a product as visceral and enjoyable as riding an electric moped through a city, that felt like a missed opportunity at every screen.

The redesign started with a fundamental question: what should it feel like to use this? Not which features to add or which flows to simplify, but what emotional register the product should occupy. The answer — arrived at through user research across all three cities — was confidence. Riders wanted to feel in control, informed, and unencumbered. The design followed from that.

The ride phase was rebuilt end-to-end: map and discovery, scooter selection, pre-ride checks, the active ride experience, and the end-of-ride flow. Each moment was treated as an opportunity to either erode trust or build it. Clarity of information, timing of prompts, and the quality of micro-interactions all carried weight.

The redesign also quietly turned the consumer app into a data asset for operations. Passive reporting — surfaced at moments of natural frustration rather than as explicit tasks — gave the ops team real-time intelligence on scooter condition without adding any burden to the rider. A three-tap popup at the moment of cancellation was worth more than any formal reporting flow would have been.

Ride UX redesign — before state

Mapping the friction points in the existing ride flow before redesigning

Redesigned ride experience

After: a ride flow built around confidence, clarity and quiet delight

App screen — discovery App screen — active ride App screen — end of ride

Passive intelligence

One in eight rides was
cancelled. Nobody knew why.

A 12% pre-engine cancellation rate was a significant and expensive signal — one the operations team had no way to decode. Damage? Low battery? Wrong scooter? Missing helmet? Without structured data, every intervention was a guess.

Embedded within the redesigned cancellation flow was a lightweight structured prompt: a few options, a single tap, and the rider moved on. The ops team got a categorised, timestamped report. Within weeks of launch, the real distribution of cancellation causes was clear for the first time — and fixes could be targeted accordingly rather than spread across guesses.

Cancellation flow — passive data collection

Cancellation prompt — structured reporting built into a moment riders were already experiencing

02

The field operations platform

Nothing existed.
We built the whole thing.

Before the field operations platform existed, Coup's ground teams were operating on instinct and improvisation. Assignments were communicated via WhatsApp. Maintenance records lived in spreadsheets — if they were logged at all. There was no reliable way for dispatchers to see the status of the fleet in real time, no structured workflow for field runners to receive and complete tasks, and no audit trail for the work being done on thousands of scooters across three cities.

Every gap in that system had a direct cost. A scooter with an unresolved fault stayed offline. A runner without a clear assignment drove around inefficiently. A dispatcher without accurate fleet data made decisions based on intuition rather than information.

The brief was open-ended and the starting point was blank. I began with immersive research into how field teams actually operated — riding along with runners, spending time with dispatchers, mapping the informal systems they'd built to cope with the absence of proper tooling. What emerged was a clear picture of two distinct use cases that needed to work in concert: the dispatcher who needed strategic control, and the field worker who needed clarity in the moment.

Those two needs drove two separate but connected products: a web-based dispatcher dashboard for ops managers, and a mobile-first field worker app designed for use on the street.

🗺
Fleet status at a glance

Live map view of every scooter in the fleet — online, offline, flagged, or in maintenance. Dispatchers could see the entire city's health in seconds, without chasing runners for updates.

🔧
Structured maintenance logging

Field workers received clear assignments, completed tasks through a guided flow, and logged maintenance outcomes in a format that fed directly into the dispatcher's view. Every action left a traceable record.

📋
Assignment management

Dispatchers could create, assign, and reprioritise tasks in real time based on fleet conditions. Runners got their next job pushed to their phone — no calls, no WhatsApp chains, no ambiguity.

Field worker app — assignment view

Field worker app — assignments, status updates and maintenance logging in a single flow

Maintenance report screen

Maintenance report — structured outcome logging that built the ops team's data picture over time

Login screen Scooter status view Dispatcher overview

The field worker app was designed with a specific constraint in mind: use in physically demanding conditions. Runners operated in rain, in traffic, in winter, often one-handed. Every interaction had to work with gloves on. Text had to be legible in full sun. Actions had to be confident and irreversible — the kind of clarity that removes hesitation rather than creating it.

Research — design before commitment

Validating a costly hypothesis
before anyone built anything.

A proposal emerged to let engaged riders earn credits by swapping depleted scooter batteries — a community-powered approach to reducing ops costs and driver dependency. The appeal was obvious. The problem: validating it properly would require physical charging infrastructure that didn't exist.

Rather than waiting for infrastructure, I designed a lightweight in-app pilot that let us collect meaningful behavioural data from real users through small, targeted changes to the existing flow. The research came back quickly and cheaply — and gave the business what it needed to make an informed decision about whether to commit to the infrastructure investment. Design used as a research instrument rather than a delivery mechanism.

Community battery swap pilot

Community battery swapping pilot — testing intent before infrastructure commitment