The Interaction Model Is The Product

Why your product feels hard to use (and why a redesign won't fix it)

When complex B2B software "feels hard to use," the proposed fix is often a redesign: new visual language, tidier navigation, perhaps a design system to bring order to the components that have multiplied across three years of sprints.

That instinct is understandable. It's also usually wrong.

The Nielsen Norman Group has tested B2B software extensively and found something stark: across the B2B sites NN/g tested, task success sits at 58% — eight points below the average for mainstream websites, despite B2B software carrying far higher financial and operational stakes (NN/g, B2B Usability). That gap doesn't close because the interface looks better. It closes when the software's underlying logic — how it responds to what a user is trying to do — is coherent. Most B2B and enterprise products never had that logic designed as a system in the first place.

NN/g attributes part of this persistence to accountability: B2B products are less directly exposed to the immediate feedback that forces consumer products to fix usability failures. There's no obvious churn event, no conversion drop-off, on the day something is confusing. The cost lands later instead, diffused across support tickets, training budgets and quiet non-adoption. That absence of a fast feedback loop is exactly why the problem compounds for years before anyone names it correctly.

The interaction model: the layer beneath the screens

The interaction model is the logic that governs how software responds to user intent — across every state, every context, every type of user, before a single screen has been drawn. It sits upstream of information architecture, which sits upstream of visual design. Get the model wrong and no amount of visual polish downstream will correct it, because the incoherence isn't visible in any one screen. It's visible in the relationships between screens: what happens when a user does something the system didn't anticipate, how state persists (or doesn't) as they move between tasks, whether the same action means the same thing everywhere it appears.

Most redesign engagements start at the visual layer because that's the layer clients can see and describe. "The navigation is cluttered." "It looks dated." Those are real complaints, but they're usually symptoms. The actual defect is further upstream, in decisions — or absences of decision — about how the system is meant to behave.

The signal I look for is whether the difficulty survives a change of presentation. If people can state what they want but cannot predict what the system will do — whether a selection persists, which object owns an action, or what a status change affects — I treat it as an interaction-model problem. If the behaviour makes sense once the right control or hierarchy is visible, it is more likely a visual or information-architecture problem. I make the distinction concrete by mapping one core task as states and transitions, including recovery, then showing where the current rules contradict one another. That gives a client something more useful than an argument about taste: we can see whether a visual redesign would change the behaviour causing the support burden.

How features accumulate into incoherence

No one sets out to build an incoherent product. It happens sprint by sprint. A feature ships to solve one customer's problem, using whatever pattern was fastest to build. Six months later, a related feature ships from a different team, solving an adjacent problem with a different pattern. Neither decision was wrong in isolation. Together, they produce what's best described as interaction debt: navigation that mirrors the org chart rather than the user's task, state that behaves inconsistently depending on which part of the product you're in, and a mental model the user has to reconstruct every time they move between features.

Across the products I've designed, the same failures recur: navigation follows the organisation or underlying systems rather than the user's job; the same object behaves differently depending on where it was opened; filters, selections or draft state disappear when the user moves between related tasks; and important exceptions are bolted on as one-off flows. Another common failure is treating every user as either a novice or an expert. In practice, people are expert in one part of a workflow and new to another. The model has to keep its rules stable while revealing depth progressively, or each new feature makes the product harder to learn.

ACM's Interactions literature makes the underlying mechanism explicit: complex software requires users to build a cognitive model of how the system works, and expert fluency only emerges when that underlying logic is consistent and learnable (ACM Interactions, Architects of Information). When the model is inconsistent, users never graduate from effortful navigation to fluent use. They stay in training mode indefinitely — which is precisely what shows up downstream as high support ticket volume and dependence on onboarding. Gartner's B2B buyer research, still widely cited via Stripe, finds that access to customer support and personalised training are the two things B2B software buyers value most in onboarding (Stripe, How to reduce churn in SaaS) — a proxy for products that were never designed to be self-explanatory.

Why AI-generated UI makes the problem worse, not better

In 2026, there's a tempting shortcut available that wasn't there three years ago: prompt-to-UI generation. These tools can produce plausible screens quickly. That speed is real — but it is speed of screen production, not a gain in coherence. A systematic literature review published in Computers (MDPI, April 2026) documents that generative no-code and prompt-to-UI tools produce substantially different interface outcomes from identical prompts — even across repeated runs of the same tool (MDPI Computers, Design Behaviour and Interface Consistency in Generative No-Code Tools). There is no mechanism in these tools for enforcing interaction coherence across a product, because coherence isn't a property of any individual screen. It's a property of the relationships between screens — the thing the tool was never asked to reason about.

This is the trap for 2026: it's now trivially easy to produce something that looks finished. NN/g's 2026 State of UX report states this directly — "surface-level design won't be enough to stay competitive," and teams "just slapping together components from a design system" are, in NN/g's own words, "already replaceable by AI" (NN/g, State of UX 2026). The differentiator the field itself now names is depth of interaction thinking, not visual execution. AI-generated UI accelerates the exact failure mode this article is describing: visual consistency without interaction coherence, produced faster than ever.

Design system refresh vs. interaction architecture: different scopes, different outcomes

This is the decision most founders are actually making when they say "we need a redesign," without realising there are two different things on offer.

A design system refresh standardises the visual and component layer — colours, spacing, typography, a shared button. It's valuable, and it's often necessary. But it governs appearance, not behaviour. A product can be perfectly consistent visually and still be interaction-incoherent: the same button style used to mean three different things in three different contexts.

An interaction architecture engagement addresses the model itself — the logic of how the system responds to intent, before any screen exists. It's a different scope, a different duration, and it produces a different set of artefacts: not mockups, but the rules the mockups will later have to obey.

Most clients can't distinguish between these two engagements without help, because both are described, in a sales conversation, as "redesign." That's the conversation this article exists to enable.

Designing the model before the screens

Designing that model starts with recognising who it actually has to serve. NN/g's guidance on designing for complex applications makes a related point that's easy to miss: users of complex software don't sort neatly into "novice" and "expert." Most sit somewhere across a spectrum NN/g calls Legacy, Legend and Learner users, each with different needs from the same interaction logic (NN/g, Designing Complex Applications). A model designed for only one of those groups will fail the others regardless of how the screens are styled. This is why interaction architecture, not visual design, has to be the first commitment — it's the layer that has to work for everyone using the product, not just the persona in the deck.

My process begins with the language and objects of the product, not a screen inventory. I map the actors, their goals, the core objects they act on, the states those objects can enter, and the transitions between them — including permissions, failures and recovery. The working artefacts are usually a domain map, task and state flows, a behaviour matrix for rules that must stay invariant, and a decision log for trade-offs. I prototype representative journeys with realistic data before adding visual finish, deliberately testing edge cases as well as the happy path. Clients validate the model through task walkthroughs: can they predict what happens next, does the language match the business, and do exceptions resolve without creating a new rule? Only once those answers are stable do I turn the model into screen architecture and reusable component behaviour.

The common objection here is that this takes time the team doesn't have. It's worth being precise about what that trade-off actually is: the cost of skipping the model isn't avoided, it's deferred and converted into support tickets, mandatory training, and the specific kind of churn that shows up months after a customer has already decided the product is more trouble than it's worth. The question isn't whether the cost gets paid. It's whether it's paid once, upstream, in a designed model — or continuously, downstream, in the cost of running the product for users who never quite learn it.

The diagnostic question every founder should ask before commissioning a redesign

Before scoping any engagement, it's worth asking one question honestly: if every screen in the product were rebuilt with a beautiful, consistent design system tomorrow, would the support tickets stop? Would users stop needing training to complete their core tasks?

If the answer is no — if the problem would simply look better while behaving exactly as confusingly as before — the defect isn't in the interface. It's in the model underneath it. That's not a problem AI-generated components will solve, however fast they ship. It's a problem that has to be designed, deliberately, before the first screen is drawn.

That's the scope conversation worth having before any redesign is commissioned — and it's the starting point for how we approach product design work: as an interaction architecture problem first, a visual one second.