Build the product around the component library
Spark Island was an early custom React design system when I joined Intel. I was hired to develop it further and eventually took ownership of the product roadmap.
The team expanded the component library and set stronger accessibility and design standards. I established the documentation and supported adoption through designer onboarding, office hours, webinars, training, and outreach.
Verified delivery by Q3 2023
- 34 production-ready React components
- An Angular proof-of-concept library
- An accessibility validation process
- New components achieving Fable AUS scores of at least 75
- Contributions from consuming teams released into the production library
- Automated icon asset generation
Plan UX, development, and documentation together
I organized the roadmap around three ongoing areas of work: UX, development, and documentation.
I set OKRs for each area and created a research roadmap. We did not have consistent access to research resources, so the research plan was not completed as intended. I owned the documentation in addition to the roadmap and design work.
Development capacity was limited. My manager provided a budget that we extended by hiring two contractors in Poland to support Angular. The existing developer remained focused on React. I also began using AI to build supporting tools and automate repetitive work.
Choose a shared library that fits Intel products
Intel teams needed React, Angular, and CSS. The available developers could not maintain a separate custom implementation for each framework.
Spark Island had broad support in principle. Few groups wanted to fund its engineering, so leadership favored an established third-party library.
Why Material did not fit
Material offered a broad ecosystem and strong engineering support. Its interaction patterns are heavily influenced by consumer and mobile products. Many Intel applications serve expert users working in dense, technical desktop environments. Material would have been easier to maintain. Its interaction model did not fit those products well.
Why Carbon fit
IBM Carbon was designed for enterprise software used by experts working with dense data and complex workflows. It reduced the amount of custom engineering we needed. Its interaction patterns suited Intel products.
Validate before committing
The team built Carbon proofs of concept in React and Angular. Both worked, so we proceeded with the migration.
Sequence the migration by dependency
The migration started with the parts of the system that other components depended on.
Tokens and themes came first. Foundational components followed, then components with more dependencies. The team also mapped Spark Island patterns to Carbon equivalents and migrated the code infrastructure and Figma libraries. We updated the documentation and helped product teams adopt the new version.
Support eight themes with one token structure
Spark Island originally supported four visual themes with light and dark modes. A later Intel brand change added another light and dark pair, bringing the total to eight. I managed the token structure and updated the Figma libraries. Developers implemented the tokens in code.
I also used AI to build Figma plugins that reduced the manual work of documenting tokens across all eight themes.
Migration surfaces
- Component mappings and theming
- React, Angular, and CSS infrastructure
- Figma libraries and design tokens
- Documentation and product-team adoption support
Lower the cost of maintaining the system
Adoption varied across product teams. Long-term ownership and funding remained the harder organizational problem.
When I left Intel, the Carbon migration was complete, several teams had adopted the system, and Spark Island had been released as open source.
Carbon reduced the amount of custom engineering Intel needed to maintain. Continued product, design, engineering, documentation, and adoption support was still necessary. I cannot verify how well the system was supported after my departure.
