Stella UI

A clean, intuitive website designed to enhance patient experience. Seamless navigation, calming aesthetics, and a user-focused approachwhere healthcare meets great design.

Client

TRANE TECHNOLOGIES

Category

Services

WEB DESIGN, UI/UX DESIGN

Year

2025

Trane Technologies has 50+ digital products with disparate design systems and inconsistent UI.

I designed and launched Stella – a unified token-first design system that became the common foundation for Commercial and Residential products. The system is built around tokens and shared component libraries to support different interfaces without duplicating design.

After the launch of Stella, teams stopped building components from scratch, design files became structured and consistent, and collaboration between designers and developers was simplified thanks to a shared system of tokens and documentation.

Stella Design System — Overview

Working on multiple products inside Trane Technologies quickly exposed a pattern.

The problem wasn’t the lack of UI components — it was the lack of shared decisions.


Different teams solved the same problems in different ways. Identical flows were built using different components, spacing rules, and interaction patterns. In some cases, the same feature within a single product relied on multiple conflicting UI libraries, depending on when and by whom it was implemented.


Designers made reasonable local decisions, but globally the system drifted.

Buttons with different radii lived next to each other. Similar forms behaved differently across screens. Spacing and typography rules changed from feature to feature, even when the user journey remained the same.


This inconsistency wasn’t intentional — it was structural.


There was no common foundation to align on. No shared language for design decisions. As a result, design reviews often focused on fixing visual discrepancies rather than discussing product intent, and engineering teams had to account for design variability that shouldn’t have existed in the first place.


Over time, it became clear that the issue could not be solved by adding more components or enforcing stricter reviews. The problem required a system-level solution - one that would standardize decisions without removing flexibility.

That realization shaped the direction of Stella.

Impact

After Stella was introduced, its impact showed up less in presentations and more in everyday work:

  • Teams stopped rebuilding basic UI from scratch. New flows now start from Stella Global components instead of ad‑hoc local libraries.

  • New designers onboard faster because every product starts from the same file structure, token set, and component system. They spend their first weeks solving product problems, not reconstructing design foundations.

  • Designers and engineers work off the same token layer, which turned design–implementation drift into an exception instead of the default. When something changes, it’s updated once at the token level — not patched across individual screens.

  • Design reviews shifted away from debating spacing, radii, and colors, and toward product intent and interaction patterns, because those visual decisions are now encoded in the system.

  • For new initiatives, the question is no longer “which library are we using?” — work simply starts in Stella.

Token-First Architecture

In Trane, the core problem wasn’t how components looked — it was how decisions were made.
Each team picked its own colors, spacing, states, and patterns. Even inside a single product, the same UI problem could be solved three different ways, simply because there was no shared layer of decisions.


In Stella, that layer became explicit.


If you want to control design at a company scale, you don’t control individual components — you control the values they use.

From day one, Stella was designed as a token-first system. Tokens weren’t an optimization added later; they were the goal.
Color, typography, spacing, states, and layout all live above the UI. Components don’t “decide” how they look — they just read from tokens.


In practice, this means:

  • designers never apply raw colors or spacing directly; they choose semantic tokens with a defined role,

  • the same state (for example, a primary button hover) is defined once at the token level, not reimplemented inside every component,

  • changes happen in one place and flow through the system, instead of being patched screen by screen.


Architecturally, Stella doesn’t have “half-tokenized” components. Inside the system, nothing lives outside the token layer.
Legacy patterns stayed in products for a while, and migration was gradual, but the system itself relied on tokens from the start.

This doesn’t remove complexity — it still exists.


What changes is where it lives: instead of being smeared across hundreds of files and local libraries, complexity is concentrated in a single, intentional layer where it can actually be managed and evolved.

File & System Organization

Stella was structured to support dozens of products with different goals, while avoiding fragmentation and system bloat.

The system is divided into three layers: Stella Global, Stella Commercial, and Stella Residential.


Stella Global contains the shared foundation — components and patterns used across all products. Around 90–95% of the system lives here, ensuring consistency and reuse.


Direction-specific libraries contain components that are shared across multiple products within the same direction, but are not relevant outside of it. This prevents the global system from turning into a dumping ground while still enabling reuse at scale.

.

All layers are built on top of the same token foundation, which guarantees consistency even when UI patterns differ.
This structure allows controlled variation without fragmentation, keeping the system scalable, navigable, and easy to maintain.

Beyond UI Components

Stella was designed as a complete design workspace, not just a UI component library.


Beyond core UI components, the system includes a wide range of built-in add-ons and supporting assets that designers use daily: brand logos, social and integration icons, file type icons, payment methods, flags, emojis, cursors, and utility elements such as spacing and measurement guides.


All of these assets are pre-integrated into the system, following the same structural and naming principles. Designers don’t need to search external libraries, download icon packs, or recreate common assets — everything is already available, consistent, and ready to use.


This approach significantly reduces friction, speeds up design work, and ensures that the design system feels complete, practical, and immediately usable from the first interaction.

Component System

Stella’s component system is designed to handle real product complexity without turning into an unmanageable set of one-off patterns.


At the core of the system is a focused set of base components. Each one is built to scale through states, variants, and composition rather than through endless duplication. Instead of creating a new component for every slightly different use case, Stella relies on a clear structure of base pieces that can be combined and extended in predictable ways.


Components are not treated as static UI blocks. Each one follows a declarative, override-based structure, inspired by systems like Mantine: core properties such as radius, background, border, padding, and layout are defined once, while visual and behavioral differences (hover, active, disabled, focus, contextual variants) are applied through controlled overrides.


This keeps the system flexible without making it chaotic. Designers can express different product needs, but they do it within a shared set of rules and constraints. As a result, new work tends to reinforce the system instead of forking away from it.


Every component is tied directly to the token layer. That connection prevents visual drift over time: when tokens evolve, components inherit those changes by design, and product teams don’t have to manually chase inconsistencies across screens or libraries.

Documentation & Knowledge System

Stella was designed with documentation as a first-class part of the system, not as an afterthought.


Every component is fully documented — not only how it looks, but how and why it should be used. Documentation covers usage principles, interaction behavior, edge cases, and decision rationale, ensuring that components are applied consistently across products.


However, Stella documentation goes far beyond components.


The system includes extensive guidance on content, communication, and decision-making: how interfaces should speak to users, how copy is structured, what patterns to avoid, and why certain design decisions were made. This turns the design system into a shared reference point, not just a UI library.


Documentation also plays a key role in education and enablement. Stella supports designers at different levels of experience, providing practical guidance, best practices, and internal training materials. This includes design principles, workflow recommendations, and patterns that help designers grow while staying aligned with the system.


By documenting not only what to use, but how to think and why decisions exist, Stella reduces ambiguity, accelerates onboarding, and creates a common understanding across teams.

Final Reflection

Stella is an ongoing system, not a finished artifact.


I continue actively evolving the design system — shipping updates, refining architecture, and improving documentation based on real usage and feedback. Stella has become one of the most meaningful and impactful products I’ve worked on, and I take genuine pride in owning and maintaining it.


The feedback from designers and developers has been consistently strong. The system significantly improved design consistency, development speed, and product delivery quality across teams. More importantly, it raised the overall standard of how design and engineering collaborate inside the organization.


As the system owner, I see Stella not just as a design system, but as a long-term investment in product quality, scalability, and shared understanding. Seeing it actively used, trusted, and expanded across the company is what makes this work especially rewarding.