OVERVIEW
In product team, seeing lack of parity between design and code, seeing old design system is not to flexible for designers and not function enough for developers, it was cost our team a lot of time and resources to design and develop the same design system (but different style) over time and projects. That's the problem I set out to solve, a system flexible enough for designers to rebrand fast, fast handover, and functional enough for developers. One system, many products, no more starting from zero
MY ROLE
UI/UX Designer
Initiator
TEAM
Products
Engineers
TECHNIQUE
UX Audit
Atomic Design
Library & Style guide
Design Tokens & Variables
APPROACH
MY RESPONSIBILITIES
Identify design system architecture, restructuring foundations, and crafted the components on top of that
Then documented the design specs and explain the usage guidelines to the team
I created and managed for each component library and tracking engineers work. If there any bugs, I will continue communicate with them and make it until it's as expected based on the design component. I also, delegate the system on how to use, does, and don’t to my team (UI/UX designers), so they can create a UI into their screen and also a good UX based on the requirements from product managers
Observation & Researching
Identifying pain points in the development process and collaboration
Learning & Planning
Building the architecture of design system and managing property design tokens
Implementation & Documentation
Creating documenting to explain use cases and design specs to avoid miscommunication between designers and engineers
OBSERVE & RESEARCH
I observed the product closely to identify what it actually needed, what had already been implemented, and what was still missing
I look back to every component across the projects one by one. Colors, naming, sizing, pattern, none of it followed the same logic twice inconsistent/confusing naming. It was a small thing, but it added friction and slowed to every sprint
Designers and engineers were rebuilding the same component interactions on every new project with tight deadlines. I discussed with the team, the real pain point was clear: every project meant starting a (new) design system from scratch instead of building on what already existed. What we needed wasn't another one-off system, but one flexible enough to rebrand, scale, and expand without redoing the same work each time
LEARN & PLAN
I aimed to create a flexible, scalable, and efficient design system that have ability to rebrandable, consistent, and expandable-rather than starting a new design system every time
I also started learning about design tokens, as they make it easier to create consistent and meaningful names across the system. Instead of referring to colours by their raw values, MIDDS uses semantic tokens to describe their purpose and role. This makes communication easier across designers and developers, while also making the system more scalable and easier to maintain. Each token has a unique name and value, the structure helps MIDDS keep tokens predictable, reusable, and easy to understand across both design and development
MIDDS system architecture has two main layers based on my team’s needs: Foundation and Components. Foundation contains design tokens that represent the brand’s visual style. It focuses on styling and makes the system flexible and easy to rebrand when needed. Components represent reusable UI elements and interactions. This layer is built to be scalable and expandable as the product grows
IMPLEMENTATION & DOCUMENTATION
I turned that structure into reusable tokens, defined component behavior, and documented the use cases
Tokens handle the brand foundations, color, typography, iconography, elevation, spacing, so rebranding is a matter of updating the values, not redesigning every component. I defined component behavior around what products actually needed like states, validation, content rules. And I documented the use cases behind
Turn foundation decisions into variables and tokens that represent the brand’s visual style, such as colors, typography, iconography, elevation, radius, grid, shadow, and spacing. These tokens act as the single source of truth for the brand’s visual language. When rebranding, we only need to update the foundation token values, and the changes can be applied across the system without redesigning each component from scratch
With the foundations and tokens set up, I moved on to how components actually behave. MIDDS components should solve real product needs, so I started with defining what the component needs to do, it might need a label, helper text, validation feedback, a required indicator, icon slots and states for focus, error, disabled and read-only behavior
A component should solves a recurring problem, has a clear purpose and benefits from shared management. I document the decisions behind, not just assets. I write down what it's for, where it should and shouldn't be used, what states it supports, content rules, accessibility, and any exceptions people need to know about
CONCLUSION & IMPACT
MIDDS helps designers and engineers collaborated quickly to produce design system to meet client brand styles and requirements
This system speeds up our design process, keeps branding flexible, and makes design-development more efficient while ensuring rebrandable, consistency, and expandable
170+
Total Numbers of Components
2:1
WCAG 2.1 Level AA contrast ratio
35%
Faster deliver to engineer