Dotti design system
Dotti
How a scalable design system and token-based approach created clarity, consistency, and speed within our portal.
Company • Pelion
Role • Product designer
Team • Design, dev
The challenge
Across the portal small differences began to appear. Buttons that looked almost alike, colours just a few shades off, layouts that didn’t quite follow the same rhythm. On their own, these variations seemed minor but together they made the experience feel fragmented and harder to maintain.
We needed a scalable system that could keep design, development, and brand aligned as well as speed up feature development. It needed to reduce friction, prevent design from becoming a bottleneck and maintain consistency while allowing flexibility for future growth.
Shared language
Consistency
Speed
Scalability
Clarity
Collaboration
About Dotti
I co-built our design system Dotti, shaping how design and development collaborate across the portal. It became our single source of truth, unifying the visual language, speeding up delivery, and keeping the experience consistent.
The Pelion brand was built around dots and flowing lines, representing connection, movement, and effortlessness. In the IoT space, where connecting multiple devices can get complex, this visual language reflected our mission. Building on that foundation, Dotti was born, a system designed to bring the same sense of connection and clarity to how we design, build and scale our portal.
Dotti design system guide
Design tokens
When building Dotti, we looked closely at established systems like 'Material Design' and 'Salesforce Lightning'. Both offered comprehensive token frameworks but they were too large and complex for our team to maintain. We wanted something scalable and a system we could easily maintain and expand as our portal evolved.
We started by researching best practices and identifying which token types made sense for our product and testing them out with our own components.
Design token research
We implemented a two-tier design token approach, focusing on primitives and semantic tokens. Component tokens were utilised only when absolutely necessary, for example when a component had a unique or complex style. This approach was strategic, keeping the system maintainable and scalable while still allowing flexibility for exceptions.
Primative tokens
Foundational values such as colour, typography, spacing and radius.
Semantic tokens
Meaning-based values like success and error, mapped directly to primitives.
Component tokens
When a component requires unique or complex styling not shared elsewhere.
First we mapped out colour tokens in our documentation, defining both primitives and semantic values to ensure a solid foundation before moving on to other token types. We planned ahead for future theming, including light and dark modes and the possibility of custom user themes.
Semantic tokens mapped to primatives
Semantic tokens mapped to components
Once the structure was finalised, these tokens were implemented in Figma Variables and linked directly to Storybook. This made the design system tangible, consistent, and easy to use across design and development. By tailoring the token system to fit our workflow, we were able to create a scalable foundation that balances structure with flexibility.
Figma variables
Iconography
Dotti’s icons are bespoke and optimised for screen usage. Where possible, all line work sits on solid pixels, ensuring the highest quality rendering on any device. We use a geometric grid to guide form and sizing with standard icons at 20x20 pixels and smaller icons at 16x16 pixels to maintain a consistent style across the portal.
We also utilise filled icons for elements like status labels and key indicators, helping them stand out and communicate meaning clearly.
Pelion icons
Components
Components are the atomic building blocks of the Pelion platform UI. Our library documents the styles and behaviours for every button, container, modal, and more.
Each component includes defined variants and states, such as hover, active, and disabled, ensuring consistent behaviour across the portal. Components are responsive by design, adapting seamlessly across devices and screen sizes.
Our components are highly reusable, enabling teams to maintain consistency while speeding up development and iteration. Where needed, we restyle third-party components to match our design system while retaining their built-in functionality.
Component documentation
Component selection
Developer handoff
Once the foundational design work was complete, we worked closely with developers to bring the system to life in Storybook. This became our shared environment for testing components, refining behaviours, and aligning on implementation details.
Through regular reviews and feedback loops, we ensured every component matched the design intent, performed consistently, and could scale across the product. This close collaboration kept design and development tightly aligned, reducing friction and creating a more efficient workflow.
Storybook
Learnings
Building Dotti showed just how valuable a well-structured design system can be. We built a library of reusable components, improved collaboration between design and development, and made feature delivery faster and more consistent.
As our product evolved, we recognised the need for greater speed and flexibility. While Dotti provided a strong foundation, the deprecation of Vue 2 framework introduced technical limitations that made future scaling more difficult.
We’re now transitioning to another framework, updating components and design tokens with our own styles and structure. This move will make the system even more scalable and maintainable, carrying forward everything we learned from Dotti into a more future-ready framework.