User Flows

In architectural design, an existing plan helps establish what is there before we decide what to remove, retain, or change. Designing a digital experience can require a similar progression.

We investigate the current arrangement, identify what is causing difficulty, and make the proposed arrangement visible. That may involve an existing website, an application, a staff-assisted process, or a combination of digital and physical interactions.

The process described in a meeting may differ from the one people actually follow. A customer might bypass a page and call someone. An employee might copy information into a second system because the first cannot pass it along. Those unofficial routes can reveal needs that a diagram of the intended process would miss.

We distinguish what has been observed from what has been reported or assumed. A current-state flow should help us investigate reality, not make an uncertain process look settled.

A person, a purpose, and a starting point

We begin by defining whose path we are examining and what they are trying to accomplish. “Use the website” is too broad to explain much. “Find out whether an item can be exchanged and begin the exchange” gives us something specific to investigate.

The starting point matters. Someone arriving through an order email has different context from someone arriving through search. A returning employee may already know the terminology; a first-time customer may need an explanation before the first decision.

One diagram does not have to contain every possible person and starting condition. We can create related flows where the differences affect the design.

Actions and decisions

A flow shows what someone does and what determines the next step. They choose an option, provide information, review a result, or wait for something outside their control.

We make decision points explicit. Does this path depend on a selection, an account state, a business rule, or a staff response? If two routes appear to lead to the same place, do they really produce the same result?

That clarity helps clients, designers, and developers discuss the same behavior rather than attaching different assumptions to the same screen.

Conditions, alternatives, and recovery

The expected path is only one part of the experience. Someone may have missing information, encounter an unavailable option, lose their connection, or need to correct an earlier choice.

We consider the alternatives that matter to the task and its risks. Not every exception needs equal prominence, but important conditions should not be left for someone to improvise during development—or discover alone after launch.

Moving backward can be a useful action. Leaving can be a reasonable choice. A flow should accommodate human decisions, not treat every departure from the preferred business outcome as a defect.

Handoffs and outcomes

Some paths move between customers, staff, partners, and systems. We identify where responsibility changes and what information needs to travel with it.

What does the person know at that point? Who acts next? How will progress be communicated? Is the task finished, or has a request merely been submitted?

Those distinctions help us avoid designing a reassuring final screen for a process that still leaves everyone uncertain.

When we work through an online product exchange with a retail team, we begin with the customer's circumstances and the choices the business can actually support.

Opening an order, selecting an item, choosing a replacement and submitting a request may describe the main route. Together, we examine what that sequence leaves out. How does someone exchange a gift? What happens when the replacement is unavailable? Can they visit a store? Does a staff member need to review the request before anything is confirmed?

We map those routes with the people responsible for the policy, the online experience and the store handoff. Each route needs to show what the customer knows, what information travels with the request and who acts next. If a rule is still undecided, we leave it visible as a decision to make—not a finished branch in the diagram.

Following the request across channels also helps us investigate whether store staff can see it and whether someone has to repeat information. Where the connection is missing, rearranging screens will not be the whole answer.

Customer Experience Design helps examine continuity between those moments. Service Blueprinting connects them with the people and systems doing the work. Systems Integration can help carry the information across a technical boundary.

Following a task together can reveal a better question than the one we started with.

The flow becomes a shared way to shape the experience, not simply a picture of where to put the next button.

Several design tools can describe an experience, but they answer different questions.

• Information Architecture organizes information and its relationships. A sitemap can show the places available; a flow shows a route through them toward a particular goal.
• Customer Journey Mapping considers a customer's relationship with an organization across stages, channels, and time, including context, expectations, feelings, and touchpoints.
• User Journey Mapping examines someone's pursuit of a goal within a product or service, including what they experience along the way. A user flow concentrates on the actions, decisions, and conditions of the path. The two can describe the same task from complementary perspectives.
• Service Blueprinting connects the visible experience to the work supporting it behind the scenes.
• Storyboarding can make a sequence of moments and their human meaning easier to imagine.
• Wireframing gives structure to the screens or views along a route. A wireflow can combine those structures with the connections between them.
• Prototyping lets us experience selected parts of the proposed behavior rather than only reading the path.

These are complementary ways of thinking. We choose the representation that makes the question discussable; we do not need to produce every artifact to prove that the process happened.

A short path can hide information someone needs. A longer path can break a difficult decision into understandable parts. Neither is inherently better without knowing the person, task, and circumstances.

We examine the effort within the steps: what people must remember, interpret, provide, or risk. We also consider whether the experience asks for information too early, creates an unnecessary dependency, or makes someone repeat themselves.

A review step before a consequential action may be worth keeping. An internal administrative step that contributes nothing to the customer's task may be worth removing or automating.

The aim is purposeful effort, not the smallest possible diagram.

A useful path gives each step a reason to be there.

User Flows can contribute throughout Design Thinking. Discover may involve mapping the existing path. Define helps identify the problem, relevant conditions, and desired outcome. Explore makes different arrangements visible before more detailed design and development.

We work with the knowledge already available and identify where it is incomplete. Research, analytics, stakeholder conversations, support records, and direct examination of a product can contribute different kinds of evidence. The flow makes their implications easier to discuss; it does not replace them.

The resulting work may include current and proposed flows, decision rules, role distinctions, annotations, dependencies, and unresolved questions. A simple path might need one clear diagram. A larger system may need an overview with separate, connected task flows.

Developers and implementation partners can help us assess feasibility early. Clients can identify operational realities that a screen cannot reveal. That co-creation is part of designing a path the organization can actually support.

What if the current process is undocumented? Bring the product, instructions, support questions and people who know the work. We can follow a task together, compare accounts and identify which parts need further investigation. A confident recollection and an observed action do not have to be treated as the same evidence.

Can we begin with one task? Yes. Account setup, an exchange or a staff approval can provide a useful starting point. We include the dependencies that affect that task without requiring a map of the entire business.

What happens after we agree on a route? We can carry the decisions into Wireframing, Interaction Design and the appropriate prototype, or prepare them for your existing team. The handoff includes unresolved conditions and the reasoning behind the path so later changes can be considered intelligently.

Choose something a customer or colleague regularly tries to accomplish. Write down where they start, what they do, the decisions they face, and how they know they are finished.

Now ask: What happens when they cannot take the next step?

Add that route. Then ask who has to help and what that person needs to know. Mark anything you are assuming rather than treating it as a fact.

You may discover that the next useful design question is about a policy, a handoff, or missing information—not a new screen.

A proposed flow expresses how we believe an experience should work. Reviewing it together can expose gaps, but agreement around a diagram does not establish that people will understand or use it as intended.

Prototypes, appropriate usability evaluation, implementation review, and learning from the live experience help test that belief. Repeated detours or requests for help can give us a reason to investigate. They may point to the interface, the information, the surrounding service, or an assumption we need to reconsider.

Discover → Define → Explore → Design / Develop / Market → Learn → Advance → Discover

Learn and Advance take those discoveries into the next round of work. The map can change as our understanding improves.

We can map and redesign a focused flow independently or develop it as part of a broader design effort. You may have a new idea, an inherited product, or a process your team knows could work better but finds difficult to explain.

Bring us the task, the detours, and the questions. We can work with you and your implementation team to understand what is happening and design what should happen next.

Contact Us