Chapter 9

Model Processes and Services

25–30 min read

In earlier chapters, you defined user needs, architecture requirements, and backlog items as ways to capture the goals and needs of your system.

This chapter looks at techniques you can use to understand the organizational processes your solution needs to support. That matters because many products and information systems are built around complex services and workflows that support the work of the organization, its employees, partners, customers and other people. Work may move across employees, partners, suppliers, customers, departments, and systems before the organization can deliver a service or complete a task.

You use service blueprints and workflow diagrams to understand how people, systems, and information move through a process today, often called an "as-is assessment", and how that process should work after it is redesigned, a "to-be assessment". Service blueprints help you see a service end to end, including what users experience and what happens behind the scenes. Workflow diagrams let you zoom in on one operational process and show who does what, in what order, and with what decisions along the way.

What You Will Learn

By the end of this chapter you will be able to:

Analyze an as-is process to identify friction, hand-offs, decisions, and failure paths.

Design a to-be process that clarifies responsibilities and improves the flow of work.

Choose between service blueprints and workflow diagrams based on the design question you are trying to answer.

Use process models to communicate how people, systems, data, and decisions move through a process.

Translate process design decisions into requirements, backlog items, data needs, architecture considerations, business rules, and test cases.

Foundation

Why Model Processes

Much of the software we build (if not all) needs to support an organizational process. To design that software well, you need to understand how the work happens today and how it should work in the future. That means looking at the steps people follow, the decisions they make, the systems they use, the information they need, and the hand-offs that move work from one person or system to another.

Process models make that work visible, by illustrating the sequence of steps, the decisions people make, the hand-offs between roles or systems, and the information that moves along the way.

This matters because many requirements are hidden in the process. A person may describe their role simply as "I approve requests," but the process model shows what that approval actually involves: who submits the request, what information must be checked, who has authority to approve it, what happens when it is rejected, which systems are used, and what record must be kept.

That level of complexity can be hard to capture in a single user story. User stories are useful for describing discrete needs, but they do not show the larger process that shapes how work gets done. A process model gives you that bigger picture before you translate the work into stories, requirements, backlog items, or system behavior.

When you map a process with stakeholders, you can see how work happens, where it breaks down, and where a better process may be needed. Building these models with your stakeholders helps people from different roles develop a shared understanding of the work (Jones & Bowes, 2017).

Process design helps you:

See hidden requirements. Hand-offs, shared data, decision rules, failure paths, and system interactions become visible before they are buried in code.

Create a shared reference point. Operations, engineering, compliance, product, and design can point to the same step and discuss what needs to happen.

Reduce rework. It is easier to fix a misunderstanding in a diagram than after the system has been built.

Inform the work that comes next. Process models help you identify architecture requirements, data needs, backlog items, business rules, test cases, and operational procedures.

Approach

The Process Design Process

Process design starts by making the current process visible. The current process is often called the as-is process. It shows the work as it happens now, including the unofficial workarounds that may not appear in policy documents or procedure manuals.

Mapping the as-is process gives you something concrete to study. You can see where people wait, get confused, re-enter information, fix errors, search for missing context, or work around the official process. These friction points often point to opportunities for improvement.

The improved process is often called the future state or to-be process. It shows how the work should happen after the redesign. The to-be process makes your design choices visible: which steps stay, which are removed, which are simplified, which are automated, which require human judgment, and how the redesigned process should flow.

Identify Process Design Opportunities

Once you have mapped the as-is process, look for places where the process creates unnecessary effort, confusion, delay, risk, or poor user experience.

Common opportunities include waiting, rework, unclear ownership, excessive hand-offs, hidden work, missing information, and weak failure paths. These are not just operational annoyances. They often point directly to product and system requirements.

For example, missing information may suggest a data requirement, unclear ownership may suggest a workflow or permission requirement, and weak failure paths may suggest exception handling or escalation requirements.

Design the To-Be Process

After you understand the as-is process, design the to-be process. Do not simply redraw the current process with a new system added. Decide how the work should change.

As you design the to-be process, ask:

Which steps should stay because they create value or reduce risk?
Which steps can be removed, simplified, or combined?
Which steps should be automated, and which still require human judgment?
Where should the process provide status, confirmation, or feedback?
What information does each actor need to complete their step?
What business rules does the system need to apply?
What should happen when the process fails, times out, or receives incomplete information?
What needs to be logged, reviewed, approved, or auditable?

A good to-be process makes the work easier to understand and easier for people to carry out. It clarifies who is responsible, removes steps that no longer add value, shows where automation can help, and improves the experience for the people using or supporting the service.

Choosing the Right Model

Different process models help you answer different design questions. Some give you a broad view of a service. Others show the detailed steps, decisions, systems, and rules that shape a specific process.

In this chapter, we focus on two common models: service blueprints and workflow diagrams. Use a service blueprint when you need to understand how a service is delivered end to end, including what the user sees and what happens behind the scenes. Use a workflow diagram when you need to drill into one process and understand who does what, in what order, with what decisions and hand-offs.

You can use these models together, as a service blueprint helps you see the broader service experience and using a workflow diagram lets you zoom in on one part of that service where the work is complex, risky, or important for implementation.

Technique	What it explores	Best used when	Audience
Service blueprint	How the whole service works end to end, including what users see and what happens behind the scenes.	You need to understand or redesign a service experience and the organizational work that supports it.	Customers, operations, design, product, engineering, leadership.
Workflow diagram	Who does what, in what order. The decisions, rules and hand-offs between roles and systems.	You need to understand or redesign one operational process.	Operations, product, business analysts, engineering.

Process Model Fidelity

Process models can be rough or polished depending on where you are in the design process.

For example a whiteboard sketch works well during a workshop when you are exploring or defining a process with stakeholders, but you might use a more structured diagram when you need to review the process with a broader group, keep it as part of the project record, or give the development team a reference they can use during implementation.

Choose the level of fidelity that fits the decision in front of you. Modeling in more detail than the decision requires wastes effort and can make the important parts harder to see.

Service Blueprints

A service blueprint helps you understand and design a service from both sides: what the user experiences and what the organization does to make that experience possible (Stickdorn et al., 2018). It shows the user's actions, the work the user can see, the work that happens behind the scenes, and the support processes that sit behind the service. In service design, the visible work is often called frontstage work, while the behind-the-scenes work is called backstage work. Seeing both sides together helps you identify hand-offs, hidden work, integration points, and places where the service may break down.

Service blueprints are usually organized sequentially. You read them from left to right, following the stages of the service over time. Within each stage, the content is organized from top to bottom in horizontal bands that help show what the user experiences, and the organizational work needed to support it.

Fig 9.1 — A service blueprint organizes work into four stages and five bands, separated by three lines

How to Create a Service Blueprint

Service blueprints are best created with people who understand different parts of the service. Include people who work directly with users, people who support the backstage process, and people who understand the systems, policies, or data the service depends on. This helps the blueprint show both the official process and how the service works in practice.

Start by choosing the service or scenario you want to model. Keep the scope specific enough to follow from beginning to end. For example, "book and attend an advising appointment" is a better scope than "student advising."

Next, identify the major stages of the service. These stages become the columns of the blueprint and are read from left to right. For an advising appointment, the stages might include "search for advising options," "book appointment," "receive reminder," "attend appointment," and "receive follow-up."

Then fill in the blueprint using five horizontal bands (Stickdorn et al., 2018):

Physical evidence. List the things the user sees, touches, or receives during each stage, such as a confirmation email, printed receipt, kiosk screen, door sign, or dashboard message. This helps you identify what the user actually experiences and where communication may be missing or inconsistent.

Customer actions. Describe what the user does at each stage. Write these from the user's perspective, such as "looks up office hours," not "performs query against location service."

Frontstage actions. Capture the actions employees, systems, or interfaces perform that the user can directly perceive. This might be a staff member greets the user, website search results, a kiosk prints a ticket etc.

Backstage actions. Show the work employees or systems do out of view, but that support the frontstage interactions. For example, a nurse pulls the patient's chart, a scheduling service confirms the appointment slot, or an order management system checks stock.

Support processes. Identify and include the systems, teams, policies, and data that make the service possible but do not usually act in real time during a single user interaction. This may include systems, infrastructure, policies.

As you build the blueprint, use three horizontal lines to separate different kinds of work:

The line of interaction shows where the user directly interacts with the organization, such as speaking with an employee, using a website, receiving a notification, or submitting a request.

The line of visibility separates what the user can see from what happens behind the scenes. Work above this line is part of the user's direct experience. Work below this line is hidden but still essential.

The line of internal interaction separates backstage work that directly supports the user interaction from the broader support processes that make the service possible.

Finally, review the blueprint for gaps and failure points. Ask where information moves between people or systems, where users wait, where duplicate work happens, where errors occur, and what happens when a backstage step fails. Those points often become requirements, integration needs, backlog items, or areas for deeper workflow modeling.

After you understand the as-is service, create a to-be version. Use it to show what should change: unnecessary steps removed, communication improved, backstage work shifted or simplified, repetitive checks automated, or hand-offs made clearer.

Workflow Diagrams

Workflow diagrams help you understand and design one process from start to finish. They show who does each step, what happens next, where decisions happen, what rules apply, and where work moves from one person, team, or system to another.

Workflow diagrams include swimlanes for the main actors or roles, such as a customer, staff member, department, system, or external partner. When work moves from one swimlane to another, the hand-off becomes visible. If the process keeps bouncing between people, teams, or systems, the diagram makes that coordination problem easy to see.

Keep in mind that workflow diagrams can be formal or simple. A quick sketch may be enough when you are trying to understand the current process or discuss a proposed change with stakeholders.

Fig 9.2 — A simple workflow diagram with three swimlanes, a hand-off, a decision, and two outcome paths

When to Use a Workflow Diagram

Use a workflow diagram when you need to:

Understand how a single operational process flows from start to finish.
Design how that process should work in the future.
Identify which actor or system performs each step.
Surface hand-offs, decisions, and business rules that affect the system design.
Compare an as-is process to a proposed to-be process.
Specify the process clearly enough for implementation, automation, testing, or operational hand-off.

How to Create a Workflow Diagram

Workflow diagrams are often best created with the people who know the work. In a participatory workshop, include the people who perform, support, or are affected by the process. Build the as-is diagram together using a whiteboard, sticky notes, paper, or whatever works best in your workshop setting.

Ask participants to identify missing steps, hand-offs, exceptions, delays, business rules, and workarounds. Then use what you learn to design the to-be workflow.

To create a simple workflow diagram, start with a few common elements:

Rounded rectangle or oval. The start or end of the process.

Rectangle. A task being performed.

Diamond. A decision point with labeled outcomes, such as "approved" and "rejected."

Arrow. The direction of the work.

Swimlane. A horizontal or vertical band labeled with an actor, such as a person, role, team, or system.

These shapes give you a common visual vocabulary that most business people can follow, making your diagram easier to read. You can also add annotations, callouts, or other cues when they help your audience understand what is happening and follow the logic of the process.

Start by choosing one process to model. Keep the scope narrow enough to manage. It is usually better to begin at a high level, sketch the overall process, and then iterate. Once the main flow is clear, you can dive into specific parts of the process or related subprocesses in more detail.

Next, identify the main actors involved in the process. These may be people, organizational roles, teams, systems, or external partners. Give each actor its own swimlane.

Then add the main steps in sequence. When you label a step in a workflow, use specific verbs and clear nouns. The verb should describe the action being performed. The noun should name the thing being acted on. Avoid broad verbs such as handles, manages, processes, supports, or works on unless you explain the specific action. Instead of writing "advisor processes application," write "reviews application materials," "checks prerequisite completion," or "updates application status."

Show where decisions occur and how they change the path of the process. Label each outcome clearly, such as approved, rejected, complete, or missing information. Every branch should lead somewhere, including paths where work stops, escalates, or is sent back for correction.

Finally, review the diagram with stakeholders. The people who perform, support, or are affected by the process will spot missing steps, exceptions, business rules, and workarounds you did not capture. Use what you learn to refine the diagram, clarify ambiguous steps, fill in missing branches, and correct anything that does not match how the work actually happens. If the diagram is hard to follow during the review, that is a signal to simplify it, split it into subprocesses, or clean up the layout before moving on.

Once the as-is workflow is mapped, create a to-be version. Do not simply add a new system step to the current process. Remove unnecessary steps, clarify ownership, reduce hand-offs, add missing feedback loops, make exception paths explicit, and mark the rules the system needs to apply.

Process Modeling for AI and Agentic Systems

As organizations add AI to their processes, some steps may be performed, shaped, or recommended by the AI system. A loan application might be pre-screened before a human reviewer sees it. A customer support request might be classified, routed, or drafted by AI. A scheduling tool might suggest meeting times based on past patterns.

You need to decide where AI fits in the process, what information it can use, where human judgment is still needed, how its output will be reviewed, and what happens when that output is wrong, incomplete, or uncertain (Yildirim et al., 2022).

These choices are easy to miss as stakeholders may not see the prompt instructions, model settings, tool access, data sources, review steps, or fallback paths unless the process model makes them explicit.

A process model makes those choices visible before they are buried in the system. That gives the team a chance to discuss accountability, oversight, reliability, data use, and exception handling while the design can still change.

When diagramming AI-enabled systems, you should:

Name the AI step clearly. Give the step a specific activity label, the way you would for any other actor or system. For example "Classifies the request and drafts a response" tells your team and stakeholders what the system actually does, where the label "AI" does not.

Do not hide AI inside a generic system lane. Treat the AI capability like any other system actor when its actions matter. Show what it receives, what it produces, what tools it can call, what records it updates, and who reviews or overrides its output.

Show what the AI uses and changes. If the AI reads a policy document, queries a database, calls an external service, updates a record, or sends a message, show that connection on the model. These are integration points, data flows, and possible risk points (Konrad et al., 2026).

Show what happens when the AI is wrong or uncertain. AI systems can produce incorrect, incomplete, or out-of-scope outputs, so your model should show what happens next (Weisz et al., 2024). In many cases, that means routing the work to a human reviewer, exception queue, or alternate process.

Show where a person stays in the loop. In many enterprise processes, a person still reviews, approves, or can override what the AI produces. Mark those checkpoints on the diagram. These are choices about judgment, accountability, and oversight, not failures of automation.

From Process Design to Development

Once the diagram has been refined with stakeholders, hold a final walkthrough with the process owners and the development team. Use this walkthrough to confirm that the process is clear enough to guide development decisions and to surface any remaining gaps before the work is translated into requirements, backlog items, or code.

The diagrams also help you move from process design into development:

Identify architecture requirements. Integration points, shared data entities, performance constraints, reliability requirements, and security boundaries often become visible in the process design. For example, the model may show where a step must complete in seconds rather than minutes.

Clarify business rules and system behavior. Decision points in the model often reveal rules the system needs to apply. For example, the system may need to check whether a request is complete, whether a user has permission to approve it, whether a deadline has passed, or whether an exception should be routed to a human reviewer. These rules need to be clear enough for the team to design, build, and test them.

Inform and refine the backlog. Each meaningful step in the to-be process may become a backlog item, test case, or operational task. Hand-offs and integrations are often backlog items in their own right because they require coordination with other teams or systems. Failure handling, escalation paths, and business rules are easy to miss unless they are shown explicitly in the process model.

Give developers a process reference. During development, the model helps the team check whether the system behavior matches the intended process. Developers can use it to understand what should happen before and after a step, which decisions change the path, what records need to be updated, and what should happen when the process fails, branches, or loops back for correction.

Best Practices

Use these practices to keep process models focused, readable, and useful.

Match the model to the decision. Choose the level of detail needed to help you and your stakeholders understand the process and make decisions.

Separate the as-is from the to-be. The as-is process shows the current work. The to-be process shows the proposed redesign. Keeping them separate helps stakeholders see what is changing and why.

Identify exceptions. Cancellations, disputes, exceptions, delays, missing information, failed integrations, and escalations are where many real requirements appear. A model that shows only the "happy path" may describe an unrealistic version of the service or process, not reality.

Label activities. Use specific verb and noun labels for workflow steps and avoid vague phrases.

Show important actors and systems separately. If the process involves several systems, partners, vendors, or AI components, show them separately when their hand-offs matter. The boundaries between systems are often where integration, security, reliability, and accountability requirements appear.

Complete decisions. Every decision point should have two labeled outcomes, and every outcome should lead somewhere. Include the paths where the work stops, escalates, loops back, or is sent for correction.

Capture the rules behind decisions. A diamond on a workflow diagram should not just say "approved?" or "eligible?" The team needs to know what makes something approved, rejected, eligible, incomplete, or ready for review. Those rules often become validation logic, permissions, notifications, routing, or test cases.

Keep the model readable. Large diagrams with too many lanes, crossing arrows, or unlabeled branches quickly stop being useful. If the model is too large for one readable page, split it into a high-level model and one or more detailed subprocesses.

Walk the model with stakeholders. A model is a conversational artifact, not a finished spec. A walkthrough with the people who perform, support, or are affected by the process almost always surfaces something you missed.

Update the model when the process changes. Process models go stale when systems, policies, prompts, tools, responsibilities, or organizational processes change. Review the model when those changes affect how work actually happens.

Wrap Up

You started this chapter with operational work that may have lived in people's heads, scattered procedures, and informal conventions. You now have process models that make sequence, hand-offs, decisions, exceptions, and AI involvement explicit, including the moments when a person needs to review, approve, or override what the system produces.

In the next chapter, you will use the integration points, shared data entities, and information flows surfaced by these models to create data flow diagrams and a data dictionary. These artifacts help you understand and describe what information moves through the system, where it comes from, where it goes, and what rules govern it.

References and Further Reading

Chen, X. A., Knearem, T., & Li, Y. (2025). The GenUI study: Exploring the design of generative UI tools to support UX practitioners and beyond. In Proceedings of the 2025 ACM Designing Interactive Systems Conference (DIS '25) (pp. 1179–1196). Association for Computing Machinery.

Jones, P. H., & Bowes, J. (2017). Rendering systems visible for design: Synthesis maps as constructivist design narratives. She Ji: The Journal of Design, Economics, and Innovation, 3(3), 229–248.

Konrad, P. M., Adam, T. L., Terrenzi, R., & Ayvaz, S. (2026). Architecture without architects: How AI coding agents shape software architecture. arXiv.

Kuehnert, B., Kim, R., Forlizzi, J., & Heidari, H. (2025). The "who", "what", and "how" of responsible AI governance: A systematic review and meta-analysis of (actor, stage)-specific tools. In Proceedings of the 2025 ACM Conference on Fairness, Accountability, and Transparency (FAccT '25) (pp. 2991–3005). Association for Computing Machinery.

Levy, O., Dikman, I., Levy, N., & Winokur, M. (2026). AI-assisted requirements engineering: An empirical evaluation relative to expert judgment. arXiv:2604.15222.

Object Management Group. (2014). Business process model and notation (BPMN), version 2.0.2.

Qi, X., & Yu, J. (2025). Participatory design in human-computer interaction: Cases, characteristics, and lessons. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI '25). Association for Computing Machinery.

Schroeder, H., Aubin Le Quéré, M., Randazzo, C., Mimno, D., & Schoenebeck, S. (2025). Large language models in qualitative research: Uses, tensions, and intentions. In Proceedings of the 2025 CHI Conference on Human Factors in Computing Systems (CHI '25). Association for Computing Machinery.

Shostack, G. L. (1984). Designing services that deliver. Harvard Business Review, 62(1), 133–139.

Stickdorn, M., Hormess, M. E., Lawrence, A., & Schneider, J. (2018). This is service design doing: Applying service design thinking in the real world. O'Reilly Media.

Van der Bijl-Brouwer, M., & Malcolm, B. (2020). Systemic design principles in social innovation: A study of expert practices and design rationales. She Ji: The Journal of Design, Economics, and Innovation, 6(3), 386–407.

Weisz, J. D., He, J., Muller, M., Hoefer, G., Miles, R., & Geyer, W. (2024). Design principles for generative AI applications. In Proceedings of the CHI Conference on Human Factors in Computing Systems (CHI '24). Association for Computing Machinery.

Yildirim, N., Kass, A., Tung, T., Upton, C., Costello, D., Giusti, R., Lacin, S., Lovic, S., O'Neill, J., O'Reilly Meehan, R., Ó Loideáin, E., Pini, A., Corcoran, M., Hayes, J., Cahalane, D., Shivhare, G., Castoro, L., Caruso, G., Oh, C., … Zimmerman, J. (2022). How experienced designers of enterprise applications engage AI as a design material. In Proceedings of the 2022 CHI Conference on Human Factors in Computing Systems (CHI '22). Association for Computing Machinery.

No part of this publication may be reproduced, distributed, or transmitted without prior written permission.