Design Systems For Enterprise SaaS: Why Ad-Hoc UI Stops Scaling
A design system looks optional until a security platform's tenth surface ships with its own patterns and nobody can explain what changed.
A security platform’s first dashboard gets real design attention. The fifth one gets whatever pattern was handy that sprint.
By the twentieth screen, nobody remembers why the alert badge is red in one view and orange in another. That’s not a bug. It’s what happens when UI decisions get made one feature at a time, forever.
Where Ad-Hoc UI Starts To Cost You
Every product accumulates small inconsistencies. In isolation, none of them matter.
The pattern compounds with headcount. That’s exactly the shape of a growing security platform: detection, response, reporting, and admin, each built by a different team on its own timeline.
Intercom’s design team found a blunt way to measure the damage this creates. Their messaging product carried twice as many support conversations tagged for confusion as any other part of the product. That gap traced back to workflows that looked similar but behaved differently screen to screen, according to Intercom’s framework for tackling design debt.
Fixing it wasn’t free, but it paid back fast. Confusion-tagged conversations dropped 33 percent once the inconsistencies got addressed systematically instead of screen by screen.
The same math shows up in engineering timelines. One feature Intercom expected to take five weeks took five months, because nothing in the existing UI could be reused as-is.
Consistency Isn’t A Polish Problem
Jakob’s Law holds that people spend most of their time on products other than yours. Their expectations travel with them into your interface. NN/g’s usability heuristics list consistency and standards as one of ten foundational rules for that reason. Users shouldn’t have to wonder whether different words, situations, or actions mean the same thing.
A design system does more than make a product look coherent. It enforces that one control means the same thing, in the same place, everywhere it shows up.
For a security platform, that consistency isn’t cosmetic. An analyst moving from an alert queue to an investigation view is already carrying a full working-memory load. A UI that reintroduces a decision it already resolved somewhere else adds friction at the exact moment attention is scarcest.
The Resourcing Trap
Most teams that build a design system don’t fail at the component library. They fail at getting anyone to use it.
zeroheight’s fifth annual Design Systems Report surveyed 147 practitioners. It found that only 7 percent of organizations report full adoption across every team, with another 38 percent getting moderate adoption from some. Driving adoption has been the top challenge for five years running, according to the 2026 Design Systems Report.
The report’s sharpest finding names the real failure mode: trust was never the problem, usage was. Trust measured high, at 91 percent. Buy-in satisfaction fell from 42 percent to 32 percent in a single year.
That drop tracks with staffing. Sixty-one percent of teams call themselves understaffed, which means the system shrinks in scope right when more product surfaces need it to cover more ground.
What The Business Case Actually Looks Like
Treating a design system as a design nicety is how it lands first on the cut list. Treating it as infrastructure changes the conversation.
Freshworks tied its design system to a 28 percent reduction in customer service costs and faster ticket resolution. Grammarly’s internal survey found the system saved design and engineering teams a quarter of their work week. Both numbers come from Figma’s reporting on the business case for design systems.
SAP went further and put its design system on the board’s own scorecard, tracked through company-wide OKRs instead of a design team’s internal roadmap. It backs that scorecard with more than a million data points pulled from in-app surveys, enough to catch drift before it reaches a sprint review. That shift, from a tool designers maintain to a metric executives own, is what keeps the budget alive past the first year.
At one company Figma profiled, the engineering team asked to trade future headcount for more design system investment instead. That’s a strong signal from the people usually asking a design system to get out of their way.
Building It Without Stalling Out
A full component library built before anyone needs it is a common way to burn a year of budget with nothing live. Start where the inconsistency already costs something measurable: the screen with the highest support volume, or the slowest feature cycle.
That’s close to the three-step approach Intercom settled on. First, visualize where the inconsistencies live. Then build the business case with real confusion and engineering-time data. Finally, choose between fixing it screen by screen or rebuilding the pattern once and migrating everything onto it.
Whichever approach a team picks, it needs a sponsor outside the design team. A system with no executive backing is the first thing cut when the roadmap tightens, no matter how good the components are.
The Caraballo Group builds design systems for security SaaS platforms that have outgrown ad-hoc UI, so the tenth dashboard ships consistent instead of improvised. If your newest screen doesn’t look related to your first one, book a call to talk about what a system would take.
Photo by Markus Winkler on Unsplash.