Shade UI Case Study

Developer Tools, Design Systems | 2024 | Product Designer, Developer

Overview

Most design systems don't fail dramatically — they drift. A component updates in code, the Figma library lags behind, and suddenly designers are guessing again. For teams moving fast, that introduces rework. For designers learning to code, it erodes confidence in the tools they're supposed to trust.

ShadeUI was built around a single constraint: if a component exists in Figma, it exists in code in exactly the same form. No approximations, no drift.

Built in collaboration with Tunde Adekoya, I led the design system architecture, component design, and the ShadeUI website from design through development. Every decision was made jointly, but design consistency and system coherence were mine to maintain. That meant making hard calls early — prioritising architectural decisions over visible progress, so the system could scale without breaking.

Problem

Most design systems fail quietly. They don't break all at once — they drift. A component updates in code, the Figma library lags behind, and suddenly designers are guessing again. For designers learning to code, this erodes confidence. For teams moving fast, it introduces rework and friction. Working at the intersection of design and development, my collaborator and I had experienced this repeatedly. Instead of solving it with process ("remember to update Figma"), we asked whether the system itself could enforce consistency.

Constraints

ShadeUI was built around one rule: if a component exists in Figma, it exists in code in exactly the same form. No approximations, no drift.

The constraint sounds modest but cascades hard. It rules out the easy Figma habit of designing a handful of almost-the-same variants that don't map cleanly to props. It rules out shipping code that's a near-match but not an exact one. It forces the architecture to be deterministic before the system looks complete.

A few things followed from that. The Figma library and production components stay in lockstep, with one source of truth for structure, variants, and naming. Tokens and theming became the scaling path, not duplicated visual families per brand: adding a new theme is a token override, not a new component tree. Documentation was written for designers first, engineers second, so usage intent is part of the system rather than an appendix. The ShadeUI website and Storybook became the distribution and teaching layer, which mattered because adoption was the actual metric.

Role and collaboration

I owned the design system architecture from the design side, with a focus on how design decisions translate into production constraints.

My responsibilities included:

• Defining component structure, states, and variants in Figma • Establishing design tokens aligned with implementation realities • Designing over 100 components to pressure-test the system • Creating documentation to explain not just what components exist, but how they're intended to be used • Designing and building the Shade UI website

I worked closely with a designer-developer partner responsible for implementation, Storybook setup, and npm distribution. Decisions were made collaboratively, but I was accountable for design consistency and system coherence.

System view

The team was two people. On the design side, I led system architecture, component design, and the ShadeUI website. Tunde led implementation, Storybook, and npm distribution. But the work itself was constant back-and-forth: I'd ship a component, he'd flag where it wasn't holding up in code; he'd push to npm, I'd flag where documentation hadn't caught up. Decisions came from both of us, because there were only two of us to make them.

The rule when parity broke was simple: both of us stopped adding components and fixed the model. Most design system failures aren't from bad components; they're from no one being accountable for the system as a system. With two people, that accountability had to be mutual.

Key decisions

Pausing new components when button variants broke in code. Figma encouraged many visual combinations of the button: sizes, colors, icons, states, all multiplied together. Code needed a small composable prop model: a few props that combined into the same outcomes. The Figma model and the code model had drifted. We stopped shipping new components until the button's variant logic was a prop pattern we could apply everywhere. The tradeoff was visible slowdown, with no new components shipped while we reworked the model. The outcome was a prop-driven variant pattern that became the discipline for everything that followed.

Validating with Univelcity students building real sites, not just internal dashboards. Univelcity, a bootcamp training designers and developers to ship real products, adopted ShadeUI into its curriculum. Most students weren't yet ready to build a design system themselves; ShadeUI became the scaffold that let them ship complex products without first building the infrastructure underneath. That validated the designer-first usability constraint. It also surfaced a gap: students were building marketing sites with heroes, grids, and testimonials, while we'd focused on dashboards. Based on that feedback, we introduced new components for those workflows, and the system grew without forking.

Shipping a small beta surface instead of everything we'd designed. We had over 100 components designed in Figma. We shipped five: Button, Input, Badge, Banner, TextArea. The tradeoff was apparent scope, since the npm package looked thin next to what existed in design. The outcome was a clean validation of the parity model, npm ergonomics, and documentation before we let the surface grow. Fewer surprises for early adopters, and a stronger trust foundation when the rest came.

Goals

Deterministic parity - Every Figma component maps 1:1 to a production component. No approximations.
Designer-first usability - Designers should understand how components work without needing deep framework knowledge.
Scalability - The system should support future theming, dark mode, and token overrides without re-architecting core components.

Challenges

The first real failure surfaced with buttons. Visually, it was easy to create multiple button styles in Figma. In code, those same variants needed to be expressed as a small, composable set of props. Our initial approach allowed too many visual permutations, which broke when translated to code. Rather than patching the symptoms, I paused new component design and revisited the underlying model.
[object Object]
[object Object]
Shade UI was our first public npm package, which introduced unfamiliar problems beyond design: • Versioning and distribution • Documentation clarity • Storybook configuration • Maintaining trust as the system evolved When we hit blockers we couldn't resolve internally, we reached out to peers with more experience. This reinforced an important lesson: shipping a system is as much about collaboration and humility as it is about technical skill.

Solution

To move beyond internal assumptions, we partnered with Univelcity and gave early access to students learning design systems and front-end development. These users weren't building internal dashboards — they were building landing pages and marketing sites. That insight exposed a blind spot in our roadmap. The system was functionally solid but incomplete for real-world product building.
[object Object]
[object Object]
While over 100 components were designed, we intentionally shipped a small beta: • Button • Input • Badge • Banner • TextArea Shipping fewer components allowed us to validate the architecture without committing to a large, unstable surface area. Despite the limited scope, early adoption validated the core premise.
[object Object]
[object Object]

Impact

Adopted by Univelcity, one of Nigeria’s leading computer training schools, as part of their curriculum — signaling trust in ShadeUI as a system students could learn and build with.
Used by 600+ designers, with 400+ npm installations across developer projects building with ShadeUI.
Introduced a website refresh that drove a 639% increase in traffic over the following year, sustaining momentum well beyond the launch.
600 + Figma downloads by designers building with Shade UI
400 + npm installations across developer projects
639 % Increase in website traffic over the year following the refresh
7.5 % Click-through rate — an audience actively looking for what Shade UI offered
100 + Components designed to pressure-test the system architecture
1 Leading training school (Univelcity) adopted Shade UI into their curriculum

Reflection

This work made one thing clear: consistency is enforced by architecture, not reminders. Process (design reviews, "remember to update Figma," even good intentions) doesn't scale. An enforced constraint does. The earlier the constraints are explicit, the less drift there is to fight later.

It also made me think differently about everything around the components: versioning, documentation maintenance, the discipline of being readable to people without context. Most of that work isn't visible in any single component, and it changed how I think about shipping a design system at all.

ShadeUI isn't done. Next bets: broader component coverage, theming, and continuing to earn trust as the system evolves in public.