Design Systems at HBP — Building the Shared Language That Let Us Move Faster
I introduced a design system to Harvard Business Publishing from the ground up — and the platform saw 25 more educator registrations per day, year over year.
This design system became the foundation for all AI features that followed. When you have a shared design language, teams can move faster on new capabilities without fragmenting the user experience.
Context
Before a design system existed at HBP, design and engineering teams were making decisions in parallel — inconsistent components, duplicated effort, and a user experience that felt subtly fragmented across the platform. The platform had grown faster than the design infrastructure supporting it. I saw an opportunity to change that: not just by building a component library, but by establishing a shared design language that would let teams ship better work, faster.
Alignment
The design system came out of a deliberate decision the UX team made when we knew a full redesign of the Harvard Business Publishing Higher Education site was coming. Rather than rebuild page by page without a foundation, we used the redesign as the opportunity to build a shared design language from the ground up — one that would shorten development and UX cycles, streamline accessibility reviews and QA, and give design and engineering a common vocabulary.
At the same time, I advocated for moving the team from Sketch to Figma — the right moment for it, given Figma's growing adoption, rapid feature releases, and collaborative workflow. We built the system in-step with the redesign: starting with documented standards (spacing, color, typography), then growing into a full component library as page-by-page work demanded it. I built the system myself and managed a junior designer who contributed alongside me. Because we were working early in Figma's lifecycle, we've since gone back to add more mature features like auto-layout and tokens as the tooling caught up.
Building
A design system only works if developers actually use it. I worked closely with the engineering team throughout the build to make sure component specs were clear, handoff notes were thorough, and the system reflected how things actually got built — not how a designer wished they would be built. This collaboration shaped decisions about where flexibility was needed, where it wasn't, and how to version the library as the product evolved.
Outcomes
The true measure of a design system is whether it changes how teams work — and whether users notice.
- Introduced design systems practice to HBP — first system on the platform
- Component library used across the entire platform, reducing design-to-development friction
- Documented in Confluence; managed via Jira; trained team on adoption
- Created a replicable framework the team continues to build on
- Foundation for all subsequent AI feature design
- Heatmap tracking shows significantly more activity on the Free Trials and Videos sections for Simulations
- Survey results showed 67.2% of participants responded it was easier to find information on the redesigned page