Navigating the Design System of TomTom

TomTom creates products and services for a global market. Their solutions run on phones, tablets and custom-built hardware, and are used by millions of consumers and businesses worldwide. How do they maintain consistency with a Design System?

We were very kindly invited by Xinrong Ding, Principal Designer and DesignOps Specialist at TomTom, to take a look at the process and tooling they have in place to make sure there is a consistent user experience across the whole TomTom portfolio.

Why a design system? The design team grew fast!

At TomTom, the design team grew very fast last year. They started with 16 UX designers in 2018 but are now up to 35. A lot of new faces means sharing existing knowledge is essential. Everybody needs to be on the same page about where the company is heading.

An essential part of Xinrong’s job is to kickstart and lead DesignOps. Of course, defining and establishing the Design System is an integral part of DesignOps.

The navigation team is a nice example of the need for a reliable design system. The foundation was laid seven years ago with five Amsterdam-based designers spread across two scrum teams in London.

As of May 2019, there are seventeen designers from 8 locations working with 9 scrum teams distributed in 5 different locations. The spread of colleagues over several countries doesn’t make it easier to create and maintain a shared understanding of where the design is and is going.

And this is only about one product. Twelve other designers working with four other scrum teams. These teams will deliver two other products.

Current state Design system

Although many companies see a Design System as purely a UI-kit in Sketch or Figma, in our experience, Design Systems are a structured way of thinking about your design. It means process, tooling and a consistent design language. In practice, it means most systems consist of three different elements: UI-kits for designers, a component-library for developers and documentation that stitches everything together.
Xinrong demoed us two parts of the design-system at TomTom: the UI-kit and the documentation.

The TomTom UI-kit

The UI-kit at TomTom consists of multiple Sketch Libraries and Xinrong showed us a couple of them. We were very impressed! Fully scalable, with overrides and different styling for different products. Libraries ready to use in prototypes and new designs!

This is what I’m most proud of. The fact that we have it and USING IT!


Even though we were very impressed, the Sketch library is not yet optimal according to Xinrong. The UI-kit is more like a visual design library where all elements are presented in pixel-perfect details. It does not necessarily help audiences to understand the concept and end-to-end flow. Over time, almost all interaction designers have tried to use one or another wire-frame style themselves. “We are going to agree on one style because we want our design to look as if they are created by one designer,” says Xinrong.

A ‘wireframe only’ library also helps in communicating designs to internal stakeholders: Focus on the bigger picture by removing unnecessary details. However, what details to omit? How to simplify the design? There must be protocols, principles, and guidelines. In an organization that so many teams are involved in delivering one product, standardization is a must.

An overview of the different Sketch Libraries (up to May 2019)
An overview of the different Sketch Libraries (up to May 2019)

The road to documentation 🛣

The second part we got to see at TomTom is their impressive design-documentation. “If it’s not documented, it doesn’t exist,” and all documents are stored in a central place. A place that everyone within TomTom can access.

Xinrong shared their journey to choose the right tool and define the way of working regarding documentation.

It was truly a user-centered approach.


Seven years ago, TomTom redesigned the UI for their flagship consumer products. This was the perfect moment for designers to re-define the way we document our design. Xinrong recalled that it all started from a series of interviews to designers, developers, testers, managers, and other stakeholders who might use a design document in one way or another. Based on the user needs, they chose a new tool, confluence, and defined an entirely new way of working. Thanks to the user-centered approach, promoting Confluence and the new way of working was rather effortless. In a couple of weeks, every designer at TomTom was onboard and went ahead creating design documents in the new way using the new tool. All other stakeholders were happy to be able to always find the latest design documents in one place.

Now, after using Confluence for the seven years, TomTom UX team is still quite happy about it. So do most of the users of design documentation in confluence. Xinrong still misses some features such as versioning. Of course, over the years, they have implemented many small incremental improvements. TomTomers believe in Continuous Improvement.

TomTom’s documentation is very impressive! Information is organised in logical structure, and every design has UX-principles behind it, documenting the motivations and research behind the design. It feels very comprehensive and complete.

Confluence is where you can browse the sea of design.

Design documentation process of TomTom
Design documentation of one product in Confluence

Design System process: the next step

To keep some grip on the chaos of the ever-growing UI kit, each library has an owner. The owner is the one, and the only one should make changes or add new components. One designer can own multiple libraries. The responsibilities and rights of ownership is strictly defined and applied. Because, once anything is changed in any library, all design documents that include the changed component will be updated. It needs to be taken seriously.

When designers need to add a brand-new component, they need to first talk to the owner of the correspondent library. The owner needs to understand how to integrate the new component into the existing library framework.

This system works quite well. It not only ensures the integrity of the libraries but also promotes collaboration between designers. During the process, certainly, the owner of the library is aware of the new components. And if the new component is added into the system with a consistent naming convention and follows a strict structure, it also takes no time for other designers who make use of the library to notice the new components. Given the fact that TomTom UX team doubled the size in 2018. And the team has 34 members from 7 different locations (4 continents). Collaboration within the TomTom UX team can be a problem if no specific actions are taken.

Unfortunately, the ownership of the documentation is less centralized, and this affects quality – especially in combination with the sheer size of the documentation. Everything is linked with Jira tickets but when something is changed the links break and makes the documentation less usable. It is tough to keep everything clean when you have over 7 years of design and iterations to deal with!

If you want to create or finetune your own Design System process you should check out our custom made Proces Puzzle (Dutch) to help you out.

The future: Focus on the flow & design in a systematic way 🌊

In the future, TomTom wants to include a lot more about the creative process that happens before thinking about a solution. Define the journey from problem space to solution space. This includes setting up a library for prototyping purposes which is not yet available.

Another wish is to have good guidelines on how to do a project, for instance on prioritizing. Ideally, the Design System provides a solid framework that enables the employees at TomTom during the whole process: receive the input and requirements and go from there. This includes brainstorming.

The most important thing Xinrong learned is how important it is to learn from the people who work on and make use of the design system. And talk with them a lot! It’s crucial to set up and maintain the system in a systematic way and communication is key.

For me a design system is about tools and process. And it’s more about the people who are using the tools and following the process.


Lastly, another wish is measuring success: to help complete the design system internally at TomTom (if you also need some help with that, we’ve got an easy to use slide-deck for you)!

3 tips from TomTom

  • Think early, think big. If you need to deal with scalability sooner or later, make sure the initial framework can be used for a much larger scope. Ask these questions. What if my teams becomes twice the size? What if I have to design 5 products instead of one?
  • People-centric. The goal of creating a Design System is not the Design System. The goal is always that you want a happier design team, better collaboration with other teams, and more satisfied stakeholders and end users.
  • Start small and end big. Design System isn’t built in one day. Be patient. Don’t rush into anything that you would regret. Break down the Design System into smaller, less daunting, more workable chunks. Involve the entire team. Take baby steps. Celebrate every success doesn’t matter how small that is. Start small and end big. That’s how we do it.

We thank Xinrong for our great time at TomTom!

More about Design Systems?

If you enjoyed this blog please check out our other Design System Safari’s or check out the results of our research about the State of Design Systems in The Netherlands (in Dutch).

Curious how other organisations in the Nederlands build and maintain their Design Systems? Check out our research State of Design Systems in Nederlands, 2018.

Or visit our Meetups about Design Systems and download our tools.

Vragen over Design Systems?
Maurice denkt graag met je mee.

Maurice Timp
#designsytemlead #travellord

Wij gebruiken cookies voor de beste ervaring van de website. Tijd teveel, beklijk onze privacyverklaring