ROLE
Principal Designer - Design System
SKILLS
Design Systems Thinking
UI/UX Design
Accessibility & Inclusive Design
Collaboration & Cross-Team Communication
Documentation & Process Governance
Figma & Tooling Expertise
Strategy & Problem-Solving
INTRODUCTION
One Company, Many Systems—No Single Source of Truth
When PGForsta formed, it brought together multiple companies—each with its own products, design methods, and development practices. The goal? Unify everything under the HX Platform. The reality? Nothing was truly unified.
A design system was assumed to exist, but instead of a structured foundation, we found a patchwork of components built by different teams without governance—creating more friction than efficiency. But this also presented an opportunity: to audit the mess, identify misalignments, and build a scalable system that connected teams and broke silos.
UNDERSTANDING THE PROBLEM
Fragmentation, Frustration, and Workarounds
To understand what was broken, I surveyed designers, developers, and product managers. The responses exposed critical inefficiencies:
• Designers detached Figma components that didn’t meet their needs.
• Developers struggled with inconsistent code, slowing down releases.
• Teams relied on workarounds, lacking a single source of truth.
The system was meant to drive consistency but instead created unnecessary complexity.
THE AUDIT
Uncovering the Gaps: A Design System in Name Only
PGForsta technically had a design system—a code repository labeled as one. But it lacked structure, governance, and alignment between design and development. Key issues included:
• Components had no documentation.
• Every update triggered unnecessary version bumps.
• No formal contribution process existed, leading to inconsistent updates.
Rather than providing clarity, the system created inefficiencies, forcing teams to work reactively rather than systematically.
THE CHALLENGE
Breaking the Reactive Cycle
Fixing the system wasn’t just about better components—it required changing how teams worked. Key challenges included:
• Shifting from ad-hoc fixes to a structured approach with governance.
• Bridging the gap between design and development for true alignment.
• Overcoming resistance to change from teams used to workarounds.
Without clear ownership or documentation, the system had become a patchwork of short-term solutions.
THE APPROACH
The Challenges That Shaped the System
To rebuild with purpose, I focused on:
1. Aligning Design and Code as a single source of truth.
2. Establishing Governance with clear contribution processes.
3. Creating a Scalable Foundation for long-term growth.
PAIN POINTS & ROAD BLOCKS
The Reality Check
Building the system wasn’t just a technical challenge—it meant navigating shifting priorities and organizational roadblocks:
• No pilot product to validate the system in real-world use cases.
• A company rebrand that needed adaptation for product design.
• Lack of engineering leadership to drive technical adoption.
Despite these hurdles, the approach remained focused on long-term scalability.
THE RESULTS
A Structured, Scalable, and Governed System
✅ Vetted Contribution Model – Eliminated ad-hoc additions, replaced with structured processes.
✅ Organized Design Library – A systematic approach to file structure, naming, and branching.
✅ Proof of Concept (PoC) – Demonstrated value in multiple internal projects, ensuring adoption.
✅ Long-Term Governance – Preventing future fragmentation and inefficiencies.
BEYOND THE BUILD
What We Learned and Where We Go Next
• Adoption is just as important as creation—teams must actively maintain the system.
• Engineering leadership must be involved early to ensure long-term integration.
• A great design system is never “finished”—it evolves to meet future needs.