So, is it really difficult to custom MUI for developers?
A short experiment exploring whether design system customisation is actually difficult to build.
First of all, this is work in progress project
1. Context
Many times while working on design systems, I heard the same feedback:
“Customisation is difficult.”
“Design changes will slow development.”
“The token structure is too complex.”
These comments made me question my own approach.
Was I overcomplicating things? Was I making engineers’ work harder?
To understand this better, I decided to rebuild a design system myself.
Always there’s a disconnection between Designer and Engineer
2. Setup
Recreate a customisable design system using an existing framework.
Tools
- MUI (base framework)
- Claude Code
- Figma library
- Storybook
System structure
- Primitive tokens (colour, spacing, typography, radius)
- Semantic tokens
- Component overrides
- Storybook documentation
3. Building with Claude Code
Instead of writing everything manually, I collaborated with Claude Code.
The process was simple:
- Connect the Figma library
- Provide token definitions
- Define system rules
- Generate component structure
- Review and refine
Whenever mistakes happened, I added new rules to a claude.md file. This file became the rulebook for the project.
Claude reads these rules whenever it builds new components.
4. Initial Results
Within two short sessions (about 4–5 hours each):
I rebuilt:
- Foundations (tokens)
- Semantic token layer
- Base atomic components
- Customised MUI components
Even complex components like TextField—which required structural adjustments—were working.
The system is still evolving, but the core architecture is in place.
5. What I Learned
The biggest lesson from this experiment wasn't about MUI or AI.
It was about language.
I realised many of the tensions I experienced before weren't really about technical difficulty. They were about translation. Designers tend to speak in terms of patterns, visual systems, and user experience. Engineers think in terms of architecture, constraints, and implementation.
Before doing this experiment, I understood the design side of the system very well. Tokens, visual consistency, accessibility, and structure in Figma (I thought I knew quite well about React!).
But once I started rebuilding the system myself, I began to understand the implementation layer more clearly:
- how tokens are actually consumed
- how theme overrides work
- where customisation lives within a framework
- and why certain components feel harder to modify
That shift changed how I think about collaboration.
Coding has always been an intangible fear for me, but now it feels tangible. I can find solutions and navigate my way forward!
Using each one’s language to ship faster!
(also connect)
6. Reflection
This experiment started as a simple question:
Was design system customisation actually difficult to build?
What I discovered is that the difficulty often isn't the customisation itself.
It's the architecture around it.
When the system has:
- clear token structures
- documented rules
- consistent component patterns
- customisation becomes much easier to reason about and implement.
AI helped accelerate the process, but the real enabler was clarity — in both system architecture and communication.
More importantly, this experiment reminded me that design systems aren't just design artifacts or code libraries.
They are collaboration systems.
And the better designers understand how systems are implemented, the easier it becomes for teams to ship faster and work together more effectively.
14 has done, 18 more to go!
Top ↑
So, is it really difficult to custom MUI for developers?
A short experiment exploring whether design system customisation is actually difficult to build.
First of all, this is work in progress project
1. Context
Many times while working on design systems, I heard the same feedback:
“Customisation is difficult.”
“Design changes will slow development.”
“The token structure is too complex.”
These comments made me question my own approach.
Was I overcomplicating things? Was I making engineers’ work harder?
To understand this better, I decided to rebuild a design system myself.
Always there’s a disconnection between Designer and Engineer
2. Setup
Recreate a customisable design system using an existing framework.
Tools
- MUI (base framework)
- Claude Code
- Figma library
- Storybook
System structure
- Primitive tokens (colour, spacing, typography, radius)
- Semantic tokens
- Component overrides
- Storybook documentation
3. Building with Claude Code
Instead of writing everything manually, I collaborated with Claude Code.
The process was simple:
- Connect the Figma library
- Provide token definitions
- Define system rules
- Generate component structure
- Review and refine
Whenever mistakes happened, I added new rules to a claude.md file. This file became the rulebook for the project.
Claude reads these rules whenever it builds new components.
4. Initial Results
Within two short sessions (about 4–5 hours each):
I rebuilt:
- Foundations (tokens)
- Semantic token layer
- Base atomic components
- Customised MUI components
Even complex components like TextField—which required structural adjustments—were working.
The system is still evolving, but the core architecture is in place.
5. What I Learned
The biggest lesson from this experiment wasn't about MUI or AI.
It was about language.
I realised many of the tensions I experienced before weren't really about technical difficulty. They were about translation. Designers tend to speak in terms of patterns, visual systems, and user experience. Engineers think in terms of architecture, constraints, and implementation.
Before doing this experiment, I understood the design side of the system very well. Tokens, visual consistency, accessibility, and structure in Figma (I thought I knew quite well about React!).
But once I started rebuilding the system myself, I began to understand the implementation layer more clearly:
- how tokens are actually consumed
- how theme overrides work
- where customisation lives within a framework
- and why certain components feel harder to modify
That shift changed how I think about collaboration.
Coding has always been an intangible fear for me, but now it feels tangible. I can find solutions and navigate my way forward!
Using each one’s language to ship faster!
(also connect)
6. Reflection
This experiment started as a simple question:
Was design system customisation actually difficult to build?
What I discovered is that the difficulty often isn't the customisation itself.
It's the architecture around it.
When the system has:
- clear token structures
- documented rules
- consistent component patterns
- customisation becomes much easier to reason about and implement.
AI helped accelerate the process, but the real enabler was clarity — in both system architecture and communication.
More importantly, this experiment reminded me that design systems aren't just design artifacts or code libraries.
They are collaboration systems.
And the better designers understand how systems are implemented, the easier it becomes for teams to ship faster and work together more effectively.
14 has done, 18 more to go!
Top ↑
So, is it really difficult to custom MUI for developers?
A short experiment exploring whether design system customisation is actually difficult to build.
First of all, this is work in progress project
1. Context
Many times while working on design systems, I heard the same feedback:
“Customisation is difficult.”
“Design changes will slow development.”
“The token structure is too complex.”
These comments made me question my own approach.
Was I overcomplicating things? Was I making engineers’ work harder?
To understand this better, I decided to rebuild a design system myself.
Always there’s a disconnection between Designer and Engineer
2. Setup
Recreate a customisable design system using an existing framework.
Tools
- MUI (base framework)
- Claude Code
- Figma library
- Storybook
System structure
- Primitive tokens (colour, spacing, typography, radius)
- Semantic tokens
- Component overrides
- Storybook documentation
3. Building with Claude Code
Instead of writing everything manually, I collaborated with Claude Code.
The process was simple:
- Connect the Figma library
- Provide token definitions
- Define system rules
- Generate component structure
- Review and refine
Whenever mistakes happened, I added new rules to a claude.md file. This file became the rulebook for the project.
Claude reads these rules whenever it builds new components.
4. Initial Results
Within two short sessions (about 4–5 hours each):
I rebuilt:
- Foundations (tokens)
- Semantic token layer
- Base atomic components
- Customised MUI components
Even complex components like TextField—which required structural adjustments—were working.
The system is still evolving, but the core architecture is in place.
5. What I Learned
The biggest lesson from this experiment wasn't about MUI or AI.
It was about language.
I realised many of the tensions I experienced before weren't really about technical difficulty. They were about translation. Designers tend to speak in terms of patterns, visual systems, and user experience. Engineers think in terms of architecture, constraints, and implementation.
Before doing this experiment, I understood the design side of the system very well. Tokens, visual consistency, accessibility, and structure in Figma (I thought I knew quite well about React!).
But once I started rebuilding the system myself, I began to understand the implementation layer more clearly:
- how tokens are actually consumed
- how theme overrides work
- where customisation lives within a framework
- and why certain components feel harder to modify
That shift changed how I think about collaboration.
Coding has always been an intangible fear for me, but now it feels tangible. I can find solutions and navigate my way forward!
Using each one’s language to ship faster!
(also connect)
6. Reflection
This experiment started as a simple question:
Was design system customisation actually difficult to build?
What I discovered is that the difficulty often isn't the customisation itself.
It's the architecture around it.
When the system has:
- clear token structures
- documented rules
- consistent component patterns
- customisation becomes much easier to reason about and implement.
AI helped accelerate the process, but the real enabler was clarity — in both system architecture and communication.
More importantly, this experiment reminded me that design systems aren't just design artifacts or code libraries.
They are collaboration systems.
And the better designers understand how systems are implemented, the easier it becomes for teams to ship faster and work together more effectively.
14 has done, 18 more to go!
Top ↑