aTOMIS • Design System
Concept / Exploration • Not in production
TIMELINE
Feb 2026 -Mar 2026
MY ROLE
Product Designer
Overview
This project is a self-initiated exploration to test how a design system can be structured for scalability across brands and themes.
Instead of solving a single product problem, the focus was on building a flexible foundation, validating how layers like tokens, semantics, and components can work together.
The goal was to explore a system architecture that could scale even before being applied to a real product.
Why this system
As the product scaled, UI consistency started breaking across screens and teams. Similar components were being recreated with slight variations, and adapting the interface for new brands or themes required manual redesign.
The real problem wasn't just inconsistency, it was tight coupling between design decisions and components, making the system rigid and hard to scale.
The goal was to decouple decisions (color, type, spacing) from components so the same structure could adapt across contexts without redesign.
System Architecture
The system is structured as layered abstractions. Each layer handles a specific concern, from raw values to semantic meaning to final UI application.
Instead of designing components directly, decisions are first defined in foundational layers and then composed into reusable structures.
This separation allows the system to scale across brands, themes, and future requirements without breaking existing components.
Chromatics (Color System)
Chromatics is structured into three layers to separate raw values, semantic meaning, and UI application.
Particles store raw color values (e.g., hex scales). Signals assign meaning such as primary, neutral, success and hold variations across brands and modes. Bindings map these meanings to core UI roles.
Instead of component-specific tokens (like "button-blue"), bindings are defined around fundamental UI surfaces: surface, text, border, and icons.
This reduces token complexity and ensures every component derives color consistently from a shared set of roles while supporting both brand themes and light/dark modes at the binding level.
Lexemes (Typography)
Lexemes define the typographic language of the system including hierarchy, scale, and usage roles.
Instead of fixed styles, typography is structured to maintain readability and consistency across different layouts and contexts.
Fields (Layout & Spacing)
Fields define the spatial system including grid structure, spacing scale, and layout behavior.
By standardizing spacing and alignment, the system ensures visual rhythm and consistency across screens.
Glyphs (Icon System)
Glyphs form a centralized icon system designed for consistency across the product.
The icon library is not only defined in design but also implemented as a coded system ensuring a single source of truth between design and development.
This reduces inconsistencies in usage and allows icons to scale seamlessly across platforms and contexts.
Icon System in Production
Structures (Components)
Components are built by combining all foundational layers making them reusable, consistent, and theme-aware.
Instead of defining styles locally, components inherit tokens, typography, and spacing automatically.
This ensures that any change at the system level propagates across all components without manual updates.
Components inherit tokens, spacing, and typography ensuring consistency by default
How it behaves
Spacing and structure are not random they follow system rules
Outcome
This system demonstrates how separating tokens, semantics, and structure can enable scalable UI across brands and themes.
While not yet applied in a production environment, the approach validates how design decisions can be abstracted and reused effectively.
Limitations & Next Steps
As this is an exploratory system, it has not yet been tested in a live product environment or across real team workflows. The next step would be applying this system to an actual product validating scalability, developer adoption, and long-term maintainability.
Same screen, Same tokens, different modes → different outputs
The key outcome is a flexible system foundation that can be extended, implemented, and adapted in real-world products.
