In digital product design, the term complex flow appears surprisingly often—and is left undefined just as often. You may hear it during a job interview, a portfolio presentation, or a project review: “Show us an example of a complex user flow.” The instinctive response is to look for a process with numerous screens, steps, and branches.

But that is only one possible type of complexity.

A flow can be complex even when it takes place entirely within a single window. Conversely, an extensive application may contain several relatively simple flows that become complex only because they share data, system states, and the same workspace. The number of screens tells us very little about the actual complexity of the interaction.

A flow is not a map of screens

Nielsen Norman Group defines a user flow as a set of interactions describing the typical or intended path a user follows to complete a specific task within a product. Unlike a customer journey, which captures a broader experience over time and often across multiple channels, a user flow focuses on a relatively precise part of the interaction with a system. It includes both user actions and system responses. (User Journeys vs. User Flows)

For this reason, a flow should not be understood exclusively as:

Screen A → Screen B → Screen C.

It may just as easily look like this:

User decision → change in the system state → change in available options → next decision.

In this scenario, the user does not have to navigate to a new view. The entire process may take place within a single form, table, editor, or side panel.

NN/g points out that the user experience depends not only on what appears on the current screen, but also on how the current state relates to previous and future states. If users do not understand how an earlier decision affected the options available later, the problem concerns the workflow—even if each individual screen is clear. (Workflow Expectations: Presenting Steps at the Right Time)

The complexity of a flow therefore does not come from the number of views. It comes from the number and nature of the dependencies that the user and the system must handle together.

Complexity contained within a single step

Consider a simple four-step wizard. Structurally, it looks straightforward. The problem begins in the second step, where the user selects a method of configuring the product.

The first decision changes the available variants. The next one determines which fields become required. Some combinations are unavailable, others require additional confirmation, and still others trigger a background process. Changing an earlier selection may invalidate information entered later.

Visually, the user is still working within a single step. Behaviourally, however, they are moving through a tree of interdependent states.

This is an example of local flow complexity: the complexity is concentrated within one part of the interface. It exists not because the user visits many screens, but because each decision can change:

• the options displayed in the interface;
• validation requirements;
• available actions;
• the consequences of subsequent choices;
• the possibility of returning to or changing an earlier decision;
• the state of data entered in other parts of the form.

NN/g describes wireflows as particularly useful when a product contains relatively few pages, but their content or layout changes dynamically in response to user interactions. The next element in a wireflow does not have to represent a separate screen. It may show the same view after a state change, an error, a confirmation, or the appearance of additional fields. (Wireflows: A UX Deliverable for Workflows and Apps)

This directly supports the idea that a complex flow can exist within a single window.

Can a table have its own flow?

Yes—provided that the table is not merely a static presentation of data.

A table becomes part of a workflow when users can select a record, change its status, initiate a bulk action, enter an editing mode, resolve a conflict, or approve an outcome. Each operation may affect both the data and the actions available next.

Consider an order-management table. Selecting one record makes one set of actions available. Selecting multiple records reveals another. An order in “Draft” status can be edited directly, while an order already submitted for processing may require a separate correction procedure. A bulk operation may end in complete success, partial success, or an error affecting only some of the selected records.

Formally, the user is still looking at one screen. In practice, they are moving through a sequence of states:

Object selection → action selection → validation → operation → feedback → new object state.

In this context, it is reasonable to say that the table has its own flow. More precise terms would be table-based workflow, state-driven interaction, or data-management flow. These terms help distinguish a workflow performed through a table from basic table interactions such as sorting, filtering, resizing columns, or changing pagination.

Not every table automatically creates a complex flow. Complexity emerges when actions have meaningful consequences, dependencies exist between states, and users must understand what they can do now—as well as what will happen next.

One interface can contain multiple flows

A different type of complexity appears in professional tools such as analytical systems, medical applications, financial platforms, administrative software, and CAD applications.

In these products, users rarely follow one predetermined process from beginning to end. Instead, they move between many different tasks:

• creating or modifying an object;
• changing how it is displayed;
• analysing data;
• comparing alternatives;
• configuring parameters;
• running calculations;
• reviewing errors;
• exporting results;
• returning to an earlier decision.

Each tool available under an icon may initiate its own relatively small flow. However, these flows are not entirely independent. They operate on a shared data model, selected object, active mode, and action history. A change made in one area affects what the user sees or can do elsewhere.

In this case, a complex flow is not one exceptionally long path. It is an ecosystem of interconnected flows operating within a shared workspace.

NN/g defines complex applications as systems that support broad goals and nonlinear workflows for specialised users. These products often involve large datasets, analysis and problem solving, multiple roles and tools, or actions with serious consequences. (8 Design Guidelines for Complex Applications)

The word nonlinear is important here. Users may return to an earlier decision, skip part of a process, compare several alternatives, or change direction based on what they have just learned from the data. The design should not force them through a single rigid sequence if that sequence does not reflect the actual nature of their work.

Application complexity is not simply a large number of features

An extensive toolbar does not automatically make a product complex. In the same way, a large number of screens does not automatically create a complex user flow.

Complexity emerges when features:

• depend on the current state of the system;
• affect shared data or objects;
• can be used in different sequences;
• produce different consequences depending on the context;
• require coordination between roles or tools;
• use modes that change how the interface behaves;
• involve asynchronous operations, exceptions, or partial success.

Modes commonly found in graphic-design and CAD applications are a good example. The same click or drag gesture may produce a different result depending on the active tool. Modes are not inherently a design mistake—in specialised software, they may be necessary—but the current mode must remain visible and understandable. If users do not know which mode they are working in, the system becomes unpredictable. (Modes in User Interfaces: When They Help and When They Hurt Users)

This is why visibility of system status, clear feedback, undo mechanisms, and context preservation are essential in complex applications. A designer does not remove the inherent complexity of the domain. The designer organises it so that users do not have to reconstruct the system’s rules from memory every time they perform an action.

“Complex flow” can describe several different problems

The difficulty with the term is that it does not function as one strict, universally accepted category. Depending on the person or organisation using it, complex flow may refer to several different kinds of complexity.

This is why the interview question “Have you designed a complex flow?” is imprecise. A good answer should begin by identifying the type of complexity involved.

For example:

Yes. I have designed both flows with conditional logic contained within a single view and processes spanning several interconnected areas of an application. In both cases, the complexity came primarily from dependencies between decisions, data states, and available actions—not from the number of screens.

This answer demonstrates not only experience, but also the ability to define the problem before presenting a solution.

Does every flow need to be presented as a diagram during an interview?

No. A diagram is a communication tool, not compulsory proof of complexity.

The presentation format should depend on where the actual problem lies:

• a traditional user flow communicates the order of actions and decision branches;
• a wireflow shows interface changes occurring within one or several views;
• a state diagram shows how an object changes and which operations are available in each state;
• a service blueprint helps explain a process involving multiple roles and actions invisible to the end user;
• a dependency map shows how several tools or flows affect shared data.

A portfolio does not need to document every possible scenario. Such diagrams quickly turn into spaghetti and stop explaining anything. It is usually more effective to show the central mechanism behind the complexity: one important dependency, the key states, a meaningful decision point, and the way exceptions are handled.

The presentation should therefore begin by explaining what made the problem complex. Only then should it introduce the artefact best suited to communicating that complexity.

Complexity begins when one action changes what can happen next

A complex user flow may span a dozen screens, but it can also exist within a single step of a wizard. It may belong to a table if that table functions as an active space for managing states and actions. It may also emerge at the level of an entire application when several smaller flows intersect within the same working environment.

propose the following working definition is therefore not based on the number of steps:

A complex flow is a task process in which user decisions, system states, and business rules create dependencies that affect the actions available next.

The more of these dependencies users must understand, anticipate, or control, the greater the actual complexity.

This is why the intuition that a complex flow can exist both within one window and across an extensive CAD application is correct. These are simply two different levels of the same phenomenon: the local complexity of decisions and the systemic complexity of interacting workflows.