Modeling Processes and Services

In earlier chapters, you explored the problem or opportunity, defined the product vision and goals, and identified user needs.

This chapter explores how to map the organizational processes behind your solution. Because most information systems support complex, cross-functional workflows, you need to understand exactly how work moves between departments, systems, and external partners before a task can be completed.

Why Model Processes

Most software used in an organization exists to support the organization's processes. 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 handoffs 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 handoffs between roles or systems, and the information that moves along the way.

This matters because many requirements are hidden in the process. For example, someone 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.

Process design helps you:

• See hidden requirements. Handoffs, 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.

What you learn may also change the strategic case for the initiative. A proposed process may require more organizational change, cost, or risk than expected, or the analysis may show that a policy or process change could address the problem without new technology. In those cases, revisit the product vision, goals, scope, priorities, and expected investment before moving further into development.

How Process Design Works

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 handoffs, 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 handoffs.

You can use these together. A service blueprint shows you the broader service experience; a workflow diagram lets you zoom in on one part of that service where the work is complex, risky, or important for implementation.

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 handoffs, 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.

What Is Service Design?

Service design is a larger practice focused on designing services across people, touchpoints, systems, policies, and operations. Service blueprints are one of its core tools. In this chapter, you are using the blueprint as a practical way to understand how a service works and where a product or information system needs to support it. If you want to go deeper, This Is Service Design Doing and This Is Service Design Methods are useful starting points.

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. For example, a support agent updates an employee's account, an application displays an approval status, or a self-service portal confirms that a request has been submitted.
• 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.
• Supporting processes. Identify the internal teams, systems, policies, infrastructure, and data that enable the frontstage and backstage work. These processes may occur before, during, or after the user interaction. What distinguishes them is that they enable service delivery without forming part of the user's direct experience.

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 handoffs 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.

A workflow diagram can use swimlanes to show which person, role, team, system, or partner performs each step. Use swimlanes when you need to identify and visualize ownership and handoffs.

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.

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 handoffs, 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 handoff.

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, handoffs, 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 "advisor reviews application materials," "advisor checks prerequisite completion," or "advisor 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 handoffs, add missing feedback loops, make exception paths explicit, and mark the rules the system needs to apply.

Business Process Model and Notation

Business Process Model and Notation (BPMN) is a standard for diagramming business processes (Object Management Group, 2014). It defines a specific set of shapes to represent events, activities, decisions, flows, and other elements of a process. You don't need to use BPMN for every workflow diagram you create, especially during early discovery work. But it is useful to recognize BPMN because many professional process modeling and workflow automation tools use BPMN or BPMN-like notation.

Process Modeling for AI-Enabled 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 “The LLM classifies the request and drafts a response” tells your team and stakeholders what the system actually does, whereas 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. Show these connections to help understand and explore integration, data, security, reliability, and accountability requirements.
• 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. Handoffs 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.

References and Further Reading