The interface that changes itself: how to design for real-time personalization

An interface that adapts to the user in real time is no longer a feature for large platforms, but a basic expectation. Spotify changes the main screen depending on the time of day. Booking shuffles filters to search history. Linkedin replaces the CTA on the button depending on whether you have completed the profile. All of these interfaces have one thing in common: they never look the same to two different people and to the same person on two different days.

The problem is that you cannot design these interfaces according to the old rules. The layout in Figma is a snapshot of one state. And the product lives in hundreds of states simultaneously. And most design teams will find out after the release – when personalization breaks the hierarchy, blurs the brand, or begins to annoy the user with “too smart” behavior.

## Why has it become important now

Previously, personalization was a luxury: recommendation engines, A/B tests, dynamic blocks on landing pages. Now it's expected by default. And three reasons why:

• AI reduced the cost of the signal. Previously, analysts and SQL were needed to understand that the user was a beginner. Now it solves one prompt to the model on top of events.
• **The channels have become fragmented. ** The same person logs in from a mobile phone in the morning, from a desktop in the afternoon and through an email digest in the evening. The static interface is already breaking down.
• Competition for attention has increased. Universal screen loses to the screen that "understood" the user in 2 seconds.

If a product doesn’t adapt, it feels old. Even if it's visually fresh.

## What is Realtime Personalization Actually

Most often, this word is understood as recommendations. It's narrow. Real-time personalization is any change to an interface in response to a signal about a user, context, or behavior. The signal can be anything:

• who is the user (newcomer/returning/paying)
• where it is now (country, language, time zone, device)
• what he just did (last click, last purchase, interrupted flow)
• in what state (the session started a minute ago or lasts an hour)

The interface can be changed on four levels:

### Level 1: Content

The safest. Text, pictures, recommendations are replaced. The screen structure is the same. Most products start here and stop in vain.

### Level 2: Hierarchy

The order of the blocks changes, the accents that hang at the top. The beginner sees the onboarding block, the experienced - the last action. Here the first problems begin: the designer made a layout with a view to one hierarchy, and in the sale it floats.

### Level 3: components

The elements themselves are being replaced. The “Buy” button turns into “Continue shopping”, the promo card into a reminder card. Here you need not layouts, but rules: under what conditions what component is needed.

### Level 4: Navigation and Structure

It changes which sections exist for this user. B2B products often hide partitions under roles. This is the most risky level – the user loses orientation if the structure “walks”.

A good rule of thumb at the start is not to climb Levels 3 and 4 until Levels 1 and 2 are disciplined.

## First thing that breaks down: hierarchy

When a designer draws a screen, he subconsciously builds a focus: where is the first look, where is the second, where the eye leads. In a personalized interface, this focus can diverge because the blocks are rearranged by rules that the designer does not directly control.

Typical breakdown scenarios:

• The main CTA left below the fold because a personalized banner was glued on top.
• Two different personalized blocks compete for attention – both are “important” and the user chooses neither.
• On an empty signal (new user, no data) the screen looks like a broken one - white holes where personalization should be.

A checklist for a designer when a dynamic block is entered:

• What happens to the screen hierarchy if that block appears or disappears?
• Does the block have a fallback state for an empty signal?
• How many blocks can be on the screen at the same time? What about priority?
• Who decides which block wins – design system or product logic? Is that recorded somewhere?

Antipattern: "Let's add a personalized slot here, we'll solve the content later." A slot without priority rules turns into a dump after two releases.

## Questions for the audit at this stage

• Are we designing the screen or are we designing the screen assembly rules?
• Who is responsible for the hierarchy when there are 5+ dynamic blocks on the screen?
• Do we have a definition of “empty state” for each personalized slot?
• Has the designer seen what this screen looks like for three different types of users, not just your test account?

If the answers are vague, personalization will work in demos and break in sales.

## Workflow: from layout to rule n

In normal work, the designer gives the layout - a fixed picture. In a personalized product, this stops working on the second release. Another artifact is needed: a set of states and rules by which the screen is assembled.

The practical shift looks like this:

• Instead of the “model of the main” – matrix of the states of the main (a beginner without data, a beginner after the first action, a returning active, returning “asleep”, a paying one).
• Instead of “one CTA hypothesis,” **the CTA priority rule: which wins if both apply.
• Instead of “the empty state will draw later” – empty state as a full screen, because for part of the audience it is the main one.

It's not about drawing 5 times more layouts. It's about once agreeing on what axes of variability this screen has, and for what combinations we promise it looks good.

### Minimum set of artifacts

• Signal Map: What user data is available on this screen and who is supplying it.
• List of slots: what in principle can change. Content, hierarchy, component, section.
• Priority rules: If there are two blocks in the slot, who wins.
• Fallback states: What is shown if there is no signal or it is late.

Without these four things, personalization is conversation, not design.

## Diagnostics: How to know if the interface is broken

Real-time personalization breaks down quietly. Metrics can not fall, screenshots in Figma look normal, and in the sale of some users, the screen flickers, jumps or meets them with emptiness.

### Symptoms that are easy to miss

• Layout shift when downloading. First, the screen shows default, after 200-600 ms personalization is reached - and everything jumps. It is especially painful on mobile when the finger is already flying to the button.
• Double onboarding. The user sees a clue for the beginner, even though he is already a week in the product - because the segment was recalculated in a wrong time.
• Empty cells. A grid of 6 cards, but only 2 are relevant to this user - the remaining 4 are filled with garbage or not drawn at all.
• Conflict with notifications. A personalized block duplicates what has already come in a push or a letter. For the team, these are different systems, for the user – one annoyance.

### How to catch a revue

• Run the screen for at least three profiles: “zero” (no data), “medium” (typical case), “extreme” (old user, a lot of history).
• Watch the screen on the slow network – this is where you can see layout shift and late blocks.
• Open the screen twice in a row: personalization for the second run should be meaningful, not “like the first time.”.

## Typical team mistakes

### Mistake 1: Personalization without rollback

The layout is beautifully drawn, in the sale – 30% of users have an empty screen because the recommendation system did not respond. Any dynamic block must have a default that is no worse than the “universal” option.

### Mistake 2: Too many axes at once

The team simultaneously introduces segmentation by role, scenario and life cycle phase. On paper, logically, in practice, no one can explain why a particular user sees a particular screen. It's almost impossible to do that.

### Error 3: Designers can’t see their screen through the eyes of the user

In the test account, all features are included, all experiments in variant B. The designer is sure that everything works. In a real beginner, half of the blocks simply do not appear. It is treated with separate test accounts for each key segment.

### Mistake 4: Personalization for Personalization

The block changes because “we have the data.” The benefit to the user is not stated. If there is no answer to the question “What will the user do faster or better now?” it is not personalization, it is noise.

## How it fits into Figma and the design system

The good news is that there is no need to radically redesign the tools. A few habits are enough.

• **Variant components for signal states, not just visual styles. In the card recommendations - options "have data / no data / late data".
• **Document the rules next to the component. ** Not in a separate v3 personalization file, but directly in the component description: when applied, which shows in an empty state how the conflict behaves.
• Prototypes for the segment, not for the feature. It is more useful to show on the review “how does a beginner live the first 3 screens” than “what does feature X look like in a perfect case”.
• AI hints and MCP integrations — after the rules, not before. If you use them to massively generate variants of screens without a clear state matrix, you get a lot of beautiful pictures and a zero system. First the axis of variability, then the acceleration of generation.

## Checklist before delivery of the layout in development

• For each dynamic unit there is a “no signal” state.
• The priority rule is described if several blocks claim the main accent on the screen.
• Decided what happens when a late server response: show default and do not replace, or substitute with animation.
• The screen is checked on at least three user profiles, not just a designer account.
• It is clear who in the team owns the rules of assembly: design, product or ML.
• There's a way to turn off personalization on this screen in the sale if something goes wrong.

## Questions for the audit

• Can we briefly describe in words the rule by which this screen is assembled? If not, there's no rule yet.
• What would a user see if all the signals disappeared at the same time? Is it still a work product?
• Where do you document what logic wins in a conflict between two personalized blocks?
• Has the developer seen the same state matrix as the designer, or will he have to build it himself?

## Segment summary

Personalization ceases to be an ornament and becomes a construction. The designer’s artifact is not a screen picture, but a set of states and rules by which the screen is assembled for the user. Anything that is not usually described will be an accident.

## Scenario: Onboarding that catches up with the user

Classic onboarding is a linear chain of 4-5 steps. Real-time personalization breaks this linearity: the user can come with an invite from a colleague, with a filled profile from a social network, with a story in a neighboring product. Design has to see that.

The working approach is to describe onboarding not as a sequence of screens, but as a set of tasks that need to be closed before activation: “know the role”, “know the purpose”, “connect the data”, “do the first action”. At each approach, the system checks what is already closed and shows only what is left.

### What to see in the layout

• What will a user see when they have three out of four tasks closed – do we congratulate them or give them the rest of the step?
• If the task is closed in the background (for example, the data from the integration was pulled up), does the screen change at the moment or at the next approach?
• Is it possible to go onboarding "out of order" and not break the state?

## Scenario: Main screen with competing blocks

On the dashboard live recommendations, unfinished tasks, upsale, system notifications and sometimes a banner from marketing. Each block considers itself the main one. Without priority rules, the last person to be rolled out wins.

It’s helpful to describe one axis – what’s more important to the user right now. These are usually critical system messages, then incomplete user actions, then system recommendations, then everything else. Then there is the rule of conflict within one level: for example, no more than one accent block on the screen, the rest goes into a neutral state.

## AI screen assembly: where it works, where it breaks

The temptation to build the model screen is great: “Here are the signals, here is the library of blocks, collect the best.” In practice, this only works under two conditions.

First, the model assembles from pre-approved blocks and states rather than generating layout. The designer is still responsible for what each block looks like and its empty state. The model is responsible for choice and order.

Secondly, the assembly has an observable explanation. For each display there is a log: what signals came, what blocks were considered, why these were chosen. Without this, it is impossible to debunk the complaint “I have a strange screen”: neither the designer nor the support will be able to restore what happened.

### Anti-patterns when working with AI

• Generation of variants of screens without a state matrix. The model quickly produces a hundred beautiful pictures, but none of them answers the question "what we show if there is no signal.".
• MCP integration as a rule replacement. Connecting Figma to product data is useful for prototyping at real values, but does not negate the build logic described. Otherwise, everything is beautiful on one user and unpredictable on others.
• AI-copyright on dynamic blocks without editing. The text of the recommendation, collected on the fly, periodically gives out strange wording. You need boundaries: length, tone, forbidden designs, default phrase.

## How to Check Quality in Production

The layout is a hypothesis. The quality of personalization can only be seen in live data.

• Segment screenshots. Once a week – a pack of screenshots of real users from key segments (with their consent and without sensitive data). Your eyes can see what you can't see in metrics.
• Not just the CTR, but the fraction of sessions where the block actually helped: a click led to a completed action, not to a return two seconds later.
• Proportion of defaults. What percentage of impressions is a fallback because the signal didn't come. As that percentage grows, personalization degrades quietly.
• ** Support complaints tagged "weird screen."** A separate tag that reads the design team, not just the product.

## How to explain the decision to the team

The most common problem is not logic itself, but that development, product, and ML assemble it in their own way. The designer thinks that “the rule is obvious from the layout”, the developer finishes by intuition, the ML team optimizes its metric. There are three different products in one screen.

What helps the review:

• **One page of rules next to the layout. ** Not design docks for 40 screens, but short text: what axes, what priorities, what is in default, what is off.
• State matrix instead of the "perfect" screen. Shows not one frame, but a grid: segment × signal presence. You can see where the holes are.
• **Scenarios of a day in life. ** Same user, three calls per week. This is more convincing than any architectural presentation.
• **A clear area of responsibility. Who decides that block A is more important than block B: design, product or model? If there is no answer, the last person to write the code will decide.

### Review questions with the team

• If you turn off the ML service tomorrow, will the screen make sense?
• Where does the priority rule live in the code—in the design system, in the product layer, or within the model?
• Can a user’s screenshot support tell why they’re seeing this?
• What do we measure to understand that personalization does better, not just differently?

## Segment summary

Advanced personalization isn’t about “more AI,” but more discipline: explicit rules, observed build, validation on live segments, and a shared picture of states for the team. AI and MCP accelerate where the system already exists and increase chaos where it does not.

## Summary checklist: is the interface ready for real-time personalization

One screen can be assembled by intuition. There is no system that changes for each user. Below is a list that makes sense to go through before the feature goes into the rollout, and not after the first wave of complaints.

### Before launch

• The segmentation axes are described – no more than three, and each has a clear product sense, and not “because there is such a field in the data.”.
• For each dynamic block, there is an empty state, a default state, and a “signal is out of date” state.
• The segment x signal state matrix is assembled and viewed by the eyes, not just in the author’s head.
• Invariants are fixed: what remains on the screen always, regardless of the model.
• The order of priorities of blocks in case of conflict of recommendations is prescribed.
• Copyright in dynamic blocks has boundaries – length, tone, forbidden designs.
• The user can explicitly say “I’m not interested” at least for key blocks.

### At launch

• Each display is logged so that the session ID can be restored, which blocks and why got out.
• There is a feature flag that disables personalization and returns the default screen in one click.
• The default screen itself is considered a work product, not a stub.
• Support knows where to look to explain the screen to the user.

### After launch

• On the dashboard you can see: the share of defaults, the share of “useful” impressions, the share of complaints with the tag “strange screen”.
• Once a week – manually view screenshots by segment.
• There is a process of revising priority rules, not just model weights.

## Anti-process level patterns

Designer anti-patterns about AI and states are already discussed above. These are about how teams break real-time personalization organizationally, even if the screens themselves are designed neatly.

### “Personalization is led by ML, design leads landings”

The quietest and most expensive separation. The design is responsible for static pages, and anything that changes in the runtime is considered the model zone. After six months, the product consists of two different products: a beautiful facade and an unpredictable ribbon. No one considers themselves the owner of how they fit together.

### One experiment, one metric

The real-time block raises the CTR and it rolls out. A quarter later, it turns out that fatigue from the tape has grown, the depth of viewing has fallen, and subscriptions have grown. On the review of the experiment, these metrics simply did not look. Any personalization should be evaluated by a pair of “target metric + protective metric”, otherwise one is optimized at the expense of the other.

### Rules live in three places

Part of the priorities are in the design system, part is in the product code, part is inside the model. Each change requires the synchronization of three teams, and after six months, no one can answer the question “why this block is higher than that.” It is not cured by a rally, but by making rules into one readable layer - even if it is just YAML next to the feature config.

### No ritual of degradation

No one agreed in advance, what will happen if the model starts to go wrong: roll back to default, leave the last good cut, show the editorial selection? The decision is made at night under pressure and is usually bad.

## Questions for the final review

• If a new designer comes in six months, will he be able to document why the screen looks like this?
• What needs to happen for us to roll back personalization — is there a predefined threshold, or will we argue in the moment?
• What blocks are we willing to keep “human” forever because personalization makes more noise than good?
• Who on the team looks at live user screenshots, not just aggregate metrics?
• If tomorrow there is a regulatory requirement to explain to the user why they see this, can we?

## Practical outcome

Real-time personalization ceases to be magic at the exact moment when the team has a common language: a state matrix instead of a perfect layout, an observed build instead of a “model decided,” protective metrics next to the target ones, and an explicit degradation plan. No matter how smart the model is under the hood, the interface remains manageable, understandable, and design-friendly.