One framework for every viewer

The result was fragmentation in both the customer experience and the codebase. Similar information appeared in different places, common interactions behaved differently, and engineering teams repeatedly rebuilt functionality that already existed elsewhere.

I led the design strategy to bring those experiences onto a shared, modular viewer framework — creating a common architecture that could support different product needs without requiring each team to start from scratch.

The Problem

The Viewer originally had a straightforward job: display content such as presentations, PDFs, images, and documents.

As Highspot expanded, the same viewing pattern began appearing across Pitches, Digital Rooms, Analytics, Learning, Engagement, and other areas of the product.

But these experiences weren't built from a shared foundation. Each product area created its own viewer, with its own code, interaction patterns, layouts, and decisions about where information should live.

The fragmentation created two related problems. For customers, similar experiences behaved differently depending on where they were in the product — actions, metadata, navigation, and supporting information could move from one viewer to another.

For engineering and design, teams repeatedly solved the same problems independently.

Seeing the Fragmentation

The header was one of the clearest examples.

When we placed the existing viewer headers next to each other, there were nine different approaches to essentially the same piece of interface.

Different controls. Different layouts. Different information hierarchy.

Those differences weren't necessarily the result of intentional product requirements. They were largely the result of teams building separate solutions over time.

The audit helped us move the conversation away from fixing individual viewers and toward solving the underlying platform problem.

Defining the Framework

I developed the strategy and architecture for a modular viewer that could become the shared foundation for these experiences.

Rather than designing one rigid viewer, we broke the experience into predictable regions and reusable components.

A common structure established where things such as navigation, actions, metadata, contextual panels, content, and controls belonged. Product teams could then compose those pieces based on their specific use case.

I owned the information architecture, viewer anatomy, interaction patterns, component definitions, prototypes, design-system integration, and migration strategy.

The goal was straightforward: teams shouldn't have to redesign or rebuild a viewer every time they needed one.

Proving the Idea

Platform work is difficult to justify through design artifacts alone.

Instead of proposing a large migration immediately, I worked with a frontend engineer on our Shared User Experience team to build the component framework and use it in a real viewer implementation.

The working implementation gave us a way to test both sides of the system: whether the design could accommodate different viewer requirements and whether the engineering architecture actually made implementation easier.

It did.

Viewer implementations had historically taken roughly 6–12 weeks. Using the shared components, the test case demonstrated that a comparable implementation could be completed in approximately one week.

That changed the conversation. What had initially been a platform experiment became a clear opportunity to reduce duplicated work across the product.

From a Pattern to a Platform

The proof of concept gave leadership enough confidence in the approach to reprioritize the roadmap around viewer consolidation. The larger opportunity included more than 10 viewer experiences across Highspot.

Scaling the system meant more than handing teams a component library.

The engineer who built the initial framework led training for other engineers, showing teams how to compose their viewer experiences using the shared components rather than creating new implementations.

On the design side, a designer from the Foundations team worked with product designers to help apply the updated viewer pattern within their individual feature areas.

This created a repeatable model for adoption: shared architecture and components, supported by design guidance and engineering enablement.

Designing for Variation

A unified viewer couldn't assume every use case was the same. Content, Analytics, Learning, Pitches, and other areas each had legitimate differences in what customers needed to see and do.

The framework therefore separated structure from composition. Core elements and behaviors stayed predictable while individual product areas could introduce the panels, controls, and content required for their experience.

My team also helped extend the framework into responsive and mobile scenarios so the architecture could hold up beyond the initial desktop implementation.

The objective wasn't to make every viewer identical. It was to make the parts that should be consistent consistent.

The Outcome

The most significant outcome of the project was organizational and architectural.

The working implementation demonstrated that a viewer experience that had historically required roughly 6–12 weeks of development could potentially be assembled from the shared framework in about one week.

That proof changed roadmap priorities and established a path for consolidating more than 10 independently built viewers onto a common foundation.

It also gave design and engineering teams a shared vocabulary for how viewer experiences should be constructed.

We didn't conduct a comprehensive user study measuring the impact of the consolidated viewers, so I wouldn't attribute a specific usability improvement to the work.

What we did create was a more deliberate foundation for the customer experience: common patterns, predictable information placement, and a codebase that made consistency easier to maintain rather than something every team had to recreate.

For a platform team, that was the real measure of success — make the right experience easier to build the next time.