Design System for the Youlytics Portal
As the Youlytics Portal expanded to support dashboards, reporting, asset management, and collaboration workflows across the company, the product surface area grew quickly. Early UI patterns were created ad hoc to meet immediate needs, which led to inconsistencies, repeated design decisions, and slower iteration over time. To support long-term scalability and consistency, I designed and evolved a shared design system that served as foundational infrastructure for the Youlytics Portal. More images coming soon
Role
Lead Product Designer
Client
Rover
Timeline
Ongoing
Problem
As the Youlytics Portal expanded, teams struggled to design and ship new features efficiently, leading to inconsistency, and slower iteration. Two core issues emerged: - Repeated design decisions due to the lack of shared UI patterns and standards - Inconsistent components and interactions across dashboards, reporting, and asset workflows - No shared design tokens to ensure visual and structural consistency
Solution
Design and implement a shared design system that unified components, tokens, and documentation, giving design and engineering a common foundation as the portal scaled.
Approach
To address inconsistencies and improve handoff between design and engineering, I focused on establishing a shared foundation before expanding the component library. This meant defining core design tokens for color, spacing, and typography, standardizing reusable components, and documenting usage guidelines to eliminate guesswork in implementation. Rather than retrofitting patterns feature by feature, I audited existing screens to identify common structures and recurring UI decisions, then consolidated them into a scalable system. The goal was not just visual consistency, but operational alignment to ensure design and engineering were building from the same source of truth as the portal continued to grow.
Token Structure Strategy
Semantic over raw values
Rather than exposing raw colors and spacing values, tokens were structured around purpose (e.g., surface, text, border) to improve clarity and flexibility.
Layered abstraction
Tokens were organized into foundational (primitive) values and semantic aliases, allowing design updates without refactoring every component.
Engineering alignment
Naming conventions were designed to map cleanly to implementation, reducing translation overhead and preventing drift between design and code.
Determining What to Standardize
Before expanding the component library I needed to determine what should be formalized versus what should be eliminated. The portal had accumulated multiple variations of similar components with subtle spacing differences and inconsistent state applications.
Pattern Evaluation
Rather than simply standardizing everything I evaluated patterns based on frequency of use, structural soundness, and long-term scalability. Some components were consolidated into flexible primitives, some were refined, but several were intentionally deprecated. This approach ensured the design system reflected real product needs while preventing unnecessary complexity or duplication. The goal wasn’t to document the current state, it was to determine which patterns should become standardized.
Documentation & Adoption
A design system only creates value if it is usable and adopted consistently. Alongside tokens and components, I established clear documentation standards to support implementation and long-term evolution. Each component included defined usage guidelines, supported states, constraints, and examples of real product contexts. Documentation focused not just on visual specs, but on behavioral expectations ensuring interaction patterns remained predictable across dashboards and reporting workflows. To support cross-functional alignment, naming conventions and token structures were documented in a way that mapped directly to engineering implementation. This reduced interpretation overhead and minimized drift between design files and production code. By defining contribution expectations and standardizing how new components were proposed and reviewed, the system evolved intentionally rather than accumulating ad hoc variations.
Outcomes
The design system shifted the Youlytics Portal from reactive UI decisions to a shared, scalable foundation.
Operational Impact
- Faster feature iteration without redefining common patterns - Reduced duplication between design and engineering implementation - Fewer regressions caused by inconsistent component behavior - Clearer handoff through structured, shared documentation
Product Impact
- Increased interaction consistency across complex reporting workflows - Improved usability in data-dense environments through predictable patterns - Reduced visual and interaction drift as new features shipped
Organizational Impact
- Established a shared language between design and engineering - Simplified onboarding for new contributors - Enabled the portal to scale without accumulating interface debt