Architecture Beyond Roles: Where UX Designers and Process Architects Meet

Photo by Kelly Sikkema on Unsplash

A practical reflection on how User Journeys and BPMN describe different realities, and how combining them strengthens system design.

Two Worlds, One System

In real projects, architects move constantly between perspectives.

One moment you look at a system through the eyes of a user, trying to understand intention, emotion, friction, and flow. The next moment you look at it as an organisation, trying to understand responsibilities, rules, decisions, and outcomes.

This is where two visual tools often meet: User Journeys and BPMN models. They describe different worlds, and they serve different audiences, yet they often appear in the same room, the same workshop, and the same design decision.

A User Journey shows how something feels. A BPMN diagram shows how something works.

Understanding both, and knowing which one to apply at which moment, is not just a modelling skill, it is an architectural skill. It is how UX thinking and process thinking converge, and how the design of experiences aligns with the design of systems.

In this article, we explore how these tools differ, how they complement each other, and why choosing the right one strengthens your ability to design systems that are not only functional, but understandable and meaningful.

Defining and differentiating our journeys

User Journey

1. Focus: Concentrates on the user’s experience and interaction with a product or service, normally within a website or application. It maps out the steps a user takes to accomplish a specific goal.
2. Audience: Primarily used by UX/UI designers, product managers, and customer experience professionals.
3. Scope: Limited to the user’s perspective, which may be just a small part of an entire business process.
4. Elements: Includes touchpoints, emotions, pain points, and the overall experience of the user.
5. Visual Representation: Often represented as journey maps, storyboards, or flowcharts, which are less formal and standardized compared to BPMN diagrams.
6. Objective: To improve user satisfaction and usability, by identifying pain points and opportunities for improvement in the user’s interaction with the system.
7. Granularity: May include very fine-grained details, such as emotional states, that are not usually captured in BPMN.
8. Interactivity: Focuses on how the user interacts with the system, which may include multiple channels like web, mobile, customer service, etc.

Process Modelling with BPMN (Business Process Model and Notation)

1. Focus: Centers on the internal/external processes of an organization. It outlines how different tasks are coordinated to achieve a business objective.
2. Audience: Primarily used by business analysts, process designers, and IT professionals.
3. Scope: Covers the entire business process, which may involve multiple roles, systems, and decision points.
4. Elements: Includes tasks, events, gateways, and sequence flows among other standardized notations.
5. Visual Representation: Uses a standardized set of symbols and notations, making it easier to communicate across different stakeholders.
6. Objective: To optimize and standardize business processes for efficiency, compliance, or transformation.
7. Granularity: Focuses on tasks and decision points, usually at a level that is relevant for organizational efficiency and effectiveness.
8. Interactivity: Focuses on how different components (people, systems, etc.) within an organization interact to complete a business process.

Because both tools are visual, they use flows as part of their visual representations. The flow is no more than the direction of the system being represented, or the series of actions that happen. The flow is heavily influenced by the focus and scope of each tool. If we look again at those characteristics we can define the flow as follows:

• User Journeys represents a page flow
• BPMN represents a process flow

Two flows that look similar (but are not the same)

Both User Journeys and BPMN use flows. Both show steps, decisions, paths. Both create shared understanding. But the nature of their flow is completely different.

Page Flow

The flow inside a User Journey is usually a page flow:

• navigation between screens
• interactions with UI elements
• states and feedback
• user choices
• emotions experienced

It is about the interface.

Process Flow

The flow in a BPMN model is a process flow:

• business activities
• waiting times
• system calls
• exceptions
• data transformations
• responsibilities across roles

It is about the work.

Page Flow is about the user’s navigation experience within an application or website. Process Flow is about the sequence of business activities and decisions. This difference in focus and scope explains why one cannot replace the other. There are little nuances in the tool selection when we want to work with Page and Process Flows. For the BPMN user a question that arises at this point is:

Can BPMN map page flow?

The short answer: BPMN can do it, but it is rarely the best choice.

BPMN can represent simple navigation if the logic is structured:

• “Is user logged in?”
• “Display cart”
• “Order submitted”

This is useful when explaining high-level steps to stakeholders, especially in cross-functional environments.

But as soon as navigation becomes:

• rich
• emotional
• UI-specific
• layout-dependent
• multi-channel
• iterative

BPMN becomes too heavy, too formal, and too focused on business logic. It loses detail where UX tools are strongest. Not all user journeys are candidates for BPMN. The notation is designed for process flows, not navigation flows.

In short, while BPMN can be adapted for page flow, it may not be the best tool for that purpose. BPMN’s strength lies in its ability to model complex business logic, data flows, and organizational interactions, which are often overkill for page navigation scenarios. Tools specifically designed for pages, like wireframes or sitemaps, are often more appropriate for that context.

What would be a good tool to map page flow?

While there isn’t a universally standardized notation for mapping page flows like BPMN for business processes, there are several commonly used techniques and notations for representing user interactions and page flows within a system. The most commonly used methods for mapping page flows in the context of user experience (UX) design, and web development are:

1. Wireflows combine the elements of wireframes and flowcharts to provide a detailed visual representation of the user’s journey through a product. This method is especially useful when the layout and design of individual pages are integral to understanding the flow.
2. Sitemaps are commonly used in the early stages of web development to outline the hierarchical structure of a website. While they don’t capture the dynamic flow of user interactions, they serve as a useful starting point for understanding how pages are connected.
3. Storyboards are often used in UX design to capture both the sequence of screens and the user’s interactions with them. While not as formalized as some other methods, they are excellent for capturing the qualitative aspects of user experience.
4. Flowcharts are one of the most straightforward and widely recognized ways to map out page flows. They use a set of standardized symbols to represent different types of actions, decisions, and endpoints, making them easy to understand.
5. User Flow Diagrams are specialized flowcharts tailored for UX design. They focus on the steps a user takes through an interface, including decision points and alternative paths. These are particularly useful for mapping out complex interactions in digital products.
6. Swimlane Diagrams are useful for mapping out more complex flows that involve multiple actors or subsystems. Each “lane” in the diagram represents a different user role or system component, making it easier to understand interactions and dependencies.

Each of these methods has its own strengths and weaknesses, and the best choice often depends on the specific needs of the project. It’s also common to use multiple methods in conjunction to capture different aspects of the user’s journey and interaction with the product.

A subtle but important distinction

Flowcharts, user flows, and swimlanes are visually similar to BPMN but lack strict standardization. This makes them:

• lightweight,
• easier to create,
• easier to change,
• flexible for design conversations.

Wireflows, sitemaps, and storyboards are more expressive. They allow you to see the interface, not just the logic. This is why UX and process teams often use different tools, they reflect different mental models.

Should you stop using BPMN for modelling page flow?

Summarizing the sections above we arrive at the following conclusions:

• We know we have notations for visual representations of flows, some of those notations have a defined set of rules, like BPMN
• There are lighter versions, without many rules such as flowcharts
• We also know that BPMN is for mapping a specific kind of flow, process flows, that focus on a business goal rather than navigating a page.
• We know that navigating a page is basically page flow, and that is different from process flow

If by now you have the suspicion that flowcharts, BPMN and co. are not the best methods to map page flows, let me tell you that your suspicion raises a valid point: while those tools are versatile and widely understood, they may not capture the nuances of user interactions and page flows as effectively as other more adequate methods.

So why are they so used instead of other methods that can map page flow better? here are some reasons why flowcharts are still commonly used for mapping page flows:

1. Accessibility and Familiarity: Flowcharts are one of the most universally recognized forms of diagramming. Most people, regardless of their role or background, can understand a flowchart. This makes them a go-to tool for quick communication across different departments or stakeholders.
2. Simplicity: Flowcharts are easy to create and modify, which can be especially useful in the early stages of a project when ideas are still being formed and iterated upon.
3. Tool Availability: Many commonly used tools like Microsoft Visio, Lucidchart, and even whiteboards can be used to create flowcharts. This makes them a convenient option for many teams.
4. Lack of Standardization in UX Field: Unlike business process modeling, which has standardized notations like BPMN, the field of UX design lacks such universally accepted standards for mapping page flows. This leaves room for a variety of methods, including flowcharts, to be used.
5. Good Enough for Simple Flows: For simple websites or applications, a flowchart may provide sufficient detail to understand the user’s path through the system.

However, for more complex interactions, specialized tools like Wireflows, or Story Boards might be more appropriate. These tools can capture elements that standard flowcharts and BPMN might miss, such as:

• User States: Different modes or states that the user might be in, which affect their available actions.
• Emotional Journey: Some advanced mapping techniques also capture the user’s emotional state at different points in the journey.
• Multi-User Interactions: Scenarios where multiple users interact can be more easily modeled with specialized notations.
• Page Elements: Different elements that compose the page and are relevant for understanding the flow, can be more easily modeled with other tools and notations.

So the answer is, you should use BPMN and flowcharts as complementary to other methods, in other words, use them in conjunction with other tools like wireflows, sitemaps, even with wireframes, and user stories.

A user journey shows why someone moves. A BPMN model shows how the organisation responds. Together, they create the full picture.

Your take-away: Architecture beyond roles

Good architecture lives between disciplines. It needs the empathy of UX, the clarity of process thinking, and the structure of system design.

User Journeys remind us that systems serve people. BPMN reminds us that systems must also serve organisations. The two do not overlap, they align. When we combine them, we don’t just design screens or workflows. We design understanding, shared across teams that usually work apart.

Because in the end, architecture is not about choosing one diagram over another. It is about choosing the right perspective at the right time, and knowing how different lenses reveal different truths about the same system.

That is what Architecture Beyond Roles really means.