Are fixed user flows becoming obsolete?

A digital product idea becomes a usable product through the well-known UX process, which involves identifying and designing optimal user flows. Every digital product usually has predefined user flows for every identified user goal, and users are trained to follow them to accomplish day-to-day tasks. For example, you remember the steps to send an email with an attachment, right? Digital products have already started replacing these predetermined user flows with dynamic, AI-powered ones through the intent-driven UX concept and generative UIs, which have emerged through recent UI/UX evolution.

The new intent-driven UX concept optimizes UX for every individual user by dynamically creating user flows based on the user’s intention, eliminating the common productivity issues with generalized, fixed user flows. Intent-driven UX is becoming the foundation of the next-generation UI/UX era; however, it’s a challenging design technique for designers : What does a UI/UX designer design when there is no longer one predetermined user flow?

In this article, I’ll explain why intent-driven UX is emerging, the fundamentals of dynamic user-flow design, and how to design next-generation products with intent-driven UX and generative UI while still getting the benefits of traditional user-flow design.

Where predetermined user flows reach their limits

UI/UX designers identify UX flows during the UX research phase, optimize them through testing, and construct them as fixed using required UI components. Then the users learn, follow, and practice them as depicted below:

Predetermined user flows are the foundation of most digital products, but they can quickly reach their limits:

• Growing complexity with menus, screens, and flow branches — When the number of predetermined flows increases, the digital product often accumulates more menus, screens, and branched flows, increasing the complexity of the overall product structure.
• Users should understand functionality organization — A digital product with predetermined flows typically shows initialization points of each user flow within menus or within the primary UI layers, so users’ll have to find and remember where each user flow starts or branches
• Users often face user flow repetition — Fixed-flow products may offer shortcuts or autofilling options, but users often have to go through user flows repetitively by performing different atomic actions within screens; e.g., transferring $10 several times to John in a classic digital payment app may require going through the same flow repetitively
• Designers should anticipate user flows in advance — Designers study, design, and optimize all possible user flows within the UX process to satisfy every unique user. The design process becomes overwhelming when the user flow complexity increases, and users may practice unsustainable workarounds whenever an efficient flow doesn’t exist

Pre-determined flows aren’t obsolete . They work effectively for process-oriented, complex, modularized products (i.e., special-purpose or enterprise products), but won’t work effectively for modern consumer product designs, especially during the current UX evolution, which moves toward intent-driven UX and AI integrations.

From user flows to intent: intent-driven UX

Intent-driven UX, a modern UX design concept, dynamically creates user flows and implements highly productive UX for every unique user based on their intentions. Intent-driven product interfaces detect user intentions based on various signals, such as direct user inputs, queries, prompts, multimodal inputs (voice, gestures, haptics, and vision), present contextual data (location, battery status, etc.), and behavioral patterns, and create dynamic UX by generating UX layers.

Compared to traditional fixed user flows, intent-driven dynamic user flow interactions go through the following steps:

1. User expresses the intent via direct inputs, prompts, queries, multimodal inputs, or the system detects intent via contextual data or behavioral patterns
2. The system detects intent
3. Determines actions/steps in the intent
4. Composes UX with dynamic user flows
5. User intention fulfillment. Refining generated UX if required

The following diagram visualizes how intent-driven UX works:

Intent-driven UX is a theoretical UX concept; product teams can implement it in different ways. Generative UI, which uses an LLM to generate product interfaces based on the user’s intention, is a popular way to implement intent-driven UX; however, AI-less, algorithmic intent-driven UX is also a possibility. Intent-driven UX is interaction-medium agnostic, meaning you can use it to improve multimodal UX products.

While getting started with intent-driven UX, it may look similar to personalization and adaptive UX, but they both modify fixed product structures, unlike intent-driven UX, which can change the product structure layer with dynamic user flows.

Different levels of intent-driven UX

Intent-driven UX can be implemented in four levels by dynamically updating the surface, skeleton, structure, scope, and strategy UX layers.

---

---

Let’s discuss how to implement intent-driven UX in each level with practical examples:

Entry-skeleton-level intent-driven UX

The product automatically adds an isolated UI block by updating both surface and skeleton layers but without making major adjustments to the skeleton layer. At this level, the product typically places a shortcut button or an optimized, personalized UI block independently without changing the predefined, static project skeleton, as depicted in the following diagram:

Here are some practical examples:

• A digital book reading app automatically creates bookmarks on the homepage when the user stops reading a book
• A digital payment app detects frequent transactions to a specific person and creates a shortcut on the dashboard, letting the user instantly make the transaction or adjust/remove it if needed
• An e-commerce dashboard automatically creates widgets based on what reports the user frequently uses and suggests the user pin them

Deep-skeleton-level intent-driven UX

Deep-skeleton-level intent-driven UX goes beyond the entry-skeleton-level and generates the entire skeleton layer or a major portion of it based on the user’s intention. At this level, the product typically uses predefined core screens, navigation mappings, along with a design system/style guide, but dynamically composes individual screens, so inter-screen user flows can be different from user to user based on their direct inputs, behavior, settings, contextual data, etc., as depicted below:

Here are some examples:

• A farm management app dynamically generates an interactive report (without a fixed template) within the app based on requested metrics
• A helpdesk agent captures the intent via a direct prompt input and dynamically constructs a quick support page

Structure-level intent-driven UX

Structure-level intent-driven UX dynamically generates the product structure layer by constructing screens and their interconnection based on the user’s intention. This level basically involves constructing optimized navigational and interaction flows for each unique user intention using a predefined design system/style guide and components:

Here are some examples:

• A trading app dynamically generates screens and user flows based on the user’s trading experience and practices
• A hotel booking app dynamically creates different booking flows based on stay type (business/leisure), check-in/check-out dates, number of people, and other details specified in the initial booking form

Scope-level and beyond intent-driven UX

At this level, the product dynamically generates the scope layer and adjusts the strategy layer under a predefined design system/style guide using atomic UI components based on the detected user intention. This level usually extends the product with new features and changes the whole product scope or/and strategy on the fly using LLMs or similar logical modelling systems, as depicted in the following diagram:

The scope-level and beyond intent-driven UX level works effectively with LLM-first products, e.g., personal assistants, and all query/prompt-driven products, e.g., search engines.

Here are some examples:

• An agentic system detects the intent as “purchasing a gaming laptop” and dynamically generates a product purchase wizard based on known user data, such as brand preferences, payment details, address, etc.
• A user searches for calculating a specific value using a formula, then the search engine dynamically generates a small embedded app to do the calculation for different inputs

The primary idea behind scope-level and beyond intent-driven UX implementation is about extending the product capabilities based on stored knowledge/rules (e.g., using LLMs) to help users fulfill their intentions.

What do designers design when flows aren’t fixed?

With intent-driven UX, products compose dynamic user flows. As a result, each user’ll get different user interfaces crafted based on their intention, but designers can’t create hundreds or even thousands of prototypes for every snapshot of dynamic user flows.

Traditional static prototypes alone won’t work with intent-driven UX — designers should present rules and outcomes for intent-driven UX parts of the product, including the following details, along with traditional prototypes for fixed parts:

Design system or style guide

Intent-driven UX isn’t about dynamically generating everything in the surface layer from scratch—the product should still adapt to a design system or a style guide to include company branding and maintain consistency in generated UI segments. Start by maintaining a design system or style guide, and update it as needed.

Identifying signals and intents

Identify what signals affect user intentions. Clearly define all user intentions in a document using suitable UX research methods based on your design scenario. You can use traditional user interviews, online surveys, online search, team discussions for new product ideas, and usability tests, A/B tests, and similar for existing product redesigns.

Here is a sample signals-intent table of a modern digital payment app:

Signals	Intent
Repetitive payments to the same recipient with the same amount during a regular period	Making the same payment again after opening the app

Identifying outcomes

Every identified intent should map to an outcome; otherwise, the user’ll struggle with an undefined user flow. An outcome is usually what the product should generate dynamically to help the user fulfill a specific intention. Map outcomes clearly to every identified intent using a flow diagram. This diagram isn’t a traditional user flow—it’s a foundational document that helps implement dynamic user flows.

Here is a sample intent-outcome table for a digital payment app:

Signals	Intent	Outcome
Repetitive payments to the same recipient with the same amount during a regular period	Making the same payment again after opening the app	Displays a shortcut to make the payment again

You can visualize this table in a diagram as follows:

Components, states, and rules

A textual description of outcomes isn’t enough for an intent-driven product handoff — we should visually present how the UI should change based on each intention. This is where designers should create designs for intent-driven UX products.

You can show how components and their states should change based on each outcome for higher-level (e.g., entry-skeleton level) intent-driven UX products.

For example, you can link components and states for the payment transfer shortcut in the previous example scenario, as demonstrated below:

For lower-level (e.g., structure-level) intent-driven UX designs, you should also include UI composition rules along with components and their states since we can’t productively create isolated static designs for so many outcomes. For example, an intent-driven product that generates dynamic booking flows based on user inputs may use an intent-outcome diagram similar to the following:

System boundaries and permissions

If we are designing static-flow prototypes, we can create user flows adhering to boundaries and permissions, but how do we add them in intent-driven product design documents? You can embed them in UI composition rules. As a solution for growing complexity in UI composition rules, boundaries, and permissions, you can create flow diagrams if needed:

User confirmations and approvals

Add details about when the product should ask for user confirmations and approvals in UI composition rule diagrams. In intent-driven UX products, user confirmations/approvals may appear in various places:

• Within generated user flow steps
• Before changing UI based on a detected intention, e.g., Would you like to display a shortcut to do <task>?
• After changing UI, asking user approval to make the UI change permanent, e.g., Would you like to keep <widget> on the dashboard?

Fallbacks, errors, undo, and recovery

Intent-driven UX flows don’t always end up fulfilling the user’s intention — they can pause or completely halt with errors too. In some scenarios, users change their intention even after entering a dynamically generated user flow or even going through the whole dynamic flow.

Depending on the outcome, create fallbacks to classic static flows, implement undo for reversible actions, recovery options for irreversible actions, and error messages. You can embed these special flows in the previous UI composition rule diagrams.

For example, if the user accepts a suggested UI layout configuration of an expense management app, the app immediately displays a toast message to switch back to the previous layout if needed, as described in the following diagram:

Aggregating everything for handoff

We can’t use static-flow prototypes in intent-driven UX projects because the user flow is highly dynamic — if we somehow do so, we’ll have to create hundreds or even thousands of them. For design handoff, we should prepare a product design specification that effectively describes dynamic flow generation. Instead of a single traditional prototype, we should present an interactive or non-interactive document that describes how the user intention is detected and mapped to outcomes, along with visual components, states, rules, and other UI composition details, including confirmations, boundaries, fallbacks, etc.

Creating diagrams with signals, intents, and outcomes as shown in previous examples is a good way to present an intent-driven product specification. These diagrams may look like a user flow if you are using intent-driven UX at a higher level (e.g., entry-skeleton level) — no, it’s not — it’s a diagram that embeds logic to create dynamic user flows — you’ll clearly see the difference when you start preparing for design handoff of a lower-level (e.g., structure level) intent-driven product.

Designing for misunderstood intent

We can’t completely guarantee that the predicted user intent becomes the actual user intent — intent signals typically give a probabilistic prediction for what the user expects from the system at the moment, and it may mismatch with the original intent due to implementation issues (e.g., algorithmic bias), shared devices, sudden intention change, or accidental actions. Misunderstood intent is not completely preventable, so we should help users to reach their goals even if the detected intent is wrong, using the following design tactics:

• Allow adjustments — Let users make adjustments in the auto-generated user flow. e.g., displaying a “Modify” button to adjust an auto-suggested quick financial transfer action
• Fallbacks and undo — Implement fallbacks to manual, static flows for major adjustments and undo operations to go back to the previous user-preferred state
• Confirmations and cancelling — If the detected intention is doubtful and can’t be accurately enabled automatically, ask user confirmations to verify the detected intention or skip. e.g., asking the user to manually pin or dismiss a suggested dashboard widget
• Transparent intent detection — Explicitly let users know about the detected intent if possible, so they can adjust or switch to a different flow if needed, e.g., a hotel booking app detects a last-minute booking and shortens the booking flow. But the product explicitly lets the user know that some steps are deliberately dropped since a quick booking is detected, also allowing users to access dropped steps if they wish to do so

How much control should AI get?

Once the intent-driven product handoff document is ready, developers will usually feed their AI models dynamic UI-generation rules. Then, the AI model is responsible for detecting intent and dynamically crafting optimized UX; AI controls your product UI composition, so you should decide how much control should AI get.

Your product’s intent-driven UX level primarily decides how much control you’ll have to give to AI or other decision-making systems (e.g., non-AI deterministic algorithms). For example, if you choose a scope-level intent-driven UX implementation, AI controls everything above the strategy layer.

You can decide your product’s AI-oriented intent-driven UX level based on the following characteristics of user intentions:

• Risk, e.g., sending money is a high-risk task and changing a layout is a low-risk task
• Ambiguity
• Reversibility
• Complexity of UI composition implementation, e.g., higher-level, simple intent-driven implementations don’t even need AI models — a simple deterministic ruleset will do the job

Overall, low-risk, reversible products or product regions can give more control to AI, and high-risk, irreversible ones should give less control, especially since AI is probabilistic ,  not deterministic.

Testing dynamic user flows

In higher-level intent-driven UX implementations, we may identify countable, fixed flows and do manual or AI-less automated tests, but lower-level implementations create highly dynamic user flows that don’t reveal countable fixed flows. So, the only productive way to test AI-generated user flows is to let AI itself test them.

As explained in this article, you can spawn many AI-generated users and let AI test dynamic flows. AI behavior isn’t deterministic, so we can’t completely guarantee that AI tests every edge case of dynamic flows; the most effective way to test dynamic flows is to do manual testing for some crucial, identified flows along with a complete AI agent simulation.

Conclusion

Intent-driven UX isn’t about turning all user flows into CTAs (call to action) or letting AI generate the whole product from scratch. It’s about dynamically generating optimized user flows using predefined components and states to help users fulfill their intents effectively, without forcing users to follow repetitive, lengthy, fixed flows. Unlike personalization and adaptive UX, intent-driven products change the whole product’s UX (any core UX layer can be dynamically constructed).

Traditional static flows don’t fully disappear with intent-driven UX . A fixed-flow product can use intent-driven UX in specific places, or a primarily intent-driven product can still use fixed flows as fallbacks.

Plan a next-generation, intent-driven product; keep in mind that you’ll have to create a special handoff document instead of fixed-flow prototypes. Designing for intent creates rules for generating user flows, not exact fixed user flows.