What I Learned

Constraints Can Drive Innovation

This project taught me that sometimes the most creative solutions emerge from limitations. While I would have preferred refactoring the codebase, working within PrimeNG's constraints forced us to think differently about what "better" could mean.

CDS, for all its strengths as PTC's company-wide standard, had gaps: limited micro-interaction thinking, baseline accessibility compliance, and sparse usage documentation. These weren't priorities when CDS was built, but they became our opportunities.

By focusing on three areas where we could excel despite (or because of) our constraints:

• Micro-interactions: PrimeNG's component library offered rich interaction capabilities that CDS couldn't easily support. We documented hover states, loading behaviors, transition timing, and feedback mechanisms that made the UI feel more responsive and polished. This attention to detail elevated the perceived quality beyond what CDS delivered.

• Accessibility: Rather than treating WCAG compliance as a checkbox, we made it a differentiator. PrimeNG's foundation gave us keyboard navigation, screen reader support, and focus management out of the box, but we extended it with comprehensive testing protocols and clear accessibility guidelines. Our system became more accessible than CDS.

• Usage guidelines: Where CDS provided component specs, we provided component wisdom. When to use which variant. How to handle edge cases. What not to do. Real examples from our product. This documentation became invaluable for developers and designers alike, reducing decision fatigue and improving consistency.

These advantages wouldn't have been priorities if we'd simply adopted CDS. The constraint of duplication forced us to find ways to add value, and we discovered that polish, accessibility, and documentation were aspects we could improve on with low effort, thanks to the considerations made with PrimeNG.

The Figma Dev Mode approach (turning developer experience into our primary value proposition) emerged from this same constraint-driven thinking. We couldn't compete on "better architecture," so we competed on "better workflow." That insight might not have surfaced in a less constrained environment.

Pragmatism Has Its Place

Enterprise software development often requires balancing ideal solutions with organizational reality. Technical debt, resource constraints, and business timelines are real. As a design leader, my job isn't just to advocate for the perfect solution. It's to identify the best path forward given actual constraints, while still pushing for long-term improvements.

Bottom-Up Change Works

Winning over individual developers proved more effective than trying to convince management first. When developers experienced the benefits firsthand and championed the system upward, we achieved buy-in that top-down mandates never could have.

Leadership Means Getting Specific

Servant leadership doesn't mean staying high-level. Sometimes the most valuable thing a leader can do is dive into component-level critiques in Figma or pick up implementation tasks when the team is stretched thin. Being willing to work at any altitude builds trust and keeps projects moving.

What I'd Do Differently

If I could start over, I would have advocated more forcefully at the beginning for a hybrid approach: refactor and use CDS for high-impact areas (like primary workflows), while using PrimeNG only for lower-priority features. The all-or-nothing decision (full duplication vs. full refactor) created a false choice that likely wasn't necessary.

I'd also push harder for dedicated developer resources earlier, rather than treating this as "extra work" on top of feature development. The half-committed approach extended timelines and added stress.