Process mapping from a design perspective: five principles for developing the right map

Inside organisations, a process (a sale, a product line, a workflow) can be planned by one team, agreed by a second, scheduled and executed by a third, settled by a fourth and reported by a fifth, across diverse systems, over a process that runs from an annual plan to settlements closed months after execution. Nobody experiences that process end to end. Every team experiences a fragment, and each fragment feels complete from the inside.

Position in the organisation also shapes the depth of the fragmentation. People executing their tasks know their part in enormous detail, yet what happens on other teams on either side may not be clear or visible. People at high management levels often lose the operational details, until a process involving eleven teams and seven systems is represented as four text boxes on a slide. Both views are accurate and useful for daily tasks, but when the whole process needs updating, neither is enough on its own to support a decision about what to change, or how.

When we as designers are part of projects aimed at improving or adjusting processes within organisations, one of our initial contributions is ensuring the relevant "landscape" is visible and understood by all relevant stakeholders.

What we bring to the table  

Making tangled or intangible subjects understandable is a foundational skill in design practice, with a deep history and repertoire, from journey maps and service blueprints to systems-level maps. Because design practice often focuses on the user experience, maps representing time-related flows are often structured around user stories. Other disciplines such as management or engineering choose maps with different focus and logics: system architecture diagrams describe systems and data flows, but stakeholder actions and processes through time are not part of the picture, while management cross-functional process maps keep the actor and the handover, but hold the data and systems implicit or at a low level of resolution. Each is right for what it was made for, but few hold people, data, systems and time together at once.

Process maps in the context of change orchestration are more than documentation. They are what Star and Griesemer called boundary objects: “Plastic enough that each group can adapt them to its own purposes, yet robust enough to hold a single identity across all of them, and therefore able to act as a means of translation between people who see the same problem very differently” (Star and Griesemer, 1989; see also Boundary objects, Bekk). The maps we produce aim to anchor understanding (either for diagnosing what needs to change or for orienting the way forward, once decisions have been made); support conversations from diverse points of view; give decision makers something concrete to discuss against; and serve as reference material after the team has dispersed and the project has ended.

Robustness is the hard part: an artefact that the people doing the work cannot recognise never becomes a shared reference. We design our approach and our deliverables for two audiences: the people we interview, whose work must be recognisable in the result, and the people who will read and use the map later. For collecting the data, we begin with what people actually do rather than relying only on what procedures say should happen. As we structure the maps, we reason abductively about content (because no single interview or document contains what's needed to describe the whole process) and iteratively explore the logics and structures that best explain the whole and its fragments, then test and validate them with relevant stakeholders. Last but not least, we treat form as meaning, because layout, structure, information architecture, typography and iconography affect what the reader notices, finds and concludes.

Five principles for shaping a process map

Halogen has worked on change processes in large organisations for many years, and no single logic or format survives contact with all of them. What we have arrived at is not a template but a set of principles for thinking about these maps. These support the choices we make as we collect, understand and develop the maps in iterative phases, including both the people who execute the tasks and those who will use the information.

1. Red thread: Find what connects across every boundary. What is the logic the rest of the map will follow? In a single ongoing process across multiple teams and systems, the logic can often be the data journey. In multiple processes running in parallel, it can be time. When multiple teams define a process, it can be a plausible future scenario.

2. Story: Describe a case you can defend, and be explicit about what it leaves out. Same as with users: processes have subtypes, categories, and deviations. We choose deliberately what to describe, state why, and, whenever possible, flag what the cases we did not map imply for the project.

3. Scope: Start before the “start”, and end after the “end”. Processes are often shaped by decisions taken before they begin (such as contract terms, system requirements and planning assumptions) and produce consequences that might surface long after. We strive to ensure our maps contain enough information to support a clear understanding of causes and consequences relevant to the project at hand.

4. Detail: Choose the level of resolution with the readers in mind. Four steps may not carry enough to understand the situation; forty will dissolve it into noise. We develop a hierarchy that supports the right level of understanding: sub-flows, main steps, activities, and actions; each can be described with a level of detail that fits the project context.

5. Design: Define the map based on how it will be used. A map facilitated in a workshop or a meeting, or living on a wall, can be one large canvas; a map used stand-alone on a computer screen might need redesigning for readability on the screens people actually use. Besides, maps often outlive the project, so goals, scope, and creation date matter to the reader. We keep in mind that not all stakeholders read visual material the way designers do, and that maps often are used beyond the process that produced them. We adjust our design choices accordingly.

What does this look like in practice?

The cases below show how we think and work. 

I. One process, end to end - 2024

Illustration 1: an end-to-end flow carried out by different units, in different systems.

This mapping was done as part of a process change that affected multiple teams across a product value chain and required IT infrastructure adjustments. The project was also flagged as an opportunity to review ways of working across people, technology and organisation, and to build alignment between teams.

The map shown in the illustration above was the final version used to describe the process, activity, and system changes required to implement the new procedure. Previous versions with a similar structure described the as-is situation, documented pain points in the value chain’s ways of working, and captured concurrent improvement initiatives.

Principles applied:

1 & 3. Red thread and scope: The data from planning to invoice. The scope was clear from the outset: the teams across the value chain lacked a shared situational awareness of how the process flowed from beginning to end. Assessing the extent to which systems fit the new process was also one of the project's objectives, so following the data and the systems through the process was a natural choice.

2 & 4. Story and detail: An average case. We chose an average case that all teams across the value chain could easily recognise. The steps described the key moments when data was created or adjusted. Each swimlane represented a team, and under the tasks the team took part in, the map described what was done to the data, and in which system. 

5. Design: A modified service blueprint structure with detailed data flows. All the maps produced for this project began by providing the reader with context. The first block to the left described what the map was about, when it was created, and the particularities of the product. We made two main changes to the service blueprint archetype. We assigned teams to each swimlane, so the reader could see handovers between teams at a glance, and we prioritised system and data storytelling by using a consistent colour code for systems and for manual or automatic data flows across all versions of the map.

II. Several processes, one calendar - 2026

Illustration 2: selected pages of a document presenting parallel flows, performed by different units, in different systems.

This mapping was made for a new project within the same organisation and area as the previous example, but for three different products. The goal was to provide a holistic view of the as-is to prepare for a change that would impact three value chains, each of which worked differently. What differed from the first case was scale and reach: more stakeholders needed to understand the current landscape, and the focus shifted to the later stages of the value chain.

Principles applied:

1. Red thread: The calendar. Data still mattered, but following a single case's data journey would not help us understand the later steps, where many cases were aggregated into categories. What all the processes in each product had in common was a clear awareness of the month at hand and of month-end, quarterly and yearly commitments. Hence, December was chosen as the fixed reference point. 

2, 3 & 4. Story, scope and detail: The most common category for each product, with the related processes described at different levels of resolution. Each product line had cases aggregated at the end by category; we chose to describe the one most stakeholders would recognise. We documented the parallel processes that produced the same data, using them as a reference for what the change could look like. However, not all processes were described at the same resolution: as the focus was on the later stages, those were mapped in more detail.

5. Design: We prioritised stand-alone readability on computer screens. We knew this mapping was intended for a diverse range of stakeholders, mostly working independently, so screen ratio and readability became high-level design requirements. Once the month became the main organising element across processes, we replaced team swimlanes with two levels of information: who did what, and how the data was managed in the systems. We followed the previous project's colour coding for systems and data flows to ensure consistency across all products in the organisation. The document opened with an introduction to how the maps were structured and which systems they covered, and included a navigation bar.

III. A process being defined - 2025

Illustration 3: a plausible value chain with parallel technical, commercial, operational and reporting flows, uncertainties and dependencies.

This mapping was carried out as part of a project that had to assess the suitability of available commercial operations systems and procedures for a new type of offering. Two possible implementations were being explored by separate teams.

Principles applied:

1 & 2. Red thread and story: A plausible future scenario. After several conversations with stakeholders across teams, we understood that decisions being taken outside our project's mandate directly affected our assessment. It was also clear that without a shared picture of the future, the conversations were not aligned. We drafted a plausible end-to-end value chain operating in the future, comparing the two alternatives under discussion to support those cross-team conversations.

3, 4 & 5. Scope, detail and design: The offering running in 2030, from contract to invoice. The map's context section explained to the reader why a future view was relevant to their work and outlined the categories we had identified as affecting all or part of the new offering: business environment, operations and revenue management. We chose the map's logic to enable end-to-end visibility. In this case, the swimlanes described the core functional flows affecting the later stages: technical, commercial, operational and reporting. Each step in the flow included three elements: what we knew was required to execute it, lessons from analogous processes already running in the organisation, and the uncertainties whose resolution would directly affect later commercial operations.

When an organisational change or improvement project spans teams and systems, it is common to encounter different pieces of information, varying in depth, and divergent ideas about the future. A shared map gives those pieces a place to meet and provides their holders with a shared situational awareness to decide what happens next. Teams will still disagree; that is an important part of the process. With sufficient situational awareness, disagreement becomes specific and anchored, increasing the likelihood of resolution.

Get in touch if you would like to discuss how our mapping approach can support your project.