BlockUI: Building a Unified Design System for Development
January, 2026
Design system
Atomic design
Modular tokens
TL;DR
As Lead Designer at Deebug Studios, I spotted a recurring bottleneck: every new project meant reinventing buttons, colors, spacing, and layouts from scratch. Developers faced inconsistent handoffs, designers duplicated effort, and our UIs varied in quality and accessibility.
I advocated and led the creation of BlockUI — a comprehensive design system library — to establish a single source of truth for web (React.js) and mobile (Flutter). Over 3 months of phased work and iteration to meet standards. With a team of 2 other designers under my lead and close dev collaboration, we built a design system for design and development grounded on the principle of Atomic Design by Brad Frost.
While still in active development as of the time of publishing this case study, the impact was already visible within the design team: dramatically improved consistency, faster iteration speed, noticeably better-looking interfaces, and smoother collaboration among designers.
Area
Before BlockUI
Early adoption
Design consistency
High variation across projects
Consistent and uniform look and feel
Design speed
Reinventing elements repeatedly
Component reuse with faster prototying
Team collaboration
Isolated design decision and debates
Shared library, better alignment and feedbacks
UI quality
Inconsistent polish and accessibility
Improved aesthetics, cleaner, intentional designs
The Problem: Spotting the Design Debt
A few projects I was opportune to work on into my early time at Deebug Studios, the pattern became impossible to ignore. We'd kick off a new feature or product, and within days the same questions resurfaced: "What shade of primary blue are we using this time?" "Should buttons have 4px or 8px radius?" "How do we handle dark mode consistently?"
Designers spent hours aligning on basics instead of solving user problems. Developers, receiving yet another set of slightly different specs, ended up with mismatched implementations, design QA becomes argumentative or ignored — increasing bugs, rework, and maintenance debt.
Our products suffered too. Users encountered subtle inconsistencies: a button that looked one way on web, another on mobile; poor contrast in certain states; navigation that felt disjointed across breakpoints. Accessibility wasn't baked in reliably. It wasn't catastrophic, but it slowed us down and undermined our delivery output.
I realized we needed a unified design language — not just pretty components, but a foundational system that scaled across our development stacks: React web and Flutter mobile, reduced handoff friction, and enforced accessibility from the start.
Discovery & Syncing with the Team
Coding Methods
I started by auditing past projects: collecting Figma files, exploring web and mobile builds, component libraries (if used at all), and code snippets. The fragmentation was clear.
Next, I pushed to organise sync sessions with developers in order to find out their naming preferences, breakpoint strategies, theming approaches, and pain points with design handoffs. We settled on a hybrid camel_snake_case convention (e.g., my_Variable_Name) for tokens and components — readable in both design and code. Breakpoints and grids were aligned early so our Figma setups mirrored their CSS/Flutter realities.
Use of AI agents
Another major discovery I made with the developers was their use of AI agents in optimising design implementation done on Figma. This was usually done by taking screenshots or exporting UI screens to the agent and prompting according. This worked but wasn't as effective in quality and accuracy.
Hence I pushed for the company to upgrade our Figma subscription plan in order to access more design and development features, especially the Figma MCP. A game changer that allows developers to implement designs on Figma with their AI agent, exactly as it was designed on the canvas, using the style, variables and components used.
Assembling for Design
We assembled a team of 3 designers, ran some workshops to map our common UI patterns, reviewed existing industry references (Google's Material Design, Apple's HIG, W3C's WCAG, Untitled UI, ShadCN and MUI) agree on principles: modularity via Atomic Design, scalability via Tree Mapping tokens.
This early alignment was crucial. By involving devs from day one, we avoided the classic "designers build in isolation" trap. The taxonomy document became our living blueprint.
The Foundation: Principle & Architecture
Atomic Components
We adopted Atomic Design for the component hierarchy: starting with Atoms (inputs, icons), composing into Molecules (search bars, form groups), Organisms (nav systems, product cards), Templates (page skeletons), and example Pages. This ensured everything was built bottom-up, testable, reusable, scalable, flexible and maintainable.
Modular Tokens
I adopted a 3-level hierarchy, where design tokens and variables are mapped in a tree model structure from primitive to specific values. This made theming and modes effortless and prevented drift.
Root (Primitives): raw values like hex hues, underdefined numbers/unit scales and type foundations.
Stem (Semantics): purpose-driven and property-scoped mapping of the primitive values.
Branches (Specifics): component-level applications and usage with theme, mode or styled collections.
Breakpoints & Layout System
One of the most deliberate parts of BlockUI was creating a flexible, purpose-driven layout system that adapts intelligently across an unusually broad range of devices—from tiny smartwatches to ultra-wide desktop monitors and large screens. Rather than relying on a single rigid grid, I designed four distinct layout modes to suit different contexts, content density, and user scenarios:
Adaptive — for smaller screens, content-heavy, mobile-first experiences and tight spacing.
Standard — for common devices; standard margins and flexible content arrangement.
Expanded — employs more whitespace for mid-to-large screens; enhances focus and premium feel on tablets/desktops.
Wide —optimised for landscape mobile and large screens (4K, TVs, wide monitor) with wide margins to prevent content stretch.
Accessibility
Accessibility was embedded at every level—not an afterthought. When defining variables and styles, components states and properties, I enforced WCAG 2.1 AA (and targeted AAA where practical) across key dimensions such as colour contrast, text size and readability, alt text and semantics, focus states, touch targets and error handling.
These standards were enforced through token choices, variant properties, and exhaustive component documentation and annotations—making compliance the natural, not an extra step.
Building BlockUI: Layer by Layer
Iconography
I decided to integrate Phosphor icons, being the most robust icon library with over 1500+ unique SVGs, offering multiple styles and sizes, and flexible cross-platform integration for both mobile and web via CDN/package.
Colour Variables
Colour variables was the first system we fully fleshed out—because nothing breaks consistency faster than mismatched hues across screens. We structured it in three clear levels:
Raw Hues (primitives): 9 grade colour scale (100-900) for 16 unique colour hues (gray scales + vivid colors like blue, aqua, red, maroon, etc.)
Roles (semantics): primitive colours mapped into purposeful roles from light, mid and dark shades/tints: neutral neutral (gray scale), accents colours (danger, warning, success, info and abstract, extended colour (the remaning 10 hues). Primary and secondary colours where unassigned and reserved to the designer's choice for the brand colour.
Theme (specifics): Final application layer mapped semantics to context-aware properties across light and dark themes:
Surface (backgrounds)
Text (primary/secondary/extended/disabled)
Stroke (borders, dividers)
Alpha (overlays, scrims)
Shadows (elevation-based tints)
Generic fills (icons, badges, etc.)
In practice, this meant a designer could switch themes in Figma (or code) and everything adjusted automatically—no manual overrides. We tested every pairing against WCAG AA contrast from day one, baking accessibility into the branches. The payoff was immediate: no more “which red for error?” debates; the system guided choices while still allowing brand expression.
Number Variables
Spatial decisions affects perceived quality more than most people realize. Inconsistent padding or radius can make even beautiful components feel off. I built number tokens with the same three-level discipline to create rhythm and predictability.
Units (primitives): Defined core scales in two flavors:
Fixed px scale (multiples of 4px: 0, 4, 8, 12, 16, ..., up to large values)
Percent scale (10% increments: 10%, 20%, ..., 100%+)
Resolution (device physical px dimension values)
Object Property (semantics): Assigned units to specific CSS/Flutter properties with semantic meaning:
Space (margins, padding, gaps)
Opacity (disabled states, overlays, emphasis levels)
Border (widths)
Column count (grid flexibility)
Viewport (device width and heights)
Radius (corner rounding)
Dimension (element sizing dimensions)
This layer turned abstract numbers into named intent: like "spa16" for 16px space instead of hard-coded raw value.
Number Styles (specifics): Contextual applications, including:
Mode-specific shadows (drop and box shadows properties)
Breakpoint-aware layout (e.g., container max-widths, margin or gutter adjustments per mode: Adaptive/Standard/Expanded/Wide)
By keeping everything in multiples of 4 and tying to the layout modes we defined earlier, we achieved visual harmony across devices. Percent-based values helped with fluid scaling on watches and ultra-wide screens.
Type Variables
Typography brings hierarchy and voice to the interface. I wanted it flexible, readable, and responsive without pixel-perfect rigidity across platforms.
Strings (primitives): Base typeface strings (font-family stacks), placeholder text examples, and core font properties (weights: 300–900, styles: normal/italic).
Font Property (semantics): linked to primitive units value and string texts:
Font size (base scale)
Line height (relative)
Letter spacing (tracking)
Font weight (variable)
Mode-based font style (sans, serif, etc.)
I applied metric type scale (base 16) in determining the font-sizes, creating a harmonious multiple of 8 sizes from large to small. 12 was enforced as the minimum for web content in accordance WCAG 2.1 AA. Proper documentation was also made on choice of font-size unit for developers. This allowed natural scale for accessibility and cross-device consistency (especially Flutter's density-independent logic vs. React's pixel world).
Styles (specifics): Final semantic roles and breakpoint-specific styles:
Display (hero headlines)
Headline (section titles)
Title (card headers)
Body (paragraphs, labels)
Label (small UI text)
Each role had responsive adjustments paired line-height ratios in percent for readability. This percent-based approach made type feel alive and inclusive—text never felt cramped on small screens or oversized on large ones.
Outcome, Metrics & Learning
To validate our design decisions and track the super-app's performance, I worked with our engineering team to implement a comprehensive analytics setup with custom event tracking across all user touchpoints.
Key metrics we intend to track:
Service discovery rates (how users find new features).
Cross-service adoption patterns.
Payment method preferences by region.
Feature usage patterns across different user types.
Support ticket categories and resolution times.
Analytics framework: Google Analytics 4 with custom events, behavioral tracking, and session recordings across mobile and web platforms
Our dual-mode interface is targeted to improve task completion by 34%, increase wallet and savings engagement by 3.2x, and reduce onboarding time by 68%. Key findings will reveal specific areas for improvement and feature updates.
Team & Credits
Role
People
Product Design Lead
Favour Eseosa (led strategy, research, product decision and stakeholder alignment; oversaw core architecture and design system usage.)
Design Team
1 Product Designer, 2 UI Designers
Key Partners
Engineering, Marketing and Product Management
This case study reflects work completed between September, 2025 and January, 2026 and executed by Deebug Studios.