AmiGO, with over a million drivers a month, tested TomTom’s new SDK on real roads. A new API reference took developers from 2 of 7 to 7 of 7, and shipped.
One way to pay for parking, charging and tolls inside navigation. Charger prices shipped with carmakers; paid parking reached alpha in the TomTom app in the US.
Shipped in partRead the case →
Now
TomTom · 2025– · Senior Staff UX Designer
Designing for AI agents
In development
In the car
How an in-car navigation agent behaves: quiet by default, speaking up when today is different, always with a reason.
In the docs
Developer docs written for people are now read by agents too. I prototyped the page structure and writing rules that work for both.
How I work
In code, not canvases: Claude and GitHub against the real APIs, mostly by voice. The agent builds; I frame, decide and set the checks.
Drivers switching to electric want the peace of mind they had with petrol. Delivering it took the map, the routing, the SDK, the in-car screen and each carmaker’s systems working as one. As EV experience lead, I designed that journey end to end, and five carmakers adopted it.
Role
Staff UX Designer, EV experience lead
Team
Product manager, three designers, two researchers
Years
2023–25
Status
Shipped, and now part of TomTom’s EV Experience. Ratings and driver feedback stayed concept.
The journey, step by step
Before the trip
01Onboard
Preferences are an optional prompt on the home screen, in two steps: charging operators, then services wanted nearby.
Before the trip
02Plan
The trip opens with its charging stops already planned, each with the charge on arrival and live availability.
Before the trip
03Sync
The same preferences appear in the car’s settings: networks, rated chargers, services, and the minimum charge for stops and arrival.
On the road
04Find
Charger Finder opens with live availability first. One filter narrows it to the networks the driver chose at onboarding.
On the road
05Choose
Connectors and payment first, then services nearby. Below them, the concept: what other drivers say, and liking a charger to see more like it.
Shipped in part
On the road
06Re-plan
Leave a charger with less charge than planned and the route adds a stop instead of failing.
After the stop
07Rate
On arrival, one tap to rate the charger, with optional reasons: charged, feels safe, good value, services nearby.
Concept
After the stop
08Reflect
After the trip, the phone asks once more. The answer shapes the next suggestion.
Concept
Situation
Drivers
They just wanted to drive, but their mindset shifted during a trip, and they didn’t trust chargers they’d never used.
Carmakers
They wanted deep personalisation for their drivers, and they wanted to own the driver data. TomTom couldn’t act as a data processor.
TomTom
EV wasn’t the core business, and nobody owned the experience end to end: charger data in the map, consumption-based routing, the SDKs, the in-car interface and each carmaker’s integration.
The call
I treated charging as one journey across phone and car, not a set of features, and took ownership of it across map data, routing, SDK and interface.
I also wanted a TomTom companion app to prove the phone half. Product management disagreed: it wasn’t in our agreements, and carmakers build their own apps from our components. They wanted the effort in the car.
Having led mobile before, I proposed a middle path: the car would be the product, and the phone would exist as working prototypes, to show carmakers what our components made possible.
Design principle
Personalisation you don’t own
Preferences stay with the carmaker, which knows who is driving. They reach TomTom with each request, get used once, and aren’t stored. TomTom adds what it does know: position, time of day, live charger data. Every flow had to work on those terms.
How I got there
Four charging mindsets
With our researcher, I mapped how drivers approach charging on two axes: how familiar the place is, and whether the trip is within range. Four mindsets came out: Cautious, Journey-oriented, Goal-oriented and Confident. The model became the shared reference for UX, product and engineering when deciding what to build first.
Four charging mindsets, each with a driver’s own words. Portraits are stock photos.
Mindsets across the trip
We then laid the four mindsets across the phases of a trip: setting up and planning, driving, and charging. Each cell holds the use cases research gave us for that mindset at that moment. The eight steps come out of that map.
Every use case from research, by mindset and by phase of the trip: the map the features were chosen from.
Trust as a loop
The idea was a loop: preferences set once, used on every trip, weighed against other drivers’ ratings, and updated by a rating at the stop and a question after the trip. The first half shipped with carmakers: preferences, planning with arrival charge, Charger Finder. The second half, ratings, liking a charger and feedback, stayed concept. It stopped at the way back: feedback needed a channel from drivers to TomTom, and in a carmaker’s car the driver belongs to the carmaker.
The half that stayed concept: other drivers’ ratings, a rating on arrival, a question after the trip.Concept
Charger Finder
The charger search that came out of this work. It’s part of TomTom’s design system, delivered to carmakers with adaptations for premium brands.
One component, adapted to four carmakers’ screens and the phone.
Before designing, we sat in three Chinese carmakers’ EVs at local dealerships and recorded how each handled range and charger search.
What changed
Adopted by five carmakers, with little change to the proposed experience.
TomTom now offers the journey to carmakers as EV Experience: plan in the app, hand over to the car, charge with confidence.
TomTom and CARIAD have taken next-gen navigation to the road, starting with Audi’s premium electric cars (press release). I tested the integration.
Newer carmakers took it most directly. They wanted a turnkey answer, not a starting point.
I joined the first calls with each carmaker, alongside the sales lead, product lead and VP of Product. The UX pack became part of TomTom’s pitch.
Charger Finder is registered as EU design 015086197.
In hindsight
I designed the rating at the stop and the question after the trip before anyone knew how the answers would reach TomTom. Next time I’d design the channel first: who owns the driver, and who sees the answer.
← Selected workBringing payment into a gas marketplace02 of 04
Chama · 2017–18 · Lead Designer
Bringing payment into a gas marketplace
Chama let people in São Paulo order bottled gas from local dealers, but the money still changed hands at the door. As its first designer, I brought the payment into the app, for the customer, the driver at the door and the dealer. Of the customers who paid by card, more than 70% moved to paying in the app.
Role
Lead Designer, Chama’s first designer
Team
Payment team; a second designer and researcher on the dealer tool
Years
2017–18
Status
Shipped in late 2018. In use until the company was sold.
One order, step by step
The customer pays
01Pick a dealer
Dealers by brand, with price, rating and delivery time.
The customer pays
02Card or cash
Card in the app; debit and cash at the door.
The customer pays
03Order sent
Confirm, a moment of processing, and the order is with the dealer.
At the door
04The code at the door
The driver is on the way, and the code is on the customer’s screen: it confirms the delivery and approves the payment.
The dealer is paid
05Paid out
The balance, the date it is paid, and how it was built.
The dealer is paid
06Every order
Every order, however it was paid.
Situation
Customers
In 60 interviews across São Paulo, we saw gas ordered like a taxi: a dealer’s magnet on the fridge, a phone call, and cash or a card on the driver’s machine at the door.
Dealers
Every delivery already came with proof: the card machine’s receipt and the driver’s delivery form.
Chama
A million orders went through Chama while I was there, but none of the money did. Taking the payment meant holding the customer’s money with no proof the bottle had arrived.
A dealer’s magnet on the fridge
The card machine at the door
Orders on handwritten sheets
Once Chama took the money, one step had no proof: the handover at the door.
The call
I designed the payment as one flow with three ends: what the customer paid, what the driver confirmed and what the dealer was paid had to agree at every step.
The hard part was the door. Product and operations wanted proof Chama could stand behind: when a customer says the bottle never came and the dealer says it did, someone loses the money. I argued a code broke our promise of easy payment and gave drivers one more thing to remember. The team chose the code, so I set out to make it cost as little as possible.
“Adding friction in the experience … will not make this the preferred method of payment.”
Me, in the team’s Slack, August 2018
How I got there
The checkout flow map
Card, debit and cash, with the checks for a saved card and a failed payment. I tested a one-page checkout against steps with seven customers. Neither won, so we chose steps, which suited the payment system, and added what both groups asked for: a review before paying and progress at the top.
My checkout flow map, September 2018: card, debit and cash, with the checks for a saved card and a failed payment.
Code or tap
I designed both ways to confirm a delivery, side by side: the customer reads a code to the driver, or taps to say the bottle arrived. The tap costs the driver nothing, but whoever ordered isn’t always home, and a tap can be a mistake. We shipped the code, and kept the tap as the customer’s way to close the order.
The two ways to confirm a delivery, side by side.
The ticket
Dealers told us drivers would forget the code; one already had hers photograph discount codes. So the code became a ticket, clear enough for a driver to photograph and easy to send to whoever will be home.
The order with its code, the ticket, sharing it and the ticket in testing.
Three versions of the finance tab
The version we tested with six dealers showed everything, and overwhelmed most of them. The third reorders it like an iceberg: the balance and the date it’s paid above the waterline, the month and every order below, so any figure traces back to an order.
August to late September 2018. Figures are placeholders.
What changed
Of the customers who paid by card, more than 70% moved to paying in the app.
It shipped in late 2018 and stayed in use until the company was sold. Chama put the payment screen in its TV ad that year.
The purchase cycle stayed the harder problem. A bottle lasts months and you can’t see how much is left, so people forgot or deleted the app between orders. The reorder alarm we tested didn’t change that. Chama later pivoted and was sold.
Payout timing. Small dealers were used to card money the next day, and 4 of the 6 we tested with said our payout period would hurt their business. I’d bring finance into designing payout timing in the first week, not after the first dealer test.
Credits
Nika Gou, designer · Lincoln Suarez, dealer-tool designer, who drew the code illustrations with Nika · Ana Lucia, researcher, Brazil
Drivers pay for parking, charging and tolls in a different app every time. As the sole designer working with Product, I designed how payment could live inside TomTom’s navigation, in the car and on the phone. Charger prices shipped with carmakers; paid parking with Flash reached alpha in the TomTom app.
Role
Senior Staff UX Designer, sole designer
Team
Product manager, engineering
Years
2025–26
Status
Shipped in part: charger prices shipped with carmakers. The in-car parking journey and wallet stayed vision, and an alpha ran in the US app.
Situation
Drivers and carmakers
Drivers already paid for parking, charging and tolls, just never in the same place. Where carmakers offered payment in the car, each did it differently, so the experience changed from car to car.
The call
A transaction layer, not a parking app
One journey for every service, in three moments: find, arrive and start, leave and pay. Parking came first; charging and tolls use the same three moments.
Three moments for every service, and two ways to pay.
While driving, navigation stays navigation
Payment appears at the moments it’s needed. The guidance never changes around it.
Don’t show a price you can’t trust
Some parking price data lacked hourly tariffs and didn’t match the operators’ own sites. I recommended not showing it until a reliable source existed. A wrong price at the gate costs more trust than no price on the map.
How I got there
Prices for charging
Charger pricing is dynamic and inconsistent, and it depends on the driver’s charge card and subscription, which the product can’t see. So I kept it simple. The charger list shows the energy price for each speed, in local currency, with a note that other fees may apply. Each stop on a route shows an indicative cost. There’s no total for the trip: on a long route with a ferry or tolls, a total built from partial prices would mislead.
Each charging speed shows its energy price
The next stop shows what it costs
Each stop on the route shows its cost. Illustrative figures
What I dropped
Three ideas looked helpful and added too much complexity: prices by charging time, a cost breakdown with a flat fee, and a total estimate for the trip. Each would be wrong often enough to cost trust. I chose an indicative figure over a precise one.
Prices by charging time
A cost breakdown at the stop
A total for the trip
An alpha before the car
With Product, I took the first slice to alpha in the TomTom app: paid parking with Flash in the US, from sign-up to booking, the parking pass and payment. We wanted to learn how the whole transaction felt, and whether drivers book ahead or park on demand.
The alpha in the TomTom app in the US: the whole flow, from the menu to the bill.Concept, tested
What changed
Charger prices shipped with carmakers: the energy price in the list, a note on other fees, an indicative cost for each stop on the route.
Paid parking with Flash reached alpha in the TomTom app in the US. TomTom announced the partnership in September 2025. It didn’t go beyond alpha.
The partner’s API shaped the flow more than the design did. It was built around bookings, like booking a hotel: a location, a start time and an end time. Our navigation shows parking at the moment a driver arrives and starts looking for it, so booking ahead matters less in the car. That complicated the flow.
The in-car journey and the wallet stayed vision.
In hindsight
The parking partner’s API was built for booking ahead, like a hotel: it needed a place and a start and end time. Navigation shows parking at the moment you arrive, when booking ahead matters least, so the two didn’t line up and the flow got heavier. Next time I’d agree with the partner how their API fits the moment of need before designing the flow around it.
TomTom was rebuilding its navigation as an SDK to sell to other companies, and AmiGO, with over a million drivers a month, became its first app. As design manager for mobile, and from mid-2021 for the SDK’s developer experience too, I ran design across both: the app that tested the SDK on real roads, and a developer’s first hour building on it. AmiGO moved onto the SDK and kept its drivers.
Role
Design Manager, mobile then developer experience
Team
Six designers and two researchers, across app and SDK
Years
2020–23
Status
AmiGO shipped on the SDK. The API reference shipped and is live today, built on the structure from Get started. The Get started wizards stayed vision.
The road and the first hour, step by step
On the road
01Answer by voice
A driver is asked a yes-or-no question by voice, so they don’t look down. The confirmations shipped in AmiGO.
Shipped in part
On the road
02Time to green
A countdown at the red light. It only ran in Stuttgart.
Concept, Stuttgart only
On the road
03The north star
Where we wanted the app to go. It led to the TomTom app, live today.
Vision
The first hour
04Get started
A project set up in a few choices. It stayed a vision; its page structure and naming went into the reference.
Vision
The first hour
05Build it, see the code
Each choice changes the preview and the code together.
Vision
The first hour
06Find the API
The reference grouped by what you build, as tested. It shipped and is live today.
Shipped, live today
Situation
Drivers
Over a million a month used AmiGO, and most knew where they were going. They opened it for traffic, speed cameras and what other drivers reported.
SDK customers
Logistics, ride-hailing and delivery teams wanted the opposite: navigation to places their drivers had never been. The SDK gave them everything and no way in: 23 days on average from a signed evaluation to the first API call.
TomTom
The SDK had to work on real roads before customers built on it, and AmiGO had to move onto it without its drivers noticing.
One SDK, two kinds of customer, and where my team sat: mobile from 2020, developer experience from mid-2021.
The call
I ran the app and the SDK as one team with one loop. When the developer experience designers joined my team in mid-2021, every new SDK build went on the road in AmiGO, and what we saw there set what the SDK fixed next.
I also proposed a UI kit: the navigation journey, from search to arrival, as widgets a developer could call instead of building from scratch. It wasn’t feasible with a React Native app on a native SDK. So I put the journey into the way developers learn the SDK instead.
How I got there
Drive tests, both ways
My team and I drove each build, looking for regressions in the map and the guidance, and fed what drivers told us back into the SDK’s priorities. The road also showed where the two audiences split: to keep AmiGO’s drivers, some features stayed on the old platform until the SDK caught up.
The loop between each SDK build and AmiGO on real roads.
The SDK’s first UI
The sample apps in the code repository and the screens in the docs were built from our designs, in AmiGO’s look: a thin layer, meant to be replaced, but one story from the app to the SDK.
Get started, in journey order
The UI kit’s journey became the steps of Get started: map, search, route, navigate, arrive, driver assistance. Each step is a configurator: choose an option, and the preview and the code change together. The wizards stayed a vision, but the page structure and naming they set out carried into the documentation.
The UI kit’s phases, and the six steps of Get started they became.
The reference, renamed
In research, 1 of 8 developers completed a customisation task; they got lost in the API reference. The module names already held a structure, domain then topic, so we regrouped the reference around it, and I shortened the names for the web. Then we tested both versions with seven developers, and the regrouped reference shipped.
Module names to domain and topic, and the test with seven developers.
What changed
AmiGO moved onto the SDK and kept its drivers: over a million a month, rated 4.5 on iOS and 4.7 on Android.
In testing, the new reference took developers from 2 of 7 to 7 of 7. It shipped and is live today.
AmiGO’s yes-or-no confirmations by voice shipped. The Get started wizards stayed vision, but their page structure and naming shipped in the documentation.
The north star led to the TomTom app, live today: a showcase for the EV navigation in case 1.
Drive tests and regular design critique, which I ran myself, became how the team worked, not events.
In hindsight
The UI kit was the right call for its time: developers needed a working start, not a blank canvas. Today an AI assistant can write much of that glue from good documentation, so I’d put the same effort into docs an assistant can read as well as a developer.
Credits
Strategy with Anand Shankar, product manager for AmiGO · Composition and video editing: me · Visual and UI design, and the artwork: Cindy Rodríguez · Voice for the vision films: Miaka Chen · Miguel Sioco, Senior User Researcher · Tim Standring, UI in the SDK · Maryna Akolzina, visual design in the app, and the EV work inside AmiGO and its search
QWIC · 2019–20 · Lead UX Designer · Stopped in 2020
An e-bike cockpit
The handlebar console: icons, speed and state on one small round screen.
The work
The brief
QWIC, a Dutch e-bike maker, wanted its own digital experience instead of relying on suppliers. I set five objectives for the programme: fewer third-party dependencies, shared technology across the range, one experience true to the brand, better customer support and a base for new features.
What I did
I ran the workshops that set customer segments and a north star, brought in industrial designer Sam Broadbent, and designed the cockpit, the companion app and the icon system with mechanical, mobile, backend and embedded engineers.
How it ended
COVID and the supply-chain crisis stopped new products in 2020, and it didn’t ship.
The app finds the bike, shows battery and range, and explains what is using the power.
The north star: from three rider segments on semi-integrated bikes to five on fully integrated bikes by 2022.
See the research canvases
User needs: seven riders by jobs to be done, gains and pains.
Product fit: the same riders by comfort, load, peace of mind and personal features.
TomTom · 2016–17 · Lead Designer · Stopped in 2017
A sports watch on Android
One interaction model across the range.
The work
The brief
TomTom planned to move its sports watches from a real-time operating system to Android, across running, fitness, hiking and golf.
What I did
As lead designer, with visual designer Elmar Haneveld, I defined the interaction model: app navigation, input and the link to the companion app. With industrial designer Sam Broadbent, I prototyped input methods and chose displays. We kept the large, glanceable numbers TomTom watches were known for, and tested early prototypes with users.
How it ended
In 2017 TomTom left sports wearables to focus on automotive, and the programme stopped.
The clock face is home: notifications above, applets below, settings to the right.Steps, heart rate, routes and workouts in a stack under the clock.
From research to prototype, ending on a phone strapped to the wrist.Silent · 0:56
For four years I worked on one question: could the car tell you about your drive to work before you asked? Three answers, from a small screen to no screen to every screen you own. None shipped as a product. The prediction behind them did.
Role
Interaction Designer (Spark), Lead Designer (PUCK, MOVE)
Team
With Sam Broadbent, industrial design
Years
2012–16
Status
Vision. Spark stopped in development; its prediction shipped in TomTom’s in-car software.
One question, three answers
Spark · 2012–14
01Learned your drive
A small screen that learned your commute and predicted the traffic.
Stopped in development
PUCK · 2014–15
02It tells you, once
At the start of the drive, one line: when you’ll arrive, and which way.
Concept, tested
PUCK · 2014–15
03In a jam, how long
Stuck in traffic, it says how long. The driver found it reassuring.
Concept, tested
MOVE · 2016
04Before you leave
Every way to work, the traffic on each, and when to go.
Vision
MOVE · 2016
05An unplanned stop
A lift for someone on the way: add the stop, and the timing updates.
Vision
MOVE · 2016
06In the jam
The delay, how you feel, and a word from drivers in the same queue.
Vision
MOVE · 2016
07Arrived
Arrival on the watch, and how the time went.
Vision
Situation
Commuters
Most drives were the same trip, to work and back, and nobody planned them. People checked the traffic if they remembered, and found the jam when they were in it.
TomTom
It had the traffic data to predict the trip. The open question was where the prediction should live: on a small screen in the car, in a voice with no screen, or across the devices a commuter already carried.
The call
Spark, 2012–14: a small screen
A small in-car device that learned your regular drives and predicted ETA and traffic before you asked. With industrial designer Sam Broadbent, I designed the interaction across the device and the phone: unboxing, onboarding, and getting the right information to a driver at the right moment on a tiny screen, with a basic speaker and no voice. It reached development but didn’t ship: the bill of materials kept growing until the device cost more than it was worth next to a phone on the dashboard.
Spark on the steering wheel: prediction on a small round screen.
PUCK, 2014–15: no screen
PUCK took the screen away: a speaker, microphone and GPS on the dash, with the phone doing the work. It asked one question at the start of the drive and spoke up only when there was a decision to make, like a faster route or traffic ahead.
The phone does the work. PUCK is a speaker, microphone and GPS on the dash, with no screen and no battery.
MOVE, 2016: every screen you own
MOVE followed the same commute across car and transit, on the phone, the watch and the laptop. You answer once how you travel and where home and work are. It tells you when to leave, takes an unplanned stop in its stride, warns you of the jam, and shows you your week.
How I got there
A dry run, then real commutes
Dan Oostveen, TomTom’s product manager for PUCK, drove a dry run first: a sketch of the experience, filmed, not a test. Then I devised the test and ran it Wizard-of-Oz style: PUCK’s voice played live while 10 drivers in London drove their own commutes.
The test with 10 drivers in London: the faster route landed, but the spoken instruction at a junction didn’t, for 4 of them.The test: four of the drivers on their own commutes. Faces blurred, names replaced, voices kept.Sound · 4:16The dry run before it: Dan Oostveen, TomTom’s product manager for PUCK, on his own drive. A sketch of the experience, not a test.Sketch · sound, subtitled
A vision film, not a spec
For MOVE I made two films, a drive to work and a train commute, to show the idea across phone, watch and laptop in one working day. The drive has an unplanned stop along the way, because that is where a commute app earns its place.
MOVE, the drive to work with an unplanned stop: phone, watch and laptop. Cut to 90 seconds from 4:45.Sound · 1:30
What changed
Spark’s route learning, ETA and destination prediction later shipped in TomTom’s in-car software.
PUCK’s test: 8 of 10 drivers took the faster route, but only 6 found the spoken instruction clear at a junction. At a decision point, voice needs a screen beside it.
MOVE was parked: TomTom didn’t yet have the cloud mapping platform it needed. The films became a reference inside TomTom for later commuter work.
In hindsight
Twelve years later I’m designing how navigation agents work in the car. Same problem, new tools.
Credits
Sam Broadbent, industrial design · WeArePerspective, PUCK research · Dan Oostveen, product manager, PUCK · Bart Nijssen, designer on MOVE: the watch, and the film · Pauline Appels, actor
About
I’m a product designer from London, based in Amsterdam. I trained as an engineer, with a BSc in Motorsport Technology from Oxford Brookes, then an MSc in Integrated Product Design at Brunel.
For fifteen years I’ve designed products where hardware, software and business meet. Most of that time has been at TomTom, with QWIC and Chama in between.
I’m usually handed the problem that sits between teams. I prototype early and make the whole system visible, so people can decide.
Outside work: cooking, cars, running, music and family.
