TL;DR:
We treat frontend like backend - abstracting UI into patterns that don’t match how designs actually evolve. Stop trying to make your UI scalable. Instead, make it adaptable. This post breaks down why your frontend abstractions keep failing — and what to do instead.
After working across several UI applications from scrappy personal projects, startups-scale mobile applications and to Big Tech enterprise CRMs, one thing keeps bothering me: we treat frontend like backend.
I’ve studied all the usual design patterns to clear interviews: factory, strategy, builder, proxy, facade... the works. And I’ve seen these abstractions leak into frontend codebases where they don’t belong.
We try to scale, abstract, and over engineer - and we forget that UI doesn’t reward elegance. It rewards the ability to iterate, and to adapt.
The issue? People are too eager to treat UI the same way they treat backend systems - with abstraction, encapsulation, and DRY principles - without acknowledging that the rate and nature of change in UI is fundamentally different.
UI is Designed to Break
The most fragile part of your stack is your UI. One small tweak in Figma can undo days of “architectural scaffolding”. Yet people still keep trying to create “smart” abstractions: reusable components, nested sections, configurable UIs with metadata-driven rendering.
It sounds elegant. Until it isn’t.
Yes, you should abstract at the foundational level: design tokens, layout primitives, interaction patterns - the building blocks that rarely change.
I love:
- Tailwind for utility-based layout
- Fluent UI v9 for structured component reuse
That’s where abstraction belongs.
Figma Doesn’t Care About Your Abstractions
Designers don’t think in patterns.
They think in flow, hierarchy, narrative. When they move a section around, introduce a banner between specific bullets, or redesign one screen - your abstraction breaks.
So you patch it. You add metadata. You build config-based rendering. You invent more patterns. Before long, you’ve created a custom CMS inside your React app.
Before your content payload looked like -
[
"This is point #1",
"This is rendered as bullet point list within a section",
"Great!"
]
Now it looks like -
[
{ type: "BULLET", content: "This is point #1" },
{ type: "BANNER_SMALL", image: "https://link.to/the/small/banner", alt: "this is an image of your small banner", maxVersionToShowOn: "1.9.0" },
{ type: "BULLET", content: "Not so great :(" }
]
Then the new engineer arrives. They need to implement a small change. But first, they have to reverse-engineer your abstraction. They ask:
“How is this page rendered again?”
“Why is the footer wrapped inside a section factory?”
“Why is the banner conditionally injected via content metadata?”
The answer is: because the team prematurely abstracted everything into patterns that looked elegant once, but are painful forever.
The Cost of Abstraction is Underestimated
Design changes more frequently than business logic.
Your database schema might stay stable for months. Your Figma file changes every 2 weeks.
But frontend abstraction assumes the opposite: that content is stable, and structure is sacred.
That’s just not how UI works. The result?
- Engineers fear touching the UI
- Pages get rebuilt from scratch
- Abstractions go stale
- Designers are told: “This isn’t feasible”
- Innovation slows down
UI is a Canvas to Iterate, not a System to Scale
We need to stop over-engineering the frontend. Your UI doesn’t need to be scalable. It needs to be navigable, editable, and fast to iterate on.
- Favor composition over abstraction
- Favor readability over DRY
- Favor changeability over structure
KISS - Keep It Super Simple.
Treat design as the primary driver. Build for change, not for elegance. Your abstraction won’t save you when the banner moves.
💡 Takeaways:
- Abstract slowly, especially in the UI.
- Prioritize readability and adaptability.
- Align your component design with the rate of change in design, not backend logic.
- KISS still wins — even in 2025.