Building the system behind Sakari

Sakari is a B2B SaaS messaging platform. Teams use it to send and manage customer communications at scale, with a growing surface area and multiple squads shipping in parallel.

I was the senior, and sole, product designer. Most of the product sits on a shared system I designed and stewarded, called Arctic.

One of the most impactful pieces of work I did at Sakari wasn’t a single feature or release. It was the creation, implementation, and ongoing stewardship of our design system, Arctic.

Without a shared system, design decisions quickly become fragmented, expensive to maintain, and hard to reason about. Arctic was created to solve a simple but persistent problem: how do we move faster without sacrificing consistency or quality? The answer wasn’t more rules. It was a better system.

Arctic is built on an atomic component model. Instead of designing pages or features in isolation, the system is composed of reusable primitives that scale upward.

• Buttons, inputs, and toggles
• Tables and page headers
• Layout patterns used across the app

We based Arctic on Joy UI, the newer Material UI component library. It gave us a solid technical foundation and accelerated early development.

Material ultimately discontinued Joy UI, which forced an important decision: wait on the library, or own the system ourselves. We chose ownership.

Rather than treating Joy UI as a black box, I progressively refined and extended it, reworking inputs to match Sakari’s visual language, adjusting spacing, typography, and interaction states, and adding components and patterns the stock library didn’t account for.

Over time, Arctic became less a themed library and more a Sakari-native system, informed by Joy UI, but not dependent on it. The system should serve the product, not the other way around.

A design system only works if it’s actively maintained. Each component had a status that answered three questions: has it been signed off, has it been implemented and verified in Chromatic, and is it live in the product?

Handoff used Figma annotations, ready-for-dev statuses, a master component table, and Notion as the source of truth. The toolchain was Figma, Storybook, and Chromatic, so designers and engineers could work in parallel without drift.

Every project at Sakari used Arctic. Not as a suggestion. As the default. That sped up new feature work, focused design reviews, reduced implementation variance, and built shared trust. When something didn’t exist in the system, that gap became a conversation, not a workaround.

Design systems are about decision-making, not just components. Ownership matters more than perfection. Systems only scale when they’re actively stewarded. The best systems fade into the background, until they’re missing.

A design system is never done. It evolves with the product, the team, and the constraints around it. Arctic wasn’t just a set of components. It was an investment in how Sakari works.