TomTom
Creating new generation map styling tool
Deliverabels
Team
2 UX designers
2 GIS designers
My roles
UX designer
UX researcher
Tools
Figma
MapLibre GL JS
TL;DR
TomTom MapMaker is a cloud-based map styling web application that lets teams design, test, and publish custom map styles without writing code. It’s a tool that supports collaboration between GIS (Geographic Information System) designers and OEM (Original Equipment Manufacturers, car makers) engineers by making map customization more accessible. It is achieved through branding POI (Points of Interest), separate draft environment to test and production to ship, ease of navigation through search, map inspection, traffic simulation, and inclusive accessibility features.
Challenge
Map Maker is next step after TomTom MapStyler: it keeps the same spirit of giving teams control over how maps look, but moves the workflow into a cloud-native product with collaboration, publishing, and reuse built in. Map Styler historically required an API key to start and was often used as a “design tool that outputs a style,” whereas Map Maker is designed as a full workflow tool where a style lives, evolves, and ships.
Solution
A key bridge for adoption was making it practical for existing Map Styler users to migrate without losing work: export from Map Styler, then upload into Map Maker as a style. That made Map Maker feel like an upgrade path rather than a restart.
What makes Map Maker meaningfully different from “just a JSON editor” is that it treats styles as managed assets: styles can be hosted online (no team-run server required), organized for reuse, and shipped via a publish pipeline rather than copy/paste handoffs.
Simplifying complex map styles
Problem: map styles are defined as large JSON files with hundreds of layers, making them difficult to understand, navigate, and edit. Even small changes require digging through deeply nested structures, increasing the risk of errors.
Solution: I abstracted complexity into three core concepts: Foundations, Map Modules, and Layers. Foundations allow users to control base colors across tens of layers via one color picker (for example all water bodies or all roads). Map Modules group related features (POIs, labels, parks) that can be toggled on or off. Layers remain available for fine-tuned control and can be rearranged.
Outcome: technical workflow became an approachable design system. Users can make broad changes quickly and dive into detail only when necessary.
Symbol system at scale
Problem: car manufacturers want to customize icons on map to align them with their brand, map style and cockpit aesthetics. But changing 700 icons including POIs (Points of Interest), road shields and traffic hazards can be a painfully tedious task. Small inconsistencies can compound quickly.
Solution: I've added icon customization to replace the standard icon set with a custom one, supporting a more coherent visual language. Workflow was intentionally designer-native: instead of building a customization tool from a ground-up, MapMaker provides a compatible Figma template, allowing to modify icons and export as SVG.
In case an OEM designer doesn't want to create the whole icon set from a ground up but just add some flavor to existing set, it's easily achievable through the template as well. With a help of Figma components it is easy to select a different variant of the POI marker between 3 sizes and 4 shape types. Or create custom shape and add apply it to the whole icon set.
This removes friction between in map implementation. Under the hood, replacement is also systematic: default icons can be replaced by uploading SVGs named after the icon ID, with batch upload support. Alternatively, one icon at a time flow is still at user's disposal.
Traffic layer simulations and rush-hour validation
Problem: traffic styling is edge-case driven: map may look fine in neutral conditions but break down under rush hour. Designers have no reliable way to validate how traffic overlays behave under peak congestion, aside from immersing themselves into a traffic jam.
Solution: I introduced traffic layer simulations, allowing to preview map styles under representative conditions. Instead of waiting for live data spikes, designers could access simulated traffic density based on historical data and validate visual hierarchy, between smooth traffic and busy hours.
Outcome: design decisions shifted from static assumptions to context-aware validation. Teams could confidently ship traffic styles that remain legible under peak load, reducing last-minute fixes.
Versioning and publishing with draft vs production
Problem: map styles were difficult to manage once they reached production. Any change risked breaking live experiences, and there was no clear way to test, compare, or validate updates before deployment. This made iteration slow and discouraged experimentation.
Solution: I introduced a versioning system with clear separation between draft and production styles. Designers can iterate safely in draft mode, compare versions side-by-side, and validate changes before publishing. Deployment becomes an explicit action, not an implicit risk.
Exact location & map pins
Map styling is a spatial task, and productivity comes down to how quickly you can connect what you see to what you can control. Scrolling and panning around a map canvas is wasted time during styling. I introduced a Map a Search feature that jumps directly to a city, address, or GPS coordinates (latitude, longitude) and ability to pin saved locations to access them later. This made styling sessions feel more like working in a modern map product.
Relevant details on map click
Problem: map styling is disconnected from context: designers see a visual element on the map but have to manually hunt through layers and controls to understand what it is and how to change it. This breaks the feedback loop and slows down iteration, especially in complex styles with many overlapping elements.
Solution: context-aware tooltip when clicking anywhere on the map. Instead of exposing raw data, it shows relevant active module content. Clicking a road highlights road-related controls, clicking on water bodies — foundation settings, showing what you both can and can't see.
Outcome: The workflow becomes direct and intuitive: interaction replaces navigation. Designers spend less time searching through panels and more time refining the map.
Beta
Further reducing obstacles for new map designers
As styling systems grow in complexity, the learning curve becomes the bottleneck. In practice, the design challenge here is trust: users must understand what changed, why, and how to refine it.
AI style generator offers map prompt-driven customization as an LLM-powered workflow where the tool interprets prompts and applies them to the map.
Сolor-vision simulation modes
Map styling is a prime accessibility risk area because meaning is often carried by color. Vision deficiency can make maps hard (or impossible) to interpret.
MapStyler introduced color-vision evaluation directly in the workflow will support of deuteranopia, protanopia and tritanopia. That enabled designers to simulate color-vision conditions while iterating so accessibility isn’t a late-stage audit step.
deuteranopia
tritanopia
achomatopsia
Ready to build something amazing together?
I'd love to connect with you.