What Aruba Gets Right About CX Design (And What It Doesn't)

Most enterprise networking vendors talk about customer experience as a feature. Aruba — now HPE Aruba Networking — has, to a meaningful degree, built it into the architecture. That distinction is worth examining carefully, because it reveals something instructive about what CX design actually requires: not just good intentions, but structural choices that make the right outcome easier than the wrong one.

This article uses Aruba's approach as a lens. Not to review their switches, but to extract the design principles — and the gaps — that any organisation building a complex product or service can learn from.

What Does "CX Design" Actually Mean in a Technical Product Context?

CX design is the deliberate shaping of every interaction a customer has with a product, service, or organisation — from first awareness through to renewal — so that the cumulative emotional and functional experience drives loyalty, not just satisfaction. In technical products, this is harder than it sounds. The customer's journey spans pre-sales, deployment, daily operations, troubleshooting, and renewal. Each stage has different actors, different jobs-to-be-done, and different failure modes. Getting any one stage right whilst the others remain undesigned is not CX design; it is accidental competence.

Aruba's portfolio gives us a rare opportunity to examine CX design across all three layers where it tends to succeed or fail: the product layer, the operational layer, and the service layer.

What Aruba Gets Right: The Product Layer

Designing for the operator's job, not just the network's performance

The AOS-CX operating system — the software foundation of Aruba's CX switching portfolio — is built on a microservices architecture with a database-driven state model. For a network engineer, this is not an abstract technical choice; it is a direct reduction in cognitive load. Traditional network operating systems store state in memory, which means a process crash can corrupt the entire running configuration. AOS-CX separates state from process, so individual services can restart without taking the switch down.

From a customer experience design standpoint, this is a textbook application of what behavioural economists call friction reduction. Richard Thaler's concept of sludge — friction that imposes costs on the user without producing any corresponding benefit — is endemic in enterprise networking. Aruba's architectural choice removes a category of sludge entirely: the fear-of-failure that makes engineers reluctant to push changes to production. When the cost of a mistake is lower, operators act more confidently, and the overall experience of managing the network improves.

Embedding analytics at the point of action

The Aruba Network Analytics Engine (NAE) is natively integrated into CX switches, not bolted on as a separate management console. It allows operators to write Python agents that capture real-time telemetry, monitor health conditions, and automate troubleshooting — all from within the switch itself.

This is significant from a CX design perspective because it collapses the distance between sensing a problem and acting on it. In most enterprise environments, the journey from "something is wrong" to "I know what is wrong and can fix it" involves multiple tools, multiple logins, and multiple context switches. Each of those transitions is a moment where the operator's mental model degrades and errors multiply. NAE's native integration shortens that journey dramatically.

The Nielsen Norman Group's research on minimising cognitive load consistently shows that reducing the number of steps between problem identification and resolution is one of the highest-leverage moves in experience design. Aruba appears to have understood this, even if they would not describe it in those terms.

Centralised management that actually centralises

HPE Aruba Networking Central provides unified visibility across wired, wireless, and WAN devices from a single cloud or on-premises platform. The CX 10000 Series goes further, integrating a programmable AMD Pensando Data Processing Unit (DPU) to deliver stateful services inline at wire-rate — meaning security and segmentation logic runs on the switch itself, not on a separate appliance that must be managed separately.

The CX design principle here is journey consistency: the operator's experience of managing security policy should not differ radically from their experience of managing switching policy. When organisations force customers or operators to navigate fundamentally different tools for adjacent tasks, they create what service designers call "seam friction" — the jarring discontinuity that occurs when one part of a journey is well-designed and the next is not. Aruba's integration of Dynamic Segmentation into the switching fabric reduces seam friction for the security workflow.

What Aruba Gets Right: The Service Layer

Assigning a human to the outcome, not just the contract

Aruba's formal Customer Experience Management Services assign a designated Customer Success Manager (CSM) to help clients optimise adoption, reduce operational risk, and track KPIs. This is worth noting because it represents a structural commitment to post-sale experience — the phase where most enterprise vendors disappear into a support ticket queue.

The most common failure in B2B customer experience design is not a bad product; it is a good product that customers never fully adopt because no one owns the outcome after the contract is signed.

The CSM model is a direct response to this failure. It acknowledges that the customer's job-to-be-done does not end at deployment; it ends when the network reliably delivers what the business needs. Assigning a named individual to that outcome changes the accountability structure in ways that a support hotline cannot replicate. It also exploits a well-documented behavioural mechanism: the endowment effect. When a CSM takes personal ownership of a client's success, they invest cognitive and emotional resources in it — and that investment tends to produce better outcomes than a transactional support model.

Where the CX Design Gaps Appear

Aruba's product and service architecture is genuinely thoughtful. But examining it through a rigorous CX design lens reveals three structural gaps that are common to complex technical products — and instructive precisely because Aruba is better than average.

The pre-sales to deployment handoff

The journey from "we have chosen Aruba" to "the network is live and the team knows how to run it" is, in most enterprise deployments, a seam. The pre-sales team that built the relationship and understood the business context hands off to a deployment team that is focused on technical correctness, not business outcome. The CSM, where one is assigned, typically enters after deployment.

This is a classic journey consistency failure. The customer's emotional arc peaks at the point of purchase — they are optimistic, engaged, and trusting. If the deployment experience is impersonal or technically focused without business context, that emotional capital is depleted before the relationship has a chance to compound. Good service design maps this handoff explicitly, assigns ownership of the customer's emotional state — not just their technical requirements — across the transition, and builds rituals that maintain continuity of relationship.

The self-service documentation experience

Enterprise networking documentation is, almost universally, designed for the engineer who already knows what they are looking for. It is organised by product, by feature, by command syntax — not by the job the operator is trying to do. "How do I configure Dynamic Segmentation for IoT devices in a retail environment?" is a job-to-be-done. The documentation that answers it may be spread across three guides, a community forum post, and a YouTube video from a partner.

This is a friction problem with a measurable cost. Every time an operator cannot find the answer they need, they raise a support ticket, call the partner, or — worst of all — make a configuration decision based on incomplete information. The peak-end rule, identified by Daniel Kahneman, tells us that customers remember the peak and the end of an experience disproportionately. A frustrating documentation search at a critical moment — a network outage, a new deployment — can define the customer's perception of the entire product relationship, regardless of how well the hardware performs.

Redesigning documentation around jobs-to-be-done rather than product taxonomy is a CX design intervention with a direct impact on support costs, operator confidence, and renewal likelihood. It is also, in most enterprise technology organisations, stubbornly low on the priority list.

The renewal journey is often invisible

Enterprise networking contracts renew on multi-year cycles. In the months before renewal, the customer's relationship with the vendor is typically mediated entirely by their operational experience — how often things broke, how quickly issues were resolved, whether the CSM was proactive or reactive. There is rarely a deliberate renewal journey: a sequence of touchpoints designed to surface the value delivered, address emerging concerns, and rebuild the emotional case for continuing the relationship.

This is a missed opportunity that behavioural economics makes legible. Loss aversion — the well-documented tendency for people to weight potential losses more heavily than equivalent gains — means that a customer approaching renewal is more sensitive to what might go wrong with a change than to what might go right. A deliberate renewal journey that surfaces delivered value (anchoring the reference point high) and reduces the perceived risk of continuing is more effective than a reactive commercial conversation that starts when the contract is already close to expiry.

Organisations that want to map and design these renewal journeys explicitly — rather than leaving them to chance — consistently find that the intervention pays for itself in reduced churn and higher expansion revenue.

The Broader Lesson: CX Design Is an Architectural Decision

What Aruba's portfolio illustrates, at its best, is that customer experience design is not a layer applied on top of a product or service after the real decisions have been made. It is an architectural choice. AOS-CX's database-driven state model, NAE's native integration, the DPU's inline processing — these are all CX decisions dressed in engineering language. They reduce friction, shorten the distance between problem and resolution, and make the operator's job more tractable.

The gaps — the handoff seam, the documentation structure, the invisible renewal journey — are also architectural in origin. They exist because the organisation's internal structure (pre-sales, deployment, support, commercial) maps onto the customer's journey imperfectly, and no one has been explicitly tasked with designing across those boundaries.

This is the central challenge of CX design in complex organisations: the customer experiences a journey; the organisation experiences a set of departments. Bridging that gap requires not just good intentions but deliberate structural choices — governance, ownership, measurement, and the willingness to redesign processes that work well internally but create friction externally.

• Map the full journey, including the seams. The handoff between pre-sales and deployment, between deployment and support, between support and renewal — these are where experience quality degrades most reliably.
• Assign ownership of emotional state, not just task completion. A deployment team that delivers a technically correct network but leaves the customer feeling unsupported has failed at CX design, regardless of the SLA.
• Design documentation and self-service around jobs-to-be-done. Organising information by product feature is an internal convenience; organising it by customer task is a CX decision.
• Make the renewal journey visible and deliberate. Surface delivered value early, reduce perceived switching risk, and give the commercial conversation a foundation of demonstrated outcome rather than contractual obligation.
• Use behavioural mechanisms intentionally. Friction reduction, loss aversion, the peak-end rule — these are not abstract concepts. They are design levers with predictable effects on customer behaviour.

Aruba's CX switching portfolio is a useful case study not because it is perfect, but because it is honest about what good looks like at the product layer — and therefore makes the gaps at the service and journey layers more visible. The lesson for any organisation designing complex products or services is the same: the architecture of the product and the architecture of the customer journey must be designed together, or the gaps between them will be filled by friction.

Applying This to Your Own CX Design Practice

Whether you are designing a network infrastructure product, a financial service, or a government portal, the diagnostic questions are the same. Where does the customer's journey cross an internal boundary? What happens to the quality of their experience at that crossing? Who owns the emotional arc, not just the task completion? And where is the organisation optimising for its own operational convenience rather than the customer's job-to-be-done?

These questions are the starting point for any serious customer experience programme. They are also, in our experience, the questions that most organisations have never formally asked — not because they lack the will, but because no one has been given the mandate and the tools to ask them systematically.

If you want to assess where your organisation stands, the CX Maturity Assessment provides a structured, AI-scored view across the twelve building blocks of a mature CX programme — including journey design, governance, and the employee experience that underpins everything the customer feels. It is a faster way to find the gaps than waiting for the renewal conversation to surface them.

The organisations that get CX design right — at the product layer, the service layer, and the journey layer — are not the ones with the biggest budgets or the most sophisticated technology. They are the ones that have decided, structurally, that the customer's experience is an architectural concern, not an afterthought. Aruba's best decisions demonstrate what that looks like. Its gaps demonstrate how hard it is to sustain across the full journey. Both lessons are worth taking seriously.