T*****
Design System
DRAG TO MOVE
Building one design language across 5 apps that were never designed to share one.
Heading:
Building one design language across 5 apps that were never designed to share one.
Role:
Sole Product Designer
Company:
IoT83
Read Time:
5 minutes
Timeline:
April 30, 2024 - Ongoing
Platform:
B2B Web Applications (5+ web apps)
Focus Areas:
Design System, Consistency, Prototyping, Developer Handoff
TLDR;
Built and scaled a design system across 5+ B2B web applications to reduce design debt, improve development efficiency, and enable faster feature delivery without disrupting ongoing sprints.
Context
I joined the team as the sole product designer supporting multiple client facing B2B web applications. There was no design team and no existing design system.
Work was already shipping across 5+ apps. Each product had grown on its own timeline, which meant the UI reflected many small, uncoordinated decisions made over time.
My responsibility was simple to state but harder to execute: bring consistency without slowing the team down.
THE problem
Every time I designed a new screen, I was rebuilding the same structures again. Padding had to be eyeballed. States had to be double checked. Handoffs triggered long clarification calls.
Designing or updating a screen usually took me around 40 to 50 minutes. Not because the problems were complex, but because nothing was standardized.
There was no single source of truth for the UI.
Incosistent UI
Next
THE CONSTRAINT
In a perfect world, I would have paused feature work for a few weeks and built the system cleanly from the ground up.
That was not the reality.
Active development sprints were already in motion, and product work could not stop. Features still had deadlines, and engineering still needed designs on time.
So the design system had to grow in parallel with live product delivery. That constraint shaped the entire strategy.
the approach
I structured the system using atomic principles:
Foundation → Atoms → Molecules → Organisms → Templates.
But instead of building the whole library upfront, I worked incrementally.
Instead of building the full library upfront, I worked in cycles.
After each feature handoff, while developers were in their sprint, I reviewed the work, extracted reusable patterns, standardized them, and added them to the system. Those components were then reused in the next feature.
This kept product work moving while the system matured.
Process gap I discovered a little too late-
Spacing variables were introduced after roughly 80% of the components were already built.
Once applied, they exposed:
uneven padding
small alignment inconsistencies
spacing mismatches across variants
This required revisiting several components.
Since then, I treat variables as part of the foundation rather than a later cleanup step.
what i built
Foundation —
Atoms —
Molecules
Input fields (text, number, email, password)
Search bar
Dropdown menus
Breadcrumbs
Pagination
Tabs
Accordion item
Alert/notification
Modal/Popover (basic structure)
Date picker
more
Organisms
Navigation bar
Header
Footer
Sidebar
Hero section
Card grid
List view
Table
Form (complex, multi-field)
Product listing
Calendar
Media gallery
Accordion (full component)
Tabs container (with content)
more
Templates
Home page layout
Product listing page layout
Product detail page layout
User profile layout
Dashboard layout
Settings page layout
Checkout process layout
Search results layout
404 page layout
Login/Sign up page layout
more
developer collaboration
Each major design required reviews with backend, frontend, and QA.
Before the system stabilized
review calls often took 40 to 50 minutes
many questions were about edge cases
After molecules and organisms were completed
most reviews dropped to 20 to 30 minutes
my walkthrough typically took 5 to 10 minutes
discussions became more focused
The main change was improved clarity and reuse.
Adoption and Pushback
Core components started getting reused across multiple active apps. Tables, form controls, and navigation patterns saw the fastest pickup.
Spacing variables also began showing up consistently in newer screens once they were properly wired in.
This was the point where the system started feeling real instead of aspirational.
Not every component was accepted on the first pass. Several patterns were pushed back during product and engineering review.
The most friction came from:
Transfer component
Button redesign
Tree view restructure
Earlier feedback also flagged issues in Pagination, Input, and Dropdown, which were later revised and are shipped as of today.
THE IMPACT
Reduced design time for standard screens by ~25–40% by introducing reusable components and standardized patterns
Reduced design review time by ~30–40%, with discussions shifting from UI clarifications to edge cases and product decisions
Standardized UI patterns across 5+ active web applications, reducing design fragmentation and improving cross-product consistency
Improved design-to-development alignment, reducing back-and-forth during implementation and increasing delivery efficiency
Reduced design debt by introducing shared tokens, spacing variables, and reusable components across systems
Before and After compaison —
what i'd do differently
If I restarted this work:
introduce variables at the beginning
validate feasibility earlier with engineering
be more careful when simplifying components that already communicate affordance well
map state matrices earlier
Not having a senior designer meant some of these adjustments came later than ideal.
Prototype of a "search" component to help developer understand how it should work —
NEXT STEPS
The system is still in progress.
Current focus:
completing organism level variable alignment
expanding edge case coverage
refining the transfer component
improving the button system
strengthening documentation
enabling developer contribution
The goal is to make the system easier to maintain and scale.
Thanks for reading 🙌
If you'd like to see more of my work, feel free to head back to the homepage and check out my other projects.