Design System Reset

Kong provides cloud connectivity solutions that help organizations manage, secure, and connect APIs, AI, events, and microservices. By 2023, multiple product teams were shipping features in parallel across a growing platform, with designers and engineers needing to rely heavily on a shared design system to move quickly and stay aligned.

When I joined Kong, I took ownership of the design system with the goal of improving collaboration between product design and engineering. Early conversations made it clear that the system was no longer keeping up with the scale the organization had reached — and the gap was widening as the team grew.

The design system had become a liability. Designers struggled to find reliable files in Figma, components were outdated or difficult to use, and teams frequently recreated or detached elements to meet immediate needs.

Engineering lacked a dependable source of truth. Design decisions were inconsistently applied and rarely documented, making parity between design and code difficult to maintain. As inconsistency increased, trust between disciplines eroded and handoffs slowed. Every conversation became a chance to re-litigate decisions that should have been settled.

The problem was compounded by several constraints:

• A broad, distributed product surface with multiple teams shipping in parallel
• Highly customizable products, including open-source offerings
• No shared framework for documenting or governing design decisions
• Inconsistent language and mental models between design and engineering

At its core, the challenge was not simply fixing components. It was rebuilding a system that could support consistent decision-making, scale across distributed teams, and restore trust between design and engineering.

I approached the redesign of the system as both a technical and organizational problem, focusing on alignment, clarity, and usability. Each decision was aimed at addressing the lack of a shared source of truth, reducing inconsistency, and rebuilding trust between design and engineering.

Early on, we faced a strategic question: rebuild from scratch, or evolve in place? A clean rebuild was tempting, but product teams couldn't afford to wait — and asking them to was likely to deepen the trust problem we were trying to solve. We chose a hybrid. In Figma, I started a new library file from the ground up while the old one stayed available for teams to keep shipping. In code, engineers updated Vue components in place as the new Figma components were ready, so old and new coexisted until each piece was ready to migrate.

Establishing a shared source of truth

To address inconsistent and undocumented design decisions, we introduced a framework for creating and managing design tokens. Tokens captured core decisions such as color, spacing, and typography and became the foundation for aligning design and engineering across tools and codebases.

We held a strict bar for what became a token: each one had to be defensible in a single sentence. Tokens that couldn't be explained simply weren't ready to be tokens yet. With the introduction of Figma variables, we migrated key parts of the system to use tokens directly in design, replacing brittle layer styles and manual workarounds, reducing drift between design and implementation, and making handoff more reliable for engineering.

Improving component usability across tools

I designed components first in the new Figma library, then collaborated with engineers to align props between Figma and Vue. In the old library, the prop that switched a button between primary and secondary was called prominence in Figma but appearance in Vue. Small mismatches like this multiplied across components and quietly made handoff harder. Aligning the language meant designers and engineers could speak the same way about the same component.

Some decisions cut against design instinct. Where elegance pulled toward consolidation, like a single button component covering many states, we chose discoverability instead. Three button components, each clearly named for its use case, were faster to find, less likely to be misused, and meaningfully more adopted than a single elegant one would have been.

I also took ownership of several engineering-owned tools. I had write access to our design tokens and icons repositories and contributed PRs as the system evolved, with engineers reviewing rather than gatekeeping. I reviewed their PRs in turn when tokens or components were being adopted into Vue. The shift did more to rebuild trust than any meeting could: design owning and contributing, engineering reviewing and approving.

Aligning teams and ways of working

Collaboration breakdowns don't get fixed by tools. They get fixed by rituals. We started with an in-person offsite to clarify ownership and priorities, then established recurring rhythms: office hours, cross-team 1:1s, and design reviews. These gave teams a reliable, low-friction way to engage with the system. Rather than a disruptive overhaul, we iterated incrementally each sprint to allow gradual adoption.

Over the course of a year, the design system shifted from a source of friction to a reliable foundation for product teams.

Behind the numbers, the change was as much cultural as it was technical. Improvements were introduced incrementally, letting teams adopt changes without disrupting active work streams. Clearer documentation, shared tokens, and improved component usability restored confidence in the system. Designers and engineers reported fewer handoff issues, reduced rework, and greater alignment in retrospectives. New designers onboarded more quickly, and design established clearer ownership of visual and interaction decisions through shared tokens.

The system continues to evolve, but it has become a unifying asset across teams, supporting more consistent product experiences and healthier collaboration at scale.

This project reinforced that design systems are about decision-making and trust as much as visual consistency. Designers and engineers are the primary users of a design system, and treating them that way was essential to adoption. That meant designing for their workflows, friction points, and confidence.

I also learned the importance of sequencing and restraint. Deeper theming and customization were technically possible, but prioritizing clarity, consistency, and shared understanding let the system deliver value sooner without over-engineering. Knowing what not to build was as important as knowing what to build next.

Most of all, the work made clear how much of design system success is organizational. Creating space for alignment, shared language, and ongoing rituals mattered as much as the components themselves — and had a lasting impact on how teams collaborated long after the reset.

This work was made possible through close collaboration with product, design, and engineering partners. Special thanks to Josh, Adam, Maksym, and Jilson.