Beyond Default: How a Junior Dev Challenged the Status Quo and Reshaped a Production Design System

There is a terrifying quietness that comes with being the newest, most junior person in the room. You listen, you nod, and you execute what is given to you. You are there to learn, not to lead.

At least, that is what the industry tells you.

When I joined SELISE, my very first assignment was a high-stakes production project. The timeline was tight. The roadmap was set. Most importantly, the design phase was effectively finished in Figma. Development was scheduled to kick off within the week.

On paper, everything looked "ready." But when I looked at the prototypes, something felt wrong.

The Problem: The "Enterprise" Trap

The UI followed the default Material UI (MUI) guidelines to the letter. If you have worked in the React ecosystem long enough, you know exactly what I’m talking about.

Heavy, distracting shadows (elevation) that muddy the visual hierarchy.
Boxy, rigid surfaces that feel clinical rather than welcoming.
The "Google 2018" aesthetic: Functional, yes. But it lacked soul.

It wasn't technically wrong. It was usable. But this was a product meant to scale, meant to compete, and meant to feel premium. The default MUI styling felt dated before a single line of code was written. It felt like an internal dashboard, not a modern digital product.

I had a nagging feeling: If we build it like this, we’re going to be refactoring the UI in six months.

The Junior’s Dilemma

Here was the conflict. I was the new hire. I was the junior. The designs had already been approved by management and signed off by the design team. Who was I to walk in and say, "I think we can do better"?

Impostor syndrome hit hard. I debated staying quiet. It’s easier to just build the tickets in Jira. But I cared too much about the craftsmanship to let it slide.

I decided to take a gamble. I walked up to the Project Manager. I didn't come with complaints; I came with a question.

"What if we don’t stick to native MUI styling? I think we can make this look much better without wrecking the timeline."

In many companies, this is where I would have been shut down. Stay in your lane. We don't have the budget. Instead, he did something that changed the trajectory of my time there: He trusted me.

The Technical Solution: Minimals.cc

I didn't want to reinvent the wheel. Writing a design system from scratch would have been irresponsible given the deadline. I needed a middle ground—something that used the MUI infrastructure we needed but abandoned its visual baggage.

I proposed Minimals.cc.

For the uninitiated, Minimals isn't just a "template." It is a sophisticated design system built on top of Material UI. It takes the robust logic of MUI (the grid system, the component API, the accessibility) and overlays a highly opinionated, modern aesthetic.

I wasn't proposing a redesign. I was proposing a design evolution.

Typography: Moving away from standard Roboto to clearer, punchier font stacks.
Shadows: Replacing black, diffuse shadows with colored, directional shadows that create depth without dirtiness.
Spacing: A softer, more breathable grid.

The Challenge: Integration is Not "Plug and Play"

The PM gave me a very short window to prove this could work. There was no time for meetings. I had to code my way to a solution.

Many developers think using a kit like Minimals is just "copy-pasting components." It isn't. To integrate a complex design system into an existing enterprise architecture, I had to dive deep into the MUI theming engine.

I had to manually:

Deconstruct the Theme Provider: I stripped out the default MUI theme and injected the Minimals custom theme object, ensuring it played nice with our existing Redux state.
Override Component Defaults: I had to understand how components overrides worked in MUI v5 vs v4. I wasn't just changing colors; I was rewriting the default props for Buttons, Cards, and Inputs globally to ensure consistency.
Map Design Tokens: I had to map our brand colors to the semantic tokens (primary, info, success, warning) that the new system expected.

It was a weekend of deep technical work. I wasn't just "styling"; I was building the frontend infrastructure that the rest of the team would rely on for the next two years.

The Moment of Truth

Monday came. I demoed the new look to the team.

I didn't show static screenshots. I showed them a live, interactive build. The buttons had subtle bounces. The cards floated rather than sat heavy on the page. The inputs felt tactile.

The reaction was immediate.

It wasn't just that it looked "pretty." It felt product-ready. It looked expensive. It looked like 2024, not 2018.

The impact was larger than I anticipated:

The Designer Converted: The lead designer liked the live code so much that they went back into Figma and updated the design system to match my implementation. Usually, code follows design. In this case, design followed code.
The Standard Shifted: The product design shifted permanently toward this cleaner aesthetic.
The Legacy: That codebase is still in production today. It hasn't aged. It doesn't look like legacy code. It still looks clean, modern, and confident.

What This Taught Me

Looking back, that risk defined my career as a Frontend Engineer. It taught me that titles are arbitrary when it comes to good ideas.

To any junior developer reading this: You do not need permission to have taste.

You don't need to be a Senior Architect to see that a user experience is lacking. However, you do need three things to make a change:

A Clear Vision: Don't just say "it's ugly." Have a specific alternative.
Technical Competence: You must be able to build what you propose. Ideas are cheap; execution is everything.
The Courage to Prototype: Don't argue in Slack. Build a demo. Code wins arguments.

I didn't just build what was given to me at SELISE. I built infrastructure. I built longevity. And most importantly, I built trust.

Key Takeaway for Devs

Default UI ≠ Good UI. Design systems are technical decisions, not just visual ones. If you believe in an improvement, build the prototype and show them why it matters.