I joined Fluidra, a global leader in pool and wellness automation in 2023, where the company specializes in innovative IoT-enabled products, operating in over 45 countries. After taking UX ownership of the consumer-facing app, I was entrusted with leading the creation of a scalable design system to support design teams distributed across USA, India, Spain, and Colombia. This role enabled me to establish design standards and unify user experiences across Fluidra’s international product lines.
Side Note -
I started posting my thoughts on LinkedIn about tackling the challenges and learning curves of designing a scalable design system in my new role, I was genuinely surprised to receive a connection request from Jakob Nielsen, the legendary usability expert and pioneer in the field of UX 😮
a true fan moment!
In the connected pool industry, users interact across dramatically different environments, from a backyard in direct sunlight to a desktop dashboard in an office.
I designed a unified experience across four distinct touchpoints:
- a mobile app for on-the-go control.
- a desktop application customer experience dashboard for deeper management.
- an 8-inch outdoor LCD built for pool technicians to configure pool equipments.
Each surface served a different user, context, and need. But all had to feel like one coherent product.
- Audited the existing system end-to-end, cataloging every component, eliminating redundancies, and documenting inconsistencies in visual language and UX breakdowns.
- Consulted stakeholders to align on constraints and priorities, while analyzing end-user pain points to ground every decision in real behavior.
- Assessed platform screen resolutions and established core design foundations, setting the stage for a scalable, cross-functional build.
My reaction when I saw the broken design components
Let's talk about the Screen Resolutions
Fluidra's ecosystem spans four distinct surfaces, each serving a different user and context.
- Homeowners manage their pool from an IHD tablet at home or the Fluidra Pool mobile app on the go.
- Field technicians configure systems directly on the ICD (In-Can Display)
- While advanced maintenance and pro-level operations are handled through the Fluidra Pro app.
- Internal teams monitor it all through a CX Dashboard, providing real-time visibility into equipment status and user data to proactively identify issues and keep the experience running smoothly.
Every use case lives on a different device, resolution, and environment. Making cross-surface consistency a core design challenge, not an afterthought.
.png)
Accessibility
Accessibility was a core pillar from day one, not a post-launch consideration. Given that several surfaces would be used outdoors in direct sunlight, I followed OS guidelines rigorously enforcing proper color contrast ratios, native typography, and optimized touch targets across every component.
The goal was an experience that remains clear, usable, and inclusive regardless of environment or condition.
A field visit to understand the system from the ground up
Developers lets talk
As the product scaled, UI inconsistencies compounded fast. Handoffs required constant clarification, visual bugs surfaced late in QA, and developers were left interpreting design intent without a reliable system to reference. Minor friction had become a delivery bottleneck and a threat to design consistency at scale.
Screens are final QA/ Pre-release
Architecture Decision
Before committing to a direction, I immersed myself in discovery, conducting a field visit to observe how the system operated in the real world, and aligning with developers to surface implementation gaps and handoff friction. With those insights grounded in reality, I researched how leading companies structure their design systems. After synthesizing findings and aligning with my Director of UX, we chose a three-tier architecture, a modular foundation built for scale, consistency, and long-term maintainability.
Analyzing gaps in the Design System with my colleague
Component-First Design, Not Page Design
Instead of designing static pages, I designed Fluidra Design Language that scale across products, platforms, and teams.
A page solves a moment.
A component solves many moments.
Design System New Architecture
Why Three-Tier Archirecture?
A three-tier design system is especially valuable in contexts like Fluidra, where multiple standalone products serve different audiences while sharing a common foundation. By separating the system into primitive, semantic, and component layers, teams can maintain consistency without sacrificing flexibility. The primitive layer defines core design tokens such as colors, typography, and spacing, while the semantic layer maps those primitives to meaningful roles (e.g., primary button, success state), creating a stable and reusable foundation across all products. The component layer then allows for platform specific customization, enabling each product to adapt its look and feel, such as distinct color schemes or styles without breaking the underlying system. This structure improves efficiency by reducing duplication, simplifying maintenance, and making it easier to scale or update designs globally while still supporting product level differentiation.
Primitive Tokens Layer
Sementic Tokens Layer
Component Tokens Layer
What to keep in mind when creating a Design Token?
1. Set a naming convention
A practical naming convention to start with is: category.usage.component.vari
ant
Category: Defines the type of design attribute (e.g., colors, typography, shadows, spacing, border-radius).
Usage: Indicates where or how the token is applied (e.g., text, background, icon, border, body, heading).
Component: Specifies the UI element it relates to (e.g., input, button, segmented control, checkbox, tab, link).
Variant: Captures different states or sizes when applicable (e.g., active, disabled, inactive, hover, focus, xl, l, m, s). Not all tokens require variants, and that’s perfectly fine.
2. Provide as much context as possible
Don’t worry if a token name becomes long, clarity matters more than brevity. Include enough detail to clearly describe its purpose and usage. These names aren’t visible to end users. They’re primarily for developers to understand and manage design decisions.
For example: $colors.background.button.
.primary.hover
3. Use modes for platform variations in Figma
Use modes in Figma to handle platform differences without duplicating tokens. You can define variations (iOS, Android, web) while keeping the same token structure. This keeps things consistent, easier to update, and avoids multiple sources of truth.
4. Use Figma MCP / Code Connect for easier dev handoff
Use Figma MCP and Code Connect to streamline the handoff between design and development. They help map design tokens and components directly to code, making specs clearer and reducing guesswork. This improves consistency, speeds up implementation, and minimizes back-and-forth between designers and developers.
Final Thoughts
The human mind doesn’t naturally interpret scattered strings of code and token names the way a machine does. So if we design with empathy for users, why not extend that same thinking to ourselves as designers and developers? A well-structured design system does exactly that. It’s not just a single concept, but a layered approach likeprimitives, semantic structure, naming conventions, and tooling. All built on top of each other to create something more intuitive, scalable, and ultimately more human.
Outcomes
