Oluwatosin Kazeem

Founding Product Designer. I led the strategy, design, documentation, and implementation of Sandbox, the design system that became the foundation for PHPSandbox’s products. My responsibilities included:

The same interaction was often represented in different ways across the product.

Without a shared component library, every new feature introduced another variation.

There was no underlying system governing how the interface should be built:

As a result, every design and implementation decision became an isolated one.

The product had been built primarily through engineering decisions. While this enabled the team to move quickly, there wasn’t a shared language between design and development. Developers frequently relied on Bootstrap components, Tailwind utilities, or custom implementations based on the immediate needs of a feature rather than reusable patterns. As the company planned additional developer tools, this approach would become increasingly difficult to maintain.

Accessibility wasn’t ignored, but it wasn’t embedded into the product’s building blocks. Focus states, contrast, semantic labelling, keyboard navigation, and reusable accessibility patterns were not standardized, meaning each new feature had to solve these challenges independently. I wanted accessibility to become part of the system itself rather than something considered at the end of a project.

I also studied established design systems, not to copy them, but to understand why they worked.

Polaris had the greatest influence on how I structured Sandbox, particularly in the organization of components, documentation, and naming conventions. VS Code shaped many of the interaction patterns, because the goal wasn’t to reinvent how developers work, it was to build an environment that felt immediately familiar.

By the end of the discovery phase, the challenge had become much clearer. The problem wasn’t simply inconsistent buttons or spacing.

Without one, every new feature, and eventually every new product, would continue introducing inconsistency, slowing both design and development. Instead of fixing individual screens, I decided to solve the problem at its source by creating a system that every future product could build upon.

Consistency is a by-product. The real value lies in creating a shared language that helps designers and engineers make better decisions together.

I adopted the principles of Atomic Design as the structural foundation of Sandbox. Not because Atomic Design is the only correct methodology, but because it provided a predictable hierarchy that both designers and engineers could understand as the system expanded. The system was organized into three layers:

This separation ensured that visual decisions flowed consistently throughout the entire system.

Rather than defining colours or spacing directly inside components, I built the system using Figma Variables. This made the design system significantly easier to maintain as it evolved. Instead of changing dozens of components individually, updates could be made once and inherited throughout the system. The architecture followed two distinct token layers, flowing from primitive tokens to semantic tokens to components to products.

Separating primitives from semantics meant visual changes could happen without rebuilding the component library. Changing a primary colour, introducing themes, or adjusting brand colours became significantly easier because components referenced semantic meaning rather than fixed values.

As the component library grew, consistency became just as important as the components themselves. Every component followed a predictable naming convention inspired by mature systems like Shopify Polaris.

A predictable structure made components easier to find, easier to maintain, and easier for new designers to understand.

Not every UI element deserved to become a reusable component. A simple rule guided the system:

This prevented the library from becoming bloated while ensuring repeated design problems were solved once instead of repeatedly. The goal wasn’t to create the biggest design system. It was to create the most useful one.

Documentation wasn’t something added after the design work was complete. It was designed alongside every component. Each component included usage guidelines, variants, states, do’s and don’ts, accessibility considerations, implementation notes, and naming conventions. The system itself lived inside Figma, while broader documentation and usage guidance were maintained in Zeroheight, making it accessible to both designers and engineers.

One of the goals of Sandbox was to reduce the gap between design and implementation. Because the system was built using Figma Variables, tokens could be exported as JSON, allowing engineering to consume the same values that existed in design. This created a shared source of truth across both disciplines. Rather than treating design files as static mockups, the system became something that could actively support implementation.

Once spacing, typography, colours, radius, and themes were standardized, every future component inherited those choices automatically. Instead of debating visual details every time a new feature was designed, the team could focus on solving user problems. The foundations became the guardrails that enabled faster and more consistent design.

The code editor became my favourite component because it represented everything the project was trying to achieve. Rather than creating an interface that looked different for the sake of originality, I focused on creating an experience that felt immediately familiar to developers. The result was an editor that borrowed established mental models from modern IDEs while remaining consistent with the overall Sandbox design language. Sometimes good design isn’t about creating something users have never seen before. It’s about making them feel at home from the first interaction.

No component was considered finished after its first iteration. Throughout the project, the component library evolved through:

The design system wasn’t static. It matured alongside the product. That continuous evolution became one of its greatest strengths.

Throughout the project, I found myself asking the same questions repeatedly:

Those questions became more important than any individual component. They shaped the way the entire system evolved.

Engineering wasn’t introduced after the design work was complete. They were involved throughout the process. Whenever a new component or interaction was needed, we discussed it before implementation to understand technical constraints, existing product behaviour, and opportunities to simplify the solution. The dependency search experience is the clearest example: what began as a straightforward interaction became a better one after engineering highlighted the challenge of large result sets, and we redesigned it together into a scrollable results panel. Good collaboration often produces better outcomes than working in isolation.

I treated documentation as part of the design system rather than something created after the work was complete. Every reusable component included guidance that helped designers and engineers understand not only what to use, but when and how to use it: component purpose, variants, states, usage guidelines, accessibility considerations, naming conventions, and implementation notes. The design system itself lived inside Figma, while broader documentation was maintained in Zeroheight, giving the team a central place to reference the system as it evolved.

One of the challenges with many design systems is that the design file and the codebase slowly drift apart. To reduce this risk, I built Sandbox using Figma Variables and structured the token architecture so values could be exported as JSON. This created a shared source of truth for designers and engineers. Instead of manually recreating values during implementation, engineering could work from the same tokens defined in the design system.

The first version of Sandbox wasn’t intended to be the final version. New components were only added after evaluating whether an existing pattern could be extended first. If the problem genuinely required a new solution, the process was straightforward:

This lightweight governance worked well for a small product team while preventing unnecessary duplication. The goal wasn’t to make the library bigger. It was to keep it coherent.

Accessibility wasn’t considered complete when the designs passed a contrast checker. It was verified again during implementation:

Embedding these checks into implementation helped ensure accessibility remained part of the product rather than simply part of the design file.

By moving beyond a traditional handoff process, the design system became more than a collection of reusable assets. It established:

Most importantly, it changed the conversation. Instead of discussing how individual screens should look, the team could focus on solving user problems using a shared set of building blocks.

Its greatest value isn’t visual consistency. It’s enabling designers and engineers to make consistent decisions together.

Before this project, I viewed design systems primarily as collections of reusable components. Sandbox challenged that assumption. The real work involved establishing principles, defining governance, creating documentation, collaborating with engineering, and building a foundation that could support future products. A button isn’t valuable because it’s reusable. It’s valuable because everyone on the team understands when, why, and how to use it. That shared understanding is what makes a design system successful.

One of the biggest lessons I learned was that consistency isn’t achieved by asking designers to make the same decisions repeatedly. It’s achieved by removing unnecessary decisions altogether. Once spacing, typography, colours, tokens, and interaction patterns were established, new components naturally felt like part of the same family. The design system acted as a set of guardrails rather than a set of restrictions. Good systems don’t limit creativity. They protect it from inconsistency.

Some of the strongest solutions in Sandbox came from conversations rather than sketches. The dependency search redesign is a good example. Instead of defending the original design, we treated the constraint as another design problem to solve. That experience reinforced an important belief: design quality improves when design and engineering work together early, not when they work sequentially.

One opinion I’ve developed through this project is that not every product should invest in a comprehensive design system. Early-stage startups often move too quickly for a large component library to deliver meaningful value. A design system becomes worthwhile when teams begin solving the same problems repeatedly, supporting multiple products, or working across multiple designers and engineers. The goal should never be to build a design system because mature companies have one. The goal should be to solve the right organisational problems at the right time.

I would spend more time understanding the company’s long-term product strategy before deciding which components to prioritise, mapping the system more deliberately against future business goals. I would introduce lightweight governance earlier, defining how new components are proposed, reviewed, and maintained as the library grows. And I would establish clearer adoption metrics from the beginning: success shouldn’t only be measured by the number of components created, but by outcomes such as reduced duplication, faster implementation, improved accessibility, and increased consistency across products. These are lessons I now carry into every design system project.

Sandbox was created for a small engineering-led team building developer tools. The principles behind it, however, extend far beyond this project. Whether designing a design system, a fintech platform, or a healthcare product, my approach remains consistent:

Looking back, I’m proud of the components we built. But I’m even more proud of the conversations they enabled. Sandbox introduced a common language that helped design and engineering move faster together. It replaced individual design decisions with shared principles, reusable patterns, and a scalable foundation that could support future products.

Sandbox introduced a structured foundation that the product previously lacked. The project established:

Before the design system, creating a new interface often meant making decisions from scratch. After Sandbox, much of that work shifted from creating to composing. Designers could assemble new experiences using established patterns, while engineers could implement them with greater confidence because the visual language remained consistent. This reduced unnecessary discussion around UI details and encouraged conversations about user experience instead.

One of the most valuable outcomes wasn’t visual, it was collaborative. Throughout the project, design and engineering developed a shared vocabulary for discussing interface decisions. Questions shifted from “how should this button look?” to “do we already have a pattern for this?”. That small change represented a much larger shift in how the team approached product development. The design system became a reference point for decision-making rather than just a library of assets.

Although Sandbox was initially built to support PHPSandbox, it was designed with a broader ambition. The company planned to expand beyond a single browser-based IDE into a wider ecosystem of developer tools. By investing in design foundations early, future products would have a consistent starting point instead of rebuilding common interface patterns from scratch. In that sense, Sandbox wasn’t just a solution for today’s product, it was an investment in tomorrow’s products.

Sandbox achieved what I originally set out to do. It transformed an engineering-led product with inconsistent interface patterns into one supported by a scalable design foundation. More importantly, it changed the way I think about systems. I no longer see design systems as libraries of components. I see them as tools that help teams make better decisions, collaborate more effectively, and build products with greater confidence.

Every product begins as a collection of features. The best products eventually become collections of thoughtful systems. Sandbox was my first opportunity to build one of those systems from the ground up.