For the past decade, interface design has been largely about simplification — remove clutter, reduce choices, flatten hierarchies. The result was a generation of apps that are clean but homogeneous: the same cards, the same navigation patterns, the same empty states. Intent-driven design is a shift in a different direction. Instead of making one clean interface for everyone, you design a system that reshapes itself around what a specific user is trying to do at a specific moment. This is not personalisation in the old sense — it is not changing colour schemes or recommending products. It is the interface understanding context and adapting its structure, density, and affordances accordingly.
Intent-driven design starts with a simple question: what is this user trying to accomplish right now? Not what are they interested in, not what have they done before — what is their active goal in this session? The interface should make that goal easier, and reduce friction from everything else.
In practice, this means the same screen can look different for different users or in different contexts. A music app's home screen for a user in the middle of a workout is different from the same screen for a user sitting on a commute. The underlying design system is the same; the configuration of what is surfaced, how dense the information is, and what actions are primary differs based on inferred intent.
The design system implication is significant. You cannot design for intent with static component libraries. You need components with intentional variation built in — a card that has a compact mode, an expanded mode, an action-forward mode — and a system that selects the right variant based on context signals.
Intent-driven interfaces read signals to infer context. The signals that are most useful in 2026: time of day and day of week (a finance app user at 9am on Monday is likely checking balances, not exploring features), device posture (landscape vs portrait on a tablet signals different usage modes), session history (what has the user done in the last 3 minutes?), and explicit state (is the user mid-task or browsing?).
On-device AI makes this possible without privacy concerns. A small classifier running locally can determine from these signals what mode the interface should be in — focused task completion, exploration, or passive consumption — without any of the signal data leaving the device.
The important constraint: context inference should feel natural, not manipulative. If the interface shifts in ways the user cannot predict or control, it creates anxiety rather than reducing friction. Every intent-driven adaptation should have a path back to a predictable default state.
Intent-driven design cannot be layered on top of a static design system — it has to be designed in from the start. Components need explicit variants for different density levels, primary action states, and information hierarchy configurations. Figma's variables system (now mature in 2026) makes this manageable: you can define a component's intent-driven variants as variable collections that swap based on mode.
The collaboration model between design and engineering changes. Rather than designing screens, you design states and rules: 'When the user is mid-checkout and has been active for less than 2 minutes, surface payment options prominently and hide navigation.' Engineers implement the rule engine; designers define the states. The resulting system generates layouts rather than designers specifying them screen by screen.
Accessibility is where intent-driven design has a structural advantage over static interfaces. A user with motor impairments benefits from larger touch targets when the system infers they are in a focused task mode. A user with visual impairments benefits from higher contrast and larger text in low-light conditions. Adaptation that was previously manual accommodation becomes systematic.
Figma's AI-assisted design features (released through 2025 and now mature) enable designers to define variable states and have the AI generate intermediate configurations — a mid-point between the mobile and desktop variant, or a high-density variant of a standard card — that can be evaluated quickly without building each state by hand.
Framer has become the prototyping tool of choice for intent-driven flows because its variable system and conditional logic allow prototypes that actually adapt to interaction history, not just the current click. Testing an intent-driven interface requires a prototype that exhibits the adaptive behaviour — static mocks are insufficient.
On the engineering side, feature flag systems (LaunchDarkly, Statsig) have evolved to support context-aware flag evaluation — the same flag can return different values based on user context signals, which is the infrastructure layer for intent-driven UI variants in production.
Written by Evitras Team
Evitras Technologies · 2026-04-20
Ready to build something great?
Talk to the Evitras team about your next project.
After years of flat, colourless minimalism, digital design is swinging toward personality, depth, and colour confidence. Here is what is driving the shift and how to execute it without sacrificing accessibility.
React Server Components are no longer experimental — they are the expected baseline. Here is what the server-first shift actually means for how teams build and ship React applications today.
On-device ML has crossed from bleeding-edge to expected baseline. Core ML 7, TensorFlow Lite 2.15, and MediaPipe's updated SDK make local inference practical on mid-range devices. Here is what this unlocks for mobile developers.
We publish new articles on technology, design, and strategy. Reach out to get notified when we publish something new.
We value your privacy
We use cookies to enhance your experience. Privacy Policy
