Building the system behind Highspot's product experience

Designers worked across disconnected files and patterns. Engineering had a loosely organized Rails component library, but shared implementation was limited. Similar problems were solved differently across the platform, creating inconsistencies in both the interface and the underlying code.

At the same time, Highspot's design leadership team was defining Arctic, a new design direction intended to bring more structure, hierarchy, and identity to the product.

As Director of Product Design for Platform, my responsibility was to turn that direction into something teams could actually build with — establishing the Foundations organization, formalizing Polar as our design system, and aligning design, product, and engineering around a shared approach to the platform.

The Problem

Highspot already had the beginnings of a design system when I took over Foundations, but it wasn't yet operating as a system teams could consistently rely on.

Designers were working across independently maintained files. Naming conventions and interaction patterns varied. Component architecture wasn't standardized, and there was limited alignment between what existed in design and what engineers were building.

The result showed up throughout the product.

Interfaces had become fragmented, teams repeatedly solved similar problems, and the platform lacked a clear hierarchy between its different experiences.

Everything began to feel like it belonged at the same level.

That created a larger experience problem: customers didn't always have a strong sense of place within Highspot.

We needed more than a component library. We needed a shared model for how the product itself was constructed.

Arctic and Polar

Arctic began as an initiative across Highspot's design leadership team — five design directors and our VP of Design — to establish a new direction for the product.

Our VP initiated the effort and helped establish the overall vision and leadership support, while the broader design leadership team contributed to defining how that direction should manifest across the platform.

My team's responsibility was to operationalize it.

The existing Highspot Design System effort evolved into Polar: the formal component, pattern, token, documentation, and governance system underneath Arctic.

The distinction was intentional.

Arctic defined how Highspot should feel and behave. Polar gave teams the system to build it.

Creating a Sense of Place

One of the larger problems Arctic addressed was the relationship between different parts of Highspot.

Analytics, Learning, Content, administrative experiences, individual objects, and temporary interactions had historically lived within an interface that didn't clearly communicate their relationship to one another.

We introduced an Experience Layer model to give those experiences a predictable hierarchy.

This became more than a diagram describing interface depth. It gave designers and engineers a shared framework for deciding where an experience belonged before determining what it should look like.

Combined with changes to navigation, headers, page structure, and a deliberate reduction in unnecessary iconography, the layering model helped create clearer relationships between the different worlds within Highspot.

Building Foundations

My role wasn't to personally design every Polar component. It was to create the organization, strategy, and operating model that allowed the system to scale.

I built and led a Foundations team of three senior designers with complementary areas of ownership across component development, documentation and testing, adoption, and embedded support for feature teams.

I also brought in a senior frontend engineer on contract to help us prototype component architecture and strengthen the connection between what we were designing and what engineering could realistically implement.

My responsibilities included the Foundations strategy and roadmap, hiring and team development, system architecture, governance, executive presentations, accessibility standards, design critique, component approval, engineering alignment, product-pillar prioritization, and adoption strategy.

The design system itself was only one part of the job. The larger responsibility was making foundational work a durable part of how Highspot planned and built product.

Polar

Polar became the primary system designers were expected to use for all new product work.

Over time, the library grew to more than 100 components and shared patterns, providing teams with common solutions for the interface elements and interactions that appeared throughout Highspot.

That included more than visual specifications. We established component architecture, tokens, naming conventions, interaction patterns, accessibility expectations, documentation, governance, and contribution models.

Every new design across our product pillars was expected to use Polar.

That expectation mattered. A design system only creates leverage when teams stop treating adoption as optional and begin using it as the default starting point for product development.

Aligning Design and Engineering

The design work also became a catalyst for reconsidering Highspot's frontend architecture.

Engineering ultimately moved toward a shared Web Components approach that could provide reusable interface primitives across the different technologies used throughout the platform.

The technology choice belonged primarily to engineering, but Polar helped establish the product architecture those components needed to represent. Design and engineering worked together around component boundaries, behaviors, naming, accessibility, composition, and how shared elements should evolve.

By the time I left Highspot, engineering had implemented the core component sets and was beginning to use that foundation for larger shared experiences, including the unified Viewer framework.

The long-term goal was design/code alignment: product teams designing with Polar and engineering teams assembling those experiences from the same shared concepts.

Shared UX

Some problems couldn't be solved by a design-system team alone.

That led to Shared UX, a cross-functional partnership between Product, Engineering, and Design responsible for shared interface needs across Highspot.

Foundations remained part of the design organization. Shared UX gave us the cross-functional mechanism required to turn those standards into working product.

The group included product management and engineering leadership alongside dedicated product, engineering, and design contributors. Together, we established a charter for how shared experiences should be prioritized, built, maintained, and rolled out across product teams.

That distinction was important: Foundations defined and evolved the system, and Shared UX helped operationalize it across the product.

Rather than relying on individual feature teams to independently interpret the design language, we now had a group responsible for the connective tissue between those experiences.

The Outcome

By the time I left Highspot, Polar had grown to more than 100 components and patterns and had become the required foundation for new design work across the product organization.

Engineering had implemented our core shared component sets and begun using them to construct larger platform experiences.

More importantly, the work established an organizational model around the system.

Foundations had a strategy, roadmap, governance model, and clear ownership. Shared UX connected that work to Product and Engineering. Feature teams had a common design language and a defined system to build from.

Arctic provided the direction. Polar turned that direction into a system. And Foundations and Shared UX created the organization needed to keep both evolving.

The goal wasn't simply to make Highspot more consistent. It was to create a platform that could evolve coherently as the company continued to grow.