Service
Product Design
Product Architecture
Design System
Year
2026
Client
NDA
My Role
Principal Product Designer
Product & Design System Architect
Project
Case in progress
Building a scalable product experience architecture across a multi-platform B2B SaaS ecosystem.
The product ecosystem included four interconnected surfaces: marketing website, web platform, mobile app, and desktop app. As the system grew, interface decisions, brand foundations, product patterns, and delivery workflows needed a clearer shared structure.
My work focused on connecting brand, design system architecture, product patterns, and design-to-development alignment into a more scalable operating model for teams working across the ecosystem.
This was not a UI Kit project. It was an interface and knowledge architecture effort designed to bring consistency, scalability, and decision-making structure to a complex product ecosystem.
Why the system needed architecture
The product was not a single interface. It was a growing ecosystem of connected surfaces, teams, domains, and delivery workflows.
Across the marketing website, web platform, mobile app, and desktop app, teams were solving similar interface problems in different ways. Over time, this created duplicated decisions, inconsistent patterns, and a growing gap between brand, design, documentation, and implementation.
The challenge was not only to make the UI more consistent, but to create a shared model for how product experience decisions should scale across platforms and teams.
Key challenges
Fragmented visual language across platforms
Design-to-development disconnect
Lack of shared scalability rules
Fragmented component and pattern usage
Before-state: fragmented decisions across platforms
Before the architecture work, each product surface had its own partial structure. Some platforms had UI styles and documentation, others relied on local decisions, legacy patterns, or team-specific conventions.
The main issue was not that components were missing. The deeper issue was that design decisions were not connected into one shared system. Similar patterns, states, content rules, and implementation expectations could differ across platforms and teams.
This created a growing mismatch between design intent and development reality.
Product Operating Model
To make the system scalable, I worked on a broader product operating model — a shared structure for how strategy, brand, design system, product patterns, marketing, and delivery should connect across the company.
The goal was to move away from scattered documentation and team-specific decisions toward a single knowledge system where brand foundations, interface architecture, product rules, and delivery workflows could be understood as parts of one ecosystem.
This operating model helped define where decisions live, how they influence product experience, and how teams should use the system when designing, documenting, and shipping work.
Layered design system architecture
To bring clarity and scalability to the interface, I introduced a layered design system architecture separating foundations, reusable components, interaction patterns, product modules, templates, and local components.
The goal was to make the system easier to reason about. Teams needed to understand which decisions belonged to the global system, which belonged to a product domain, and which should remain local until reuse was proven.
This structure helped define how interface elements should be created, reused, documented, evolved, and eventually promoted into the system across multiple platforms.
Foundations and token taxonomy
A scalable product system needed a stronger foundation layer. I structured foundational decisions around reusable design tokens, separating primitive values from semantic usage and component-level decisions.
This helped reduce ambiguity between visual identity, product UI, and implementation. Instead of treating color, typography, spacing, and states as isolated design choices, the system defined how these decisions should be named, reused, and translated across platforms.
From components to product patterns
One of the key architectural decisions was to separate reusable UI components from reusable interaction patterns.
Components define interface building blocks. Patterns define how product scenarios behave: what should happen in empty states, search results, validation flows, permissions, navigation, and other recurring moments across the product.
This distinction helped teams stop treating every repeated layout as a component and start documenting product logic, content rules, dependencies, and expected behaviour as reusable system knowledge.
Connecting design decisions to implementation
The architecture was implemented through a workflow connecting design libraries, documentation, Storybook, and product implementation.
Designers worked with system components and documented patterns in Figma, while developers relied on synchronized Storybook components and implementation guidelines. Documentation connected the two sides by defining usage rules, interaction logic, states, and product-specific constraints.
The goal was to make design decisions traceable — from system foundations to product screens and from product screens back to reusable system rules.
Key architectural decisions
Rebuilt the component system from scratch
The system was restructured to reduce legacy inconsistencies and create a cleaner foundation for future redesign.
Synchronized design components with Storybook implementation
Design and development references were aligned to reduce handoff ambiguity and implementation drift.
Separated reusable components from interaction patterns
Components handled UI structure, while patterns documented recurring product logic and behaviour.
Introduced structured documentation for components and patterns
Usage rules, states, constraints, and examples became part of the system, not scattered team knowledge.
Defined a new workflow for designers aligned with system architecture
Designers could work through the system layers rather than reinventing local decisions.
Introduced AI-assisted UI generation
The structured system created a foundation for AI-assisted UI generation based on existing components, patterns, and constraints.
After-state: a scalable foundation for product experience
The result was a clearer system for designing, documenting, and scaling product experience across platforms.
The work established a more consistent visual language, improved alignment between design and engineering, reduced interface inconsistencies, and created a stronger foundation for future product redesign.
Most importantly, the system gave teams a shared model for decision-making — helping them understand when to reuse existing components, when to apply patterns, when to create local solutions, and when to promote decisions back into the system.
← Back to Index
or look for the latest projects
