Penta

Overview

When I joined Fiverr, “the design system” was a Photoshop UI toolkit — a shared file of styles, not a system. Over the following years, as Director of Product Design, I drove the effort to turn that into Penta: a real, team-owned design system, built and maintained by a dedicated team in partnership with engineering.

This is a leadership story more than a hands-on one. I identified the need, made the business case for the investment, created the design-system team, and set the direction. The hands-on build was led by a dedicated product designer working alongside a four-person engineering team — my role was to establish the function, secure the buy-in, and keep it aligned with where the product was going.

The Problem

A design system isn’t a style guide — a style guide is one part of it. Fiverr had the style guide but not the system, and the gaps were starting to cost us.

No design-system authority. There was no single owner and no agreed source of truth, so consistency depended on individual designers remembering how things were “supposed” to be done.

No shared language. Designers, writers, and engineers described the same components in different terms. A name that meant something in a design file meant nothing in the codebase — so intent got lost in translation on the way to production.

A widening gap between design and production. What designers specced and what actually shipped drifted apart, because there was no systematic way to keep them in sync.

Accumulating tech debt. Without shared, reusable components, every new feature rebuilt what already existed — slower to ship, harder to maintain, and steadily eroding the level of experience we were trying to hold.

Underneath all of it: it was becoming hard to maintain the quality of experience we wanted, and the design organization was scaling faster than the system holding it together.

Making the Case

Building a design system is expensive. It needs a dedicated designer, a team of engineers, and a lot of ongoing effort — so before any of it could happen, the investment had to be justified to management.

Consistency alone wasn’t the argument that would land. The ones that did were velocity and scale: with a shared library of ready-made components and patterns on both the design and development sides, teams could build new features and flows far faster — instead of rebuilding the same pieces from scratch every time. And as the team grew, a design system meant new designers and engineers could onboard into a shared language and contribute quickly, rather than spending months learning how things were done. Framing Penta as a way to ship faster and scale more cleanly, not just look more consistent, was what turned it from a design preference into a business decision worth funding.

Making that case wasn’t a solo effort. My manager, the Head of Design, helped build the argument — including bringing in an outside expert to speak to the value of a design system, giving leadership external validation alongside the internal push. Securing buy-in for an investment this size is its own kind of work, separate from the design itself — and it’s what made everything that followed possible.

The Approach

With the investment secured, the build came down to five moves.

Create a design-system team. The first and most important decision was that a design system needs an owner. I established a dedicated team and appointed a product designer to own Penta — turning “everyone’s responsibility” (which meant no one’s) into a clear mandate, backed by engineering.

Build it from the ground up. Rather than patch the existing toolkit, the team rebuilt the system properly — components, patterns, and the structure to hold them — documenting as it went so the system was legible from day one.

Create a shared language. The team closed the gap between how design named things and how engineering implemented them, so a component meant the same thing on both sides. On the design side, components lived in Figma. On the engineering side, the same components were built in React and documented in Storybook — so a designer and an engineer referencing “CardHeader” were looking at the same thing, just in their own tool. This alignment is what makes a design system actually reduce work rather than add a translation layer — and it’s what delivers on the velocity the whole case was built on.

Build it together. Penta was built as a partnership between design and engineering, with a contribution model that let people across both disciplines take part in improving it — so it became a shared asset the organization owned, not a library handed down from one team.

Document everything. Everything lived in Notion — guidelines, examples, and onboarding material — so new designers and engineers could get started, catch up, and contribute without needing someone to explain the system to them.

Outcome

Over several years, Penta went from a Photoshop toolkit to a team-owned system with a dedicated designer, an engineering partnership, a shared design-to-code language, and full documentation — the foundation the product design organization scaled on.

But the part I’m proudest of sits upstream of the system itself: recognizing that something this expensive had to be sold on velocity, making that case to leadership, and building the team to deliver on it. Identifying a systemic problem, securing the investment to fix it, and setting the direction while the people closest to the work did the building — that’s the work a design director does that never shows up in a single screen.

What I’d Do Differently

We treated the design system as something to invest in once its absence became painful — once the tech debt, the drift, and the missing shared language had already accumulated. In hindsight, the case for a dedicated system and owner could have been made earlier, before the gaps became the bottleneck. It’s a lesson I’ve carried forward: a design system is a strategic foundation, and the argument for it — the velocity, the reduced duplication — is usually true long before anyone feels the pain of not having one.