Oluwatosin Kazeem

When I joined Sandbox, the product had no shared design language. A heuristic evaluation revealed inconsistencies everywhere: colours, component patterns, typography, and spacing. Developers were sometimes rebuilding components they had already built because they forgot they existed. Styles and variables were hardcoded rather than shared.

After speaking with Bosun, it became clear the company planned to expand its product line. I proposed building a design system from the ground up to standardise design decisions and speed up future development. Bosun wanted to be sure it was worth the time investment, especially since we needed to move fast. I had to make the case that whatever time it took would pay off in the long run. It did.

I studied existing design systems, particularly Shopify's Polaris, as a comprehensive reference for how to structure a full system with components, tokens, and documentation. I adopted an atomic design approach because I was building from scratch. Atomic design lets you start small and grow the system piece by piece, which gives it a solid foundation.

The system was built layer by layer. I created colour palettes for light and dark themes. The dark themes were inspired by VS Code and included four named variants: Vulgaris, Moneilema, Melani, and Panther. Since Sandbox is used by developers, offering multiple dark themes gave them the same experience they were used to in their IDE. That familiarity was intentional.

Typography paired Satoshi and Fira Code. Fira Code gave the monospace feel developers already knew from IDEs, while Satoshi kept UI text clean and readable at smaller sizes. I also curated icons from different libraries and matched them to the same visual style so the system felt unified instead of pieced together.

The token architecture has three levels, and that layering is what made the system scalable. Global tokens are the raw values, the core styles with straightforward naming like neutral-500 or neutral-600. Semantic tokens give those values meaning. For example, background-secondary references a global token but describes its purpose. This is the layer that makes theming possible because you can swap what background-secondary points to without touching any components.

Component tokens apply semantic values to specific elements. For example, button-bg references background-secondary. This means a single colour change at the global level cascades through the semantic layer and into every component that uses it.

I used three levels instead of two because each layer serves a different audience. Developers working on a specific button only need to know button-bg. Designers thinking about the overall theme work at the semantic level. And the global level is where the raw palette lives. I also defined spacing tokens on a numerical scale so whitespace stayed consistent across components and layouts.

The design system shipped with four core deliverables: a style guide, design tokens, a component library, and documentation. The documentation was hosted on Zeroheight and structured around styles and components.

Beyond the documentation site, the Figma file itself was designed for onboarding. I used separate files and pages rather than putting everything in one massive file, and added annotations throughout so any designer or developer could get up to speed without needing to ask questions.

The hardest adoption challenge was getting the token system to work with Tailwind CSS, which the developers were using. The naming conventions and structure did not map cleanly at first, but we eventually figured it out. Once that bridge was built, adoption was smooth. Every component and token was tested across themes before release, and the documentation was designed to be clear enough that anyone could pick it up and start building.

Sandbox was first applied to the redesign of PHPSandbox itself. The initial version of the system took about one to two months to build. During the redesign period, PHPSandbox saw a 400% increase in its user base over two years. We did not do any marketing during this time. No promotions, just posts on Twitter. The growth is attributed to the drastic improvement in the interface, which increased user trust and made the product feel welcoming and familiar to developers.

The system was then used to build Play, a platform that lets PHP developers test Composer packages without needing to install them locally. Because the design system was already in place, Play shipped faster than it would have otherwise. Play saw over 600 packages tested in its first six months.

The design system is still reviewed and updated regularly as the product line evolves.

The single hardest decision was the input field label placement: whether to put labels outside the input or within it. It seems like a small detail, but it affects every form in the system, with implications for accessibility, space usage, and visual consistency across all components.

If I were building Sandbox again from scratch, I'd pay more attention to the colour and typography system because they play a major role in the design. Design is mostly 70% typography. I would also invest more in accessibility and responsiveness for every component from day one, rather than treating those as refinements.

What makes me most confident about Sandbox is the 400% growth with no marketing. When the only variable that changed is the interface, and the user base grows that much, the design system proved its value. That's not something I can say about every project, and it's the kind of result that shows design systems are not just internal tools. They directly impact how users experience and trust a product.