Thinking About Design Systems as a Utility (feat. the Texas Power Grid)
If you’ve ever disassociated when someone says “design system,” I get it.
You’re trying to ship something real right now, all the time. You’ve got tickets, edge cases, a backlog that never shrinks, a real product with real constraints and real users, and now someone is asking you to use their components, their tokens, their opinions. Cool. Love that dynamic for us, lol.
This post isn’t about convincing you that design systems are good. You already get the concept.
It’s about why we’re taking the time to build a really good one. For Nextpoint.
Because a good one won’t feel like a process tax to use it. It will be a utility that saves you time and reduces decision fatigue. All while maintaining enough flexibility so that designers and engineers on feature teams still get to problem solve. They actually get to spend time on more impactful, higher-level user experience challenges, not to mention the unlocked user testing possibilities …
I digress. Here are the other things I was thinkin’ about. 💭
The problem isn’t skepticism. It’s timing.
On the surface, it can feel like there is resistance to building and adopting a design system. But the engineers I know are very invested in consistency and think deeply about craft.
So, what could it be? I asked, in my Carrie Bradshaw voice.
They’re anti-friction. Thats what makes more sense to me. The trade probably feels like this:
Cost (now):
Learn the system
Work within constraints
Figure out why the “easy thing” isn’t allowed
Potentially confirm your worst fear: the system sucks, isn’t usable, all hype, etc.
Benefit (later, maybe):
Consistency
Maintainability
Velocity at scale
Fewer one-off bugs that force us to look actually understand and talk about how things work
Humans. We are famously bad at optimizing for “later, maybe.”
So the stakes are high for the system to work. When the way we do things today (ie: without a system for designing user interfaces) technically works, well then the slightest friction or confusion around the system probably makes it feel like overhead. Again, you totally get the concept, “but is the design system even done yet?”
That’s a communication failure, not a values mismatch.
It’s not a library, it’s a utility.
Here’s the mental shift that helped me:
A design system is not a collection of components.
It’s shared infrastructure.
More specifically: it’s a utility.
Not in the hand-wavy sense. In the very boring, very practical sense.
Think electricity. Think… Texas.
clears throat
You could build your own power grid.
You might even do it faster at first.
You’d get exactly the voltage you want.
Very bespoke. Very artisanal.
You’d also now be responsible for:
outages
safety
compatibility
scaling
maintenance
explaining to everyone else why your setup is different
At some point, you connect to the grid. Not because it’s exciting—but because it’s sane.
Unless you’re Texas.
That’s the design system.
Engineers already believe in this pattern (just not with UI)
You already accept this logic everywhere else:
You use a standard library instead of re-implementing date handling, localization, or accessibility primitives.
Framework conventions exist so you can reason about unfamiliar code without a guided tour.
You respect API contracts because they let teams move independently and there are consequences for breaking them.
A design system is the same move—but for UI decisions.
It’s an abstraction layer that says:
“Most of these problems have already been solved. Please do not solve them again, slightly differently, under time pressure.”
That’s not design philosophy. That’s operational hygiene.
nothing can slow us down
Will it sometimes feel like using the design system will take longer? Yes. Sometimes. Briefly, but wait -
Utilities trade local optimization for global leverage.
The system might make the first 10% of a task slower:
fewer degrees of freedom
more deliberate choices
slightly more setup
What it buys you is:
less surface area for bugs
fewer regressions from “harmless” changes
predictable behavior across the app
UI you don’t have to re-think every sprint
If it’s always slower, that’s a system problem but there are ways to structure the system that help make it efficient to use.
If it’s occasionally slower, that’s just infrastructure doing its job.
It can’t be a side quest
This is the part that usually goes unsaid.
When someone asks engineers to “support the design system,” it can sound like:
extra work for someone else’s roadmap
What it actually is:
paying into shared infrastructure so your future work is cheaper
Every ui bug fixed at the system level
Every edge case handled once
Every component improved instead of forked
That’s compound interest. ❤️❤️❤️
You don’t feel it immediately.
You really feel it a year later.
The quiet promise of a good design system
When a design system is working, a few things happen almost invisibly:
Engineers stop debating UI minutiae in PRs
Product conversations move up a level
Design feedback gets sharper, not louder
Shipping feels… calmer
Not because everyone agrees—but because fewer decisions need to be re-litigated.
That’s the real value.
Not consistency for its own sake.
Not “design maturity.”
But far fewer accidental consequences and more leverage.
One honest caveat
It’s understandable to have concerns that the design system is going to be:
a bottleneck
a dumping ground
a one-way door with no escape hatches
The skepticism is justified. But that’s not what we’re building.
Utilities only work when they’re reliable, well-maintained, and responsive to real usage. Otherwise, people start running generators in the backyard again. You can’t blame them.
