Why Software UI Won't Settle

The steering wheel stabilized in about fifteen years. From Vacheron's first wheel-steered Panhard in 1894 to the 1910s, automakers converged on round wheel, floor pedals, left-hand mount. By the 1930s, the basic layout was fixed. By the 1960s, regulation had locked it in.

Why hasn't software done the same? Payroll systems have been around since the 1960s. Accounting software since the 1970s. We've had sixty years to figure out the right shape for a general ledger screen. Instead, every SaaS accounting product ships a novel interface.

The standard answer is that software is younger, or more complex, or that we haven't found the right patterns yet. None of these hold up. Cars are extraordinarily complex electromechanical systems. The sixty-year head start should have been enough. And the patterns are known — tables, forms, filters, CRUD — the primitives have been stable since the 1980s. The question isn't what the patterns are. It's why they don't stick.

Two layers

A car gets restyled dashboards, new trim materials, ambient lighting every other year. The pedals haven't moved since Eisenhower.

Physical products have two distinct layers: an aesthetic layer that absorbs novelty, and a control layer that resists it. The separation is enforced by the medium itself. You can restyle a dashboard bezel without moving the steering column because they're different physical components, manufactured differently, constrained differently. The aesthetic layer is sheet metal and plastic — relatively cheap to retool. The control layer is linkages, motors, wiring harnesses — expensive to move. Novelty flows where it's economical to do so.

In a UI these two layers aren't distinct. The pixels that display the brand identity are the pixels that receive user input. There is no bezel to restyle without moving the buttons, because the bezel is the buttons. When a designer "refreshes" a SaaS product, they're necessarily reshaping the control surface — that's all there is to reshape.

This is the structural problem. It's not just that software change is cheap (though it is). It's that software has no natural boundary between the part you're allowed to change and the part you shouldn't. Apple Liquid Glass - I'm looking at you!

A/B testing retards convergence

You'd think A/B testing would accelerate convergence — run the experiments, find the optimum, lock it in. But A/B testing optimizes locally per product, not globally across the medium.

Intuit A/B tests QuickBooks. Xero A/B tests Xero. FreshBooks A/B tests FreshBooks. Each converges on its own local optimum. But the local optima are different because the starting points are different, the user bases are different, the metrics are different. A/B testing is a hill-climbing algorithm, and hill-climbing algorithms find the nearest peak, not the highest one.

Cars had a different selection mechanism: customers who had driven one car expected the next car to work the same way. The switching cost imposed a global constraint. A/B testing doesn't do this because users rarely switch accounting software — and because the test optimizes for the buyer's experience (conversion, engagement, wow), not the user's experience (the accounts payable clerk who does the same twelve clicks four hundred times a day and needs every one of them to be where it was yesterday).

Where software does converge

Software has converged at data interchange formats: .docx, .pdf, .html, and they stabilize for the same reason car pedals stabilize: the cost of incompatibility exceeds the cost of conformity. If your file doesn't open on my machine, we can't collaborate. The forcing function is immediate and absolute.

But interchange convergence only operates between systems. Inside the boundary — inside the application — there's no real pressure to work towards a standardized UI. As Chat surfaces gain the capability to generate UI on the fly, we could go through a cambrian explosion of UI designs.

And now even cars are de-converging

Tesla put the turn signals on a touchscreen. The physical constraint that forced convergence is disappearing from cars too, now that dashboards are screens. When the control surface becomes software, it inherits software's economics.

What would make it settle

The question isn't "why hasn't software UI settled?" It's "what would make it?" The answer has two parts: a cost to change, and a layer boundary to protect the control surface from aesthetic churn.

Regulation could provide the first. Accessibility standards are the closest thing software has to the 1966 Safety Act, and they have driven convergence — screen reader compatibility imposes real constraints on layout. But WCAG is narrow. Nobody's mandating that all accounting software use the same chart-of-accounts interaction pattern.

Design systems could provide the second — if they separated "this is how we look" from "this is how the user controls the system" and made the control layer expensive to change. But design systems are per-organization, not per-industry. And they rarely distinguish between aesthetic tokens (colors, spacing, typography) and control topology (where the buttons are, what they do, in what order). They style the surface uniformly instead of protecting part of it from change.

The COBOL green-screen was stable — not because it was good, but because the medium had no aesthetic layer at all. There was nothing to restyle, so the control surface sat undisturbed for decades. We traded that for a medium where the aesthetic layer and the control layer are the same pixels on the same screen. Every refresh is a reshaping. Every redesign moves the pedals.

But the diagnosis contains the prescription. If the problem is collapsed layers, the fix is to re-separate them — deliberately, since the medium won't do it for you. Define the control topology (what the user can do, where, in what sequence) as an artifact that's expensive to change: reviewed, versioned, protected by process. Let the aesthetic layer (color, type, spacing, motion) flow freely around it. The pedals don't move. The dashboard gets restyled every season. CSS already hints at this separation. Design systems could enforce it — if they stopped treating every pixel as equally mutable and started treating control topology the way engineers treat an API contract: change it when you mean to, never by accident.