Experience systems: designing how products decide

Author

Hugo Franca is the Director of Product Design based in Lisbon, Portugal, with a comprehensive background in product experience and innovation. At Nagarro, he helps clients transform, adapt, and build new ways into the future through a forward-thinking, agile and caring mindset. He also helps organizations create smart and purpose-driven product solutions, delightful user experiences and perfect digital interfaces.

Executive summary

As products become more adaptive, intelligent, and autonomous, the real challenge is no longer designing interfaces but governing how decisions are made. Organizations need an Experience System: a framework that brings together data, business rules, AI models, permissions, content, and human judgment to determine how products should behave in different situations. Without it, adaptive experiences risk becoming inconsistent, unpredictable, and difficult to trust.

An effective Experience System defines when a product should stay fixed, adapt, recommend, ask, or act, while ensuring every decision is explainable, governed, and aligned with organizational policy. As AI takes a larger role in customer interactions, competitive advantage will come from not just making products smarter, but from creating trustworthy systems that know when to act, when to seek approval, and where human accountability must remain.

An adaptive product changes its content, layout, flow or actions depending on who is using it and in what situation. Think of a banking app that explains a transaction differently to a first-time user, a support tool that suggests the next step, or a travel service that rebooks a cancelled flight on its own. Most conversations about these products begin with the interface: which content could change, which layout could shift, and which interaction should appear for this user and not for that one.

That is the wrong place to start.

The harder question is what decides how the experience behaves, what information it may use and where its authority ends. Without an answer, adaptation becomes a pile of disconnected AI features and experiments. One part recommends while another blocks. The interface changes without explaining why. An agent acts without the right approval. A personalized journey becomes unpredictable or intrusive.

As products respond to context and act for people, organizations need something sturdier than a collection of models. They need an Experience System: the connected set of capabilities, knowledge and rules that determines how a product behaves in a particular situation.

Parts do not make a coherent experience

Most large organizations already have the ingredients: customer data, business rules, design systems, content platforms, AI models, APIs and permission frameworks. None of them produces a coherent experience on its own.

Each of these parts makes its own decisions. The recommendation model decides what to suggest. The rules engine decides what is allowed. The content platform decides what to say, and the design system decides how it looks. Nobody decides how those choices fit together for the customer in front of them, so the customer ends up seeing the joins: an offer they are not eligible for, a suggestion that contradicts a message they received yesterday, an assistant that promises something the app will not let them do.

An Experience System brings the parts under one set of decisions. It covers product capabilities, design and content, customer and situational context, business rules, models and agents, permissions, organizational knowledge, quality checks and human judgment. Its job is not to make everything change. Its job is to decide, responsibly, how the product should behave when something can change.

Stable parts make adaptation possible

Adaptive experiences need stable parts. If everything can move, nothing can be learned, trusted or automated safely.

People build mental models of a product: where things are, what labels mean, what happens when they press a button. Agents depend on predictable structures too, such as stable action names, data fields and URLs. Both break when a product treats every surface as a surprise. An Experience System should make stability explicit by listing what must stay recognizable even when the content around it adapts. That usually includes primary navigation, the names of key objects and actions, the position of critical controls, commitments such as prices and terms, and the way to undo or get help.

More adaptive products need stronger rules, not fewer. That sounds conservative, but it works the other way. Clear rules let the product move where movement helps, without eroding the places where consistency is the product.

Context with limits

Authority should be earned

A product should earn the right to act on someone's behalf gradually, the way a new colleague does. How much it may do alone depends on how confident it is about what the person wants and how easily the action can be undone. At the bottom of this ladder, it researches and explains, which is safe because nothing changes. Next it recommends, and the person can see why. Then it prepares: it fills in the form or builds the booking, and the person confirms. Only at the top does it act on its own, carrying out routine, reversible actions within limits the person has set and reporting back afterwards.

Actions that spend money, change records, share personal information or accept terms stay at the prepare step unless the person has explicitly delegated more, for example by setting a spending limit.

A travel service shows how this works. It can search every flight, suggest the best option, hold a seat and prefill the passenger details. If the traveller has allowed it, it can also rebook automatically after a cancellation, as long as the new flight costs no more. Paying for a more expensive fare still goes back to the traveller.

This is the same permission logic that the agent-facing layer needs, applied across the whole experience, to human interfaces and agents alike. People need to be able to see what the product is doing, step in, say yes or no, and reverse course when something goes wrong. The Experience System is where that becomes policy: what the product may do alone, what it may only suggest, and what it must never attempt without a person.

Evaluate behavior, not only output

Teams already evaluate models for accuracy and interfaces for usability. The behaviour of the experience needs its own evaluations.

The organization owns the policy

The model does not own the experience policy. The organization does.

Models propose, systems constrain, and people stay accountable for which choices are appropriate, which actions are allowed and which standards apply. An Experience System makes that accountability operational: written down, testable, and available to the teams and tools that shape the product every day.

Figure 1. The organization owns the policy, the Experience System applies it, the models execute within it. 

Preparing one means deciding the modes, the stable parts, the context rules, the authority ladder and the recovery paths before the next model release makes improvised adaptation look easy. Tools amplify whatever decision structure you already have, including the lack of one.

What to do next

Choose one important customer journey and define its experience policy before you add another adaptive feature. Start by mapping the decision points, meaning every moment where the product could behave differently for different people or act on their behalf. Then decide how the product should behave at each one, and mark the parts of the journey that must never change.

Take a flight cancelled on the day of travel. The policy might say the product is allowed to act, within limits. It can use the booking, the traveller's loyalty status, their seat preference and whether they have allowed automatic rebooking, but not their browsing history or a guess about their budget. If a flight on the same route leaves within a few hours at no extra cost, the product rebooks the traveller and tells them plainly: "Your flight was cancelled. We moved you to the 14:10, same seat type, no extra cost." Anything more expensive goes back to the traveller as a question. Either way, they can pick another flight, ask for a refund or reach a person who already has the case in front of them.

Each of these decisions can then be tested. What happens when there is a free alternative, when there is only a more expensive one, and when the traveller has switched automatic rebooking off? Run those scenarios on every release, and you will know whether the product still behaves the way you decided.

Those answers are the seed of an Experience System. They connect the agent-facing layer and the decision-ready design system into something an organization can govern: not a promise that everything will personalize, but a clear account of how the product decides and where a person still must.