TomTom Documentation Website
Enhancing a technical buyer journey of the world-leading location tech company
TomTom, headquartered in Amsterdam, specializes in geolocation software, collaborating with companies such as Uber and Volvo to deliver high-quality mapping and navigation experiences. With a strong focus on a product-led business model, the company aims to reduce reliance on manual, project-based services by shifting toward scalable digital solutions.
& Designer

Background
As part of the initiatives for the scalable digital solutions, TomTom recently has been laying a strong focus on online platforms such as marketing or documentation websites, that showcase the product offerings, enabling customers to discover, evaluate, and integrate products more efficiently.
Problem
The existing documentation website is outdated and difficult to navigate due to the large scale of the product portfolio. The team saw an opportunity to improve the first-time experience for potential and onboarding customers by addressing these problems.
Target Group
Product managers were included in the research as a target group alongside developers. Although PMs are commonly not primary users of the documentation website, prior research shows that they use it as a resource during the pre-purchase evaluation stage.

How I empathized with users
The research consisted of in-depth interviews with 5 developers and 5 product managers, with a range of experience and knowledge levels in location technology, from low to high. Usability testings were used during the research to understand their needs and pain points when using TomTom's documentation website as a first-time visitors.
Key findings on how and why users struggle
Below is the 4 key insights extracted from the research. For more information, please check out the

The current documentation site does not answer the key question first-time visitors have: “Which products do I need to solve my problem?” While users are presented with a wide range of product offerings, the connections between them are unclear. As a result, users struggle to narrow their focus to a relevant set of products and can easily feel overwhelmed or lost.

First-time visitors percieve current docs website as a ‘high-level glossary’ of product specifications for those who are already familiar with TomTom products. At this stage in their journey, they want to get a clearer sense of what the products are and how they fit together, rather than jumping straight into detailed “how-to” usage guidance.

Heavy use of industry-specific jargon further increases the difficulty for those who are not familiar with geolocation technologies. Users specifically noted the absence or low discoverability of resources such as starter guides, demos, and blog, which negatively impacts their ability to get oriented.

Technical users strongly prefer learning by doing. Long blocks of text in the documentation require too much time and effort; they would rather dive in, experiment with code, explore product functionalities, and see firsthand what the outcomes would look like.






Ideation
Through co-creative sessions and brainstorming, key design directions were defined. These were visualized in wireframes and iterated multiple times through design critiques with the team and stakeholders.












What do users think and feel?
Here is a simple visualization of what users think and feel while going through the pain points and how it would change with the new design ideas. Click each card to compare what the user journey is like before and after!
Flow Chart
Current flow is only allowing a linear flow as an option for users, making them go through every single pages to get to the information they need.

New flow would provide users more flexible and multi-entry exploration allowing them to find what they want at any stage of the journey.

Homepage as a central hub for the navigation
As a result of aligning on design direction, the team and I identified the homepage as the most crucial and urgent touchpoint to improve and test. It went through multiple iterations based on testing and feedback, and below are the final designs for each section.

A refreshed menu bar enables visitors to quickly discover and access key resources such as the API Explorer, demos, and blog. Highlighting an interactive demo snippet in the hero section adds dynamic visuals while sparking visitor interest.
An updated product section that helps visitors quickly grasp product use cases by product group through clear mockup imagery of final outputs, while providing flexible viewing options tailored to their preferences—reducing the overwhelm caused by long product lists and excessive scrolling that lead to visual overload.

The bottom section of the page enables users to discover additional content and resources to further explore the products, such as clearly presented success story cards and direct access to the API Explorer.
Does new design actually work?
As the project timeline was wrapping up, it was time to present the final design to broader stakeholders and move toward building the MVP. In the final testing session, I focused on validating that the new homepage design actually addressed the pain points we’d uncovered in the discovery research. I approached this by setting up success criteria aligned with the key metrics we had tracked earlier and then comparing the results.
Wheares only 2 out of 10 participants were able to complete the task of locating specific links or content, 8 out of 10 were able to do so with the new design.
The time required to complete all tasks decreased from 11 minutes to 6 minutes, showing a significant improvement.
The Likert scale rating (1 = highly negative, 5 = highly positive) measured participants' first impression on the site. It also increased, with an average score of 4.7.
The rating question (1 = very difficult to find, 5 = very easy to find) measured how easily users felt they could locate information while completing tasks. The average score highly improved from 1.8 to 4.7.
Concepts like the Get Started page, Solution Finder, and AI search assistant were tested through visible CTAs such as buttons and links. Even in this lightweight form, they sparked the intended reactions such as curiosity, a sense of liveliness, and a more welcoming experience for first-time users.
Things for the future
Although the relevant CTAs was validated in final testing and showed strong potential, the page designs weren’t included in the testing or MVP due to bandwidth constraints at scale. Encouraged by the team, I continued developing them into full high-fidelity prototypes and shared them as visionary proposals.

Intuitive and guided starting point
Users feel lost and often have difficulty orienting themselves when they first land on the documentation homepage due to the lack of a clear starting point.
The Get Started page provides a guided experience with curated starter resources, helping users quickly understand product offerings and feel confident in their first steps.
Problem-Led Product Exploration
During the discovery phase, users come to the site with a specific problem to solve, not with predefined products in mind.
The Solution Finder is a dedicated tool that helps first-time users quickly understand the available products, what they can build with them, what to expect, and what is required, by presenting this information through preselected popular use cases.
Smart Discovery Assistant, Tommy
First-time users have many questions, and finding answers by reading through documentation takes significant time and effort. The existing search and AI chatbot see low adoption and provide limited support during early exploration.
A search experience with an integrated AI assistant creates a seamless early-learning journey. By surfacing preselected, well-timed prompts, it sparks curiosity and helps users ask the right questions at the right moment, making exploration intuitive and engaging.
Wrapping up
Based on the final testing and a few more discussions with stakeholders, the MVP design was createdThen I supported the development team during implementation by adjusting the UI to better align with the existing component library.
What I learned from working at a big tech corporate
Platform ecosystems are trickier than they seem! : When working on a single product that’s part of a bigger system, it really helps to have a point of contact for each platform and some key metrics to see how everything connects and affects the project.
Legacy matters. Especially on platforms like developer portals or documentation sites. Some areas may be out of UX’s reach, often becoming outdated or overlooked. Even so, it’s important to address these issues and be proactive about speaking up.
What I learned from working with mature UX team and various stakeholders
It’s important to pitch ideas clearly, but also adapt them depending on the audience. Some people want to hear how the solution helps users, others care about how it makes the business stand out. The key is to be prepared and flexible, and make the case from all angles.
Always be ready for the “why” questions. Why is this change important? How does it really help users? Implementation taks time and resources, so the team needs to be convinced that the update will create a real impact and tangible value.
Research Archive
Discovery Research
Methodology
I conducted a qualitative study over a 3-week period to understand the early stage of technical buyer journey for TomTom's documentation website.
- 10 in-depth interviews (60 mins each)
- Participants: 5 Developers, 5 Product Managers
- Location: Online, Europe and UK
- Platform: UserTesting.com
- Structured interview quesions and scenario and task-based usability testing on the existing portal
Key Detailed Metrics
Key Pain Points
"Search bar is prominent; I am surprised this is the first thing they have. I'll skip it for now"

Page analytics indicates that the section was exposed to 99% of the first-time visitors, while only 6% of them clicked on it. It implies that the search bar does not work as a primary tool for a navigation for first time users.
"API Explorer is 'hidden' whereas I would like to see it first."

"I think right now, It's a little bit harder to sort of see that connection (between products) right off the bat, because you're almost overwhelmed at this point."

"I think testimonials always adds a little bit more validation, especially if you're trying to convince another team or your own team."

Despite the existence of entry to testimonials (by clicking the company icons), none of the participants noticed.
"It's quite long... it's not ideal, I would rather go to the API explorer to look a bit deeper into it"

Key Target Audience Needs
Contextual Information
Educational Contents
Sandbox
Step-by-step Guides
Confidence
Insightful User Behavior
Keyword Search

Limited Scroll
Artifacts
- FILEResearch Protocol.pdf
- FILEInterview Transcripts.zip
- FILEUser Flow Diagrams.fig
Evaluation Research
Methodology
I conducted a usability test comparing the old and new designs, measuring several qualitative and quantitative metrics.
- 10 unmoderated online testing session (15 questions each)
- Participants: 10 developers or product managers. old design n=5, new design n=5.
- Location: Online, Europe and UK
- Platform: UserTesting.com
- Structured quesions, scenario-based task and rating scales.














