For the last 40 years, software UIs have been built around one assumption:
Humans interact.
Humans read.
Humans navigate.
That assumption is breaking.
Software UIs were designed for a world where the only sensible way for humans to interact with the software was to use its graphical interface. Buttons, menus, dashboards, forms. Since then, every software UI has become a maze that requires onboarding, tutorials, support tickets, help docs, and training videos just to function.
We normalized this friction. We called the reduction of friction as improving “UX.”
But the cracks are obvious.
One-Size-Fits-All Interfaces Were a Workaround
The graphical user interface was a breakthrough in the 1980s. It allowed humans to interact with complex systems visually rather than through command lines.
But it was always a workaround.
It assumed that:
Humans must learn the structure of a system
Humans must remember where capabilities live
Humans must manually navigate state transitions
In early desktop software, this was manageable. A word processor had a limited feature set. An accounting tool had a defined workflow.
Modern SaaS is different.
Take a typical B2B SaaS product today:
200+ settings across multiple tabs
Role-based permissions
Integration panels
Analytics dashboards
Nested configuration flows
A new administrator onboarding into such a system is not just learning features. They are learning a map.
The product does not adapt to their intent. They adapt to the product’s architecture.
That inversion is the core problem.
A Concrete Example: Exporting Data
Consider something simple: exporting last quarter revenue data.
In many tools, this requires:
Navigating to the analytics dashboard
Selecting the correct date range
Filtering by the appropriate segment
Locating the export button
Choosing file format
Confirming permissions
Waiting for asynchronous processing
If one filter is missed, the export is wrong.
If the permission is misconfigured, the user sees an error.
If the export button is buried under a dropdown, they open a support ticket.
Nothing about the business intent is complex. “Export last quarter revenue.”
The complexity exists because the user must manually orchestrate the UI.
The interface is not helping. It is mediating.
Support Is a Symptom of UI
Why do support tickets exist?
Often not because the system is broken, but because the user cannot translate their goal into the correct sequence of actions.
Examples:
“I invited a teammate but they cannot access the dashboard.”
Root cause: a role permission buried in a secondary settings panel.“The integration is not syncing.”
Root cause: a configuration checkbox hidden under advanced settings.“Where do I update billing details?”
Root cause: billing separated from account settings and nested under a separate subdomain.
These are not intelligence problems.
They are navigation problems.
And navigation problems scale linearly with product complexity.
As feature count increases, the probability that a user fails to find the right flow increases.
QA Is Also a UI Problem
Most QA processes today are built around UI traversal.
Testers:
Click through forms
Submit invalid inputs
Toggle configuration states
Verify visual outputs
But as feature combinations grow, the number of possible state permutations grows exponentially.
For example:
5 roles
4 subscription tiers
6 feature flags
3 integration states
That alone creates hundreds of state combinations. Add custom fields, localization, and permissions, and the matrix becomes unmanageable.
UI-driven QA struggles not because teams are inefficient, but because the interface hides system logic behind screens.
Testing becomes about reproducing flows instead of understanding system behavior.
The Fix: Simulate How People Use The System
A different model emerges when we stop treating the UI as the primary object.
Instead of asking, “Does this screen work?” we ask, “Does this capability work across states?”
Instead of manually clicking through flows, we simulate them. Whichever sequence of actions that work, then becomes the way to achieve that task. If none of the attempts work, then it’s likely that there’s a bug. Then the optimization goal flips to reducing the steps-to-completion and time-to-completion of critical features, and having reliable guidance for the rest.
For example:
Simulate creating a new workspace under each subscription tier
Simulate inviting users under each role
Simulate triggering integration syncs under different network conditions
Simulate onboarding without documentation
The system becomes testable as behavior, not as pages.
This reframes QA from reactive checking to proactive exploration.
The Bonus: Simulate How People React to The System
But simulating the system alone is not enough.
The deeper insight is that friction often lives at the intersection between system structure and user intent.
So instead of just simulating features, we simulate users.
Specific personas.
For example:
Persona A: First-time founder, non-technical, onboarding a new workspace
Persona B: Operations manager integrating CRM and billing
Persona C: Enterprise admin configuring permissions for 200 employees
Now remove training material.
Let these simulated personas attempt real tasks:
Invite a teammate and assign correct access
Configure a third-party integration
Generate a compliance report
Update billing information
Measure:
How many steps it takes
How often the persona changes direction
Where they pause
Whether they activate the in-product support widget
Whether the support interaction reduces step count
Now introduce variation.
Enable Zendesk in one version.
Enable an AI assistant in another.
Embed contextual tooltips in a third.
Run identical persona simulations.
Compare:
Task completion rate
Average step count
Time to resolution
Support dependency
Drop-off probability
This transforms support from a reactive cost center into a measurable design variable.
It allows companies to test not just UI layout, but support architecture itself.
Why This Makes UI Secondary
In this model, the UI is no longer the core product.
It becomes one layer in a larger behavioral system.
The primary object of analysis becomes:
Intent
State
Outcome
The screen is simply a surface through which state transitions occur.
When companies can simulate:
How their system behaves
How different personas interact with it
How support layers influence outcomes
They stop optimizing for aesthetics and start optimizing for success probability.
That is when UI stops being central.
It does not disappear overnight. But it loses its monopoly on value.
What Comes After
The next phase is intent-driven systems.
Instead of teaching users where things live, systems interpret goals directly.
“Generate a Q4 revenue report for EMEA.”
The system then works with the requester to:
Identify the relevant dataset
Apply the correct filters
Validate permissions
Export the data
Generate the report
No manual traversal required, just a casual chat, over text or call.
In such systems:
Documentation becomes generated from execution traces.
QA becomes continuous scenario simulation.
Support becomes embedded logic rather than a separate team.
The interface remains as a transparency layer, not a navigation requirement.
A Final Note
We are still early in this transition.
Most products are UI-first because that is how software has always been built.
If product managers could, through simulation, gauge the correctness of software flows (QA), and gauge the perception of users interacting with it (CX), they can make bold decisions with conviction, as they’ve simulated the outcome apriori.
At Marketrix, we are exploring this shift by combining UI-operating simulations with persona-based user simulations to help companies understand whether their software actually enables users to succeed, and how different support layers influence that success.
The UI era taught us how to design screens.
The next era will teach us how to design systems that do not require them.