Most B2B software does not fail because the UI is ugly. It fails because the product model is wrong.
The buttons may be tidy and the tables may be perfectly respectable. But beneath the interface, people are trying to manage work that does not fit the structure the software gives them. They create duplicate records, lose track of the current document, make decisions from stale data and move between tabs, emails and spreadsheets to reconstruct context.
That is where the real UX problem lives. In complex operational products, the interface is only the visible layer of a deeper system: business rules, permissions, approvals, pricing logic, documents, integrations, statuses, teams, exceptions, history and auditability.
I encountered this in its purest form while redesigning the Aerios carrier marketplace, a charter management platform for airlines and charter teams. Aerios was not simply a quoting tool. It supported a commercial and operational lifecycle across requests, quotes, bookings, documents, invoices, contracts, aircraft, pricing, customers, approvals and integrations. The challenge was not to repaint the screens. It was to redesign the product’s mental model.
Complex products are not collections of pages
A common B2B SaaS mistake is to give each product object its own destination: requests have a page, quotes have a page, bookings have a page, invoices have a page and contracts have a page. On paper, that is sensible. It mirrors the database and gives navigation a neat explanation.
But users do not experience their work as database objects. They experience it as a journey.
At Aerios, a charter request remained relevant after a quote was created. A quote did not become irrelevant when a booking was confirmed. The booking still needed its original commercial context; an invoice needed to relate back to the quote; a contract needed to confirm what was agreed. The user was not managing pages. They were managing a transaction.
That distinction changes everything. When the product treats each object as isolated, the user has to do the joining work. They compare references, hunt for the latest state, check email, ask colleagues and rebuild the story manually. In high-value commercial workflows, that does not just make a task slower. It weakens trust in the system.
The first design principle: follow the object of work
One question became especially useful in the Aerios work: what is the user actually trying to move forward?
Not which screen are they using. Not which feature are they clicking. Not which table are we updating. What are they progressing?
For Aerios, the answer was rarely “a quote” or “a booking” in isolation. It was the movement from enquiry to confirmed work to financial output. That required a stronger transaction model: a conceptual thread that keeps related records connected through the lifecycle without forcing every screen to show everything at once.
Requests represent early-stage intent.
Quotes represent commercial proposals.
Bookings represent operational commitments.
Invoices represent financial records.
Contracts represent legal and commercial confirmation.
Transactions provide the connective tissue.
This is modelling work at the intersection of UX, product strategy and information architecture. It is also where redesigns often go wrong: teams jump into layouts before agreeing what the product actually represents. ISO 9241-210 is useful here because its human-centred-design framing begins with understanding context of use. In complex B2B products, that context includes business process, operational risk, data dependencies and the consequences of system behaviour—not only the user’s immediate goal.
Fragmentation is structural UX debt
Design debt is often discussed as visual inconsistency: different button styles, spacing or type. That matters, but in workflow products the more dangerous debt is structural. It appears when the product grows feature by feature, rather than through a coherent system design.
In the Aerios domain, that risk showed up when similar workflows behaved differently, statuses meant slightly different things in different places, records were difficult to classify as active or historical, and settings threatened to become a dumping ground for every new customer need. That was not the result of careless people. It is the normal consequence of a product moving quickly and responding to customer demand before a mature system has formed around it.
Eventually, speed produces drag. Every new feature becomes harder to place. Each workflow creates edge cases. Every customer request risks another one-off pattern. Engineering slows because the product lacks reusable interaction models, and users begin to feel the seams.
At that point, the design problem is no longer “make this feature better”. It is “reduce the cost of every future feature”. That is why design systems become strategic. They are not only component libraries; they should encode how the product behaves.
At Aerios, a table row was never just a table row
One of the clearest examples was the quote builder. At first glance, a quote builder looks like a form: add a route, aircraft, pricing and line items, then generate a document. In reality, it is a commercial modelling tool.
A serious quote needs to support structured inputs, calculated values, manual overrides, custom line items, taxes and fees, route-level logic, aircraft-specific rules, currency conversion, internal costs, customer-facing outputs, approval logic, document generation and audit history. A quote line in Aerios might be calculated, overridden, manually edited, excluded, imported from an integration, linked to a route leg or changed after confirmation.
That is not a simple component problem. It is a system-behaviour problem.
The goal was not to pretend the complexity did not exist. It was to structure it:
Start with the common workflow and set sensible defaults.
Reveal advanced controls when they are needed rather than making every user confront every option.
Label calculated values clearly and make manual overrides visible.
Keep source data distinct from edited data.
Make changes reversible where possible and preserve an audit trail.
Keep the commercial context close to the decision being made.
Real users do not stay on a happy path. Costs change, customers request amendments, aircraft assumptions move, operational information arrives late, and confirmed work may still need commercial edits. A rigid workflow can look clean in a prototype and fail the first time a real team encounters an exception. The answer is controlled flexibility: enough room for expert users to do their job, with enough guardrails to protect the integrity of the record.
Status is not decoration; it is trust
In operational software, status is one of the most important parts of the interface. It tells the user what has happened, what is happening now, what needs attention, what can still be changed, what is locked, what is waiting on someone else and what is safe to act on.
That is why visibility of system status remains such a durable usability principle. In complex B2B products, it is not just a loading spinner or confirmation message. It is the lifecycle language of the product.
For Aerios, I had to think carefully about the distinction between request, quote, booking, invoice and contract statuses. Which labels should users see? Which were operational or system states? Which transitions needed approval? Which were reversible? Which should trigger a notification or move a record into a different workspace? Which needed an audit trail?
If status is not designed deliberately, it becomes a pile of labels. If it is designed well, it becomes a map of the business process. That is UX as governance, not just presentation.
Give users the current state, not a history lesson
Lifecycle products have to balance history with action. People need traceability, but they also need to know what matters now. When every historic record has the same visual weight, the user has to interpret the lifecycle for themselves. That raises cognitive load and slows decisions.
A good transaction view should answer three questions quickly:
What is the current state?
How did we get here?
What can I do next?
In the Aerios redesign, the transaction model gave the user a clear current stage while keeping the request, quotes, booking details, invoices and contracts available underneath. The system held the thread so the user did not have to reconstruct it every time. That structure respects how commercial teams actually work.
Journey mapping and service blueprinting are especially valuable for this kind of product. A journey map shows what the person is trying to achieve over time; a blueprint brings in the people, data and backstage processes that make the experience difficult to design. In complex SaaS, I have found that you need both.
Configuration and integrations reveal product maturity
Every enterprise product eventually faces the same problem: different customers want the same product to behave differently. At a small scale, someone adds a setting, creates a workaround or hardcodes a customer-specific rule. At scale, that becomes dangerous. Configuration needs a model.
At Aerios, this included organisation settings, teams, quote templates, formulas, aircraft, base airports, document behaviours, integrations and permissions. The challenge was not just adding settings. It was making their consequences understandable. Who can change this? What does it affect? Does it apply to historic records? What happens if the selected item is deleted? Which team or profile is active?
A dropdown can represent permissions, data integrity, deletion logic, historical references, auditability, reporting and business rules. The visible artefact may be a select field. The real design work is the state model behind it.
The same principle applies to integrations. Users do not need raw API detail, but they do need to understand operational meaning: where data came from, when it was updated, whether it is fresh or stale, whether it was manually overridden, whether an integration failed and whether a value will be used in a final calculation or document. Hide implementation detail; reveal the meaning that affects a decision.
Where AI genuinely helped in the Aerios work
AI-assisted tools can compress the gap between a concept and something a team can discuss or test. At Aerios, their value was not that they magically solved complex aviation UX. They helped us explore once the problem had been framed with enough context.
I used AI-assisted workflows to explore alternative structures, draft first-pass prototype flows, turn messy notes into clearer requirements, stress-test terminology, surface likely edge cases and create artefacts that product and engineering could react to. Tools can generate plausible screens very quickly. Plausible is not the same as correct.
For a complex product, useful AI context includes the user goal, business process, data model, component system, permissions, decision points, constraints and failure states. Without that, AI produces an attractive generic interface. With it, it can speed up meaningful exploration. The designer still has to decide what preserves trust, reduces risk and works for real users.
The senior-design skill is making ambiguity discussable
Much of the hardest work on Aerios was not producing screens. It was making ambiguity discussable. Commercial teams care about conversion; operations care about execution; finance cares about control; engineering cares about feasibility; leadership cares about scale; customers care about getting their work done. They can all be right and still be talking past one another.
The designer’s job is to create artefacts that let the group reason together: lifecycle maps, transaction models, service blueprints, status taxonomies, prototypes, permission matrices, risk maps and measurement frameworks. These are not documentation for documentation’s sake. They are alignment tools. They turn abstract disagreement into something visible and shift the question from “I think” to “what happens if?”
Measure lower uncertainty, not just fewer clicks
Not every design outcome should be judged through one conversion rate. In a transaction-led operational product, I would look at measures such as time to create a quote, time to identify a transaction’s current stage, duplicate-record rates, manual document edits, support questions, quote-to-booking conversion, pricing or document errors, task success and user confidence after key workflows.
The GOV.UK Service Manual is a useful reference for choosing meaningful service metrics. A metric is valuable when the team understands what it represents and what decision it should influence.
Reducing clicks is not always the right goal. A commercial action may require more steps if they prevent an error, preserve an audit trail or give a person confidence in a high-value decision. The aim is often lower uncertainty, not merely fewer interactions.
The five models I use for complex workflow redesign
Object model: what is the main thing the user is managing?
Lifecycle model: what stages does it move through, and which transitions are allowed?
Relationship model: which records, documents and entities need to stay connected?
Control model: who can do what, what is editable and what needs to be tracked?
Measurement model: what should become faster, clearer, safer or more commercially effective?
Together, these models move UX from surface design towards product architecture. That was the lasting lesson from Aerios.
The future of B2B UX is operational design
Aerios reinforced a conviction I have developed across enterprise work: complex products need conceptual clarity before visual polish. If the product model is fragmented, users will feel fragmentation. If statuses are vague, they will not trust the workflow. If documents are disconnected, they will work around the system. If the design system covers only components, teams will keep reinventing behaviours.
The best B2B products will feel simple not because the domain is simple, but because the product has done the hard work of structuring complexity. They will preserve context, reveal the right amount of detail, support judgement rather than replace it, and model work as people actually experience it.
That is the work I found most interesting in the Aerios carrier marketplace redesign. It is not especially glamorous in the Dribbble sense. It is deeper than that: making complicated systems usable for people who do not have time for them to be confusing.
In complex software, the transaction is the product. The screen is simply where the user meets it.
