Mazda · KDDI · Connected mobility prototype

A business case you can actually drive.

Mazda and KDDI wanted to know whether a carmaker could sell mobility rather than just cars. You cannot answer that with a mockup, so we built the whole thing - rider app, driver app, fleet and telemetry admin, and the hardware that turns the car itself into a data source - and put it on a road.

A complete ride-share ecosystem, built to be tested.

The Mazda ride-share driver app: log in, and start a shift.

Client: Mazda, with KDDI
Sector: Automotive · connected mobility
Role: Product design and full-stack build
Surfaces: Rider app, driver app, fleet admin
Connected: OBD telemetry
Languages: English, Thai, Japanese
Expertise: Product Design, Customer Experience Design, Interface Design, Full Stack Development

The need

You cannot prototype a marketplace one screen at a time.

Selling vehicles and selling mobility are not the same business wearing different clothes. One ends at the forecourt; the other begins there, and keeps going for every trip after. Mazda wanted to know whether the second one was worth entering - and KDDI, whose network and IoT platform would carry it, wanted to know what it would take to run.

That is a business-model question, and business-model questions are unusually hostile to prototypes. A ride-share market has three sides - someone who wants a trip, someone who drives it, someone accountable for the fleet - and it only tells you anything when all three are present at once. Leave one out and you have not built a smaller version of the thing. You have built something that cannot teach you what you asked.

The rider

Books on demand or ahead of time, picks a car, talks to the driver, rates the trip. The half everyone pictures, and the half that proves the least on its own.

The driver

Starts a shift, accepts a job, navigates it, closes it out. Where a ride-share business is actually won or lost, and the surface most prototypes skip.

The operator

Sees the fleet, the drivers and the cars - not as a list, but as something happening right now, with a record of how it went.

What we built

Three surfaces, and the car as a fourth.

Two apps and an admin console are a ride-share platform. What made this one a carmaker's ride-share platform was plugging into the thing Mazda already had and nobody else did: the vehicle.

Rider app

Real-time and scheduled trips, car selection, in-app chat with the driver, and a rating at the end. Built in English, Thai and Japanese from the start rather than translated afterwards.

Driver app

Shift management, trip acceptance, live navigation, and the paperwork at the close of a job - ratings given and received, charges logged.

Fleet and telemetry admin

Vehicles, drivers and trips in one place, with the live feed from each car arriving beside the trip it belongs to.

Rider and driver screens: in-app chat, route options with journey times, and live navigation. — Chat, route choice, and the trip as it runs.

The driver's scheduled trips list and a trip detail with pickup and dropoff addresses. — Booked ahead, acknowledged, and waiting on a shift.

The interface

Premium is a feeling, and it is mostly made of small decisions.

The brief was not to match the global ride-hailing apps but to sit above them - a Mazda-branded service should feel like the brand on the bonnet. That is not a logo exercise. It is the weight of the type, the restraint of the palette, the way a car renders on a dark screen, how quickly the thing gets out of your way once you have asked it for a trip.

The reel is the rider app as it ran. It opens where the product opens: a language.

EnglishThaiJapanese

Three languages in a prototype is not gold-plating. Whether a mobility service travels is part of the business case, and a build that only works in one language answers the question in one market.

The Mazda ride-share rider app - a Touchfoundry prototype — The rider app, running. English, Thai and Japanese - chosen at the door.

The differentiator

Everyone else rents the car. Mazda makes it.

A ride-hailing operator knows where its cars are because the driver's phone tells it. A carmaker can know something better, because it has the vehicle: how it was actually driven.

We fitted plug-and-play devices to the universal OBD port - the diagnostic socket every modern car already has, which is what makes this portable rather than a Mazda-only trick - and streamed live data into the platform. Speed. Velocity. Braking. Acceleration.

Pull awayJunctionOpen roadHard brake

The car
A plug-and-play device in the universal OBD port, which every modern car already has.
The signals
Streamed live for the length of the trip, not sampled at the end.
- Speed
- Velocity
- Acceleration
- Braking
The events
Pulling away, slowing for a junction, opening up, and the one hard brake a rating would never have mentioned.

SpeedHow fast, continuously, not sampled at the end

VelocityDirection with the pace, so a route reads as a route

AccelerationHow the car was asked to move off

BrakingAnd how hard it was asked to stop

Which turns a rating into something better than an opinion

A five-star rating tells an operator a passenger was happy. Telemetry tells them how the car was driven, on every trip, whether or not anyone filled in a form. That is the difference between hoping a fleet is safe and being able to say so - and for a brand lending its badge to somebody else's driving, that gap is the whole risk.

Why it worked

Three organisations, one thing that had to start.

KDDI brought the network and the IoT backbone. Mazda brought the brand, the vehicles and the question. Neither was short of engineering talent, and that is usually the point at which a programme like this stalls - not because a piece is missing, but because the pieces belong to different people, in different buildings, on different clocks, and nobody owns the seam.

That was our job. Not the most glamorous line in a case study, and reliably the one that decides whether a prototype exists by the date it was needed.

Integration is the deliverable

Someone has to hold the whole shape while each party builds their part of it. We did, which is why there was something to drive rather than three things that nearly connected.

Fast enough to still be a question

A business case has a shelf life. Prove it late and the answer arrives after the decision has already been made by default.

Built to be thrown away

A proof of concept earns its keep by being honest about what it is. Ours was made to be driven, learned from, and argued with - not defended.

The outcome

The question got an answer.

The concept worked on the road, not just in the lab. Mazda and KDDI ended the engagement with a complete, working ride-share ecosystem carrying Mazda's brand, running on KDDI's backbone, reporting on itself from the vehicle up - and with the evidence to argue about what came next from something real.

That is what a proof of concept is for. Not to be the product, but to make the decision about the product a smaller one.

A carmaker's brand can carry a mobility service

Connected-car data is a real differentiator, not a talking point

The full three-sided ecosystem can be stood up as a prototype

It holds together across languages and markets

The capabilities