Service blueprints have no markup language
Flowcharts have Mermaid. Architecture diagrams have Structurizr and the C4 model. Sequence diagrams have PlantUML. Even BPMN has a text syntax now. But service blueprints — one of the most widely used tools in service design — have nothing.
The landscape
I went looking for a way to write a service blueprint as code. Here's what I found:
- Mermaid — no swimlane support. Requested since 2017, still in triage in 2025. Nine years and counting.
- PlantUML — has vertical swimlanes in activity diagrams (
|Lane| :action;), but no service blueprint semantics and the lanes run the wrong way. - D2 — modern diagram language with nested containers, but swimlanes are a feature request, not a feature.
- Kroki — aggregates 30+ diagram types. None are service blueprints.
- Miro, FigJam, Lucidchart, Smaply — all have templates, all are visual-only.
There is no text-based syntax for service blueprints. Not a single one.
The problem
Visual tools like Miro and FigJam couple content to layout. The blueprint data — steps, layers, connections — has no existence independent of its visual arrangement. Every time the service changes, you're rejigging boxes and arrows instead of updating a definition.
There's no way to version-control a service blueprint. No way to diff one. No way to review changes in a PR. The layout is the single source of truth, and it's fragile.
The notation isn't standardised either
Service blueprint notation comes from G. Lynn Shostack's 1984 paper in Harvard Business Review, later extended by Zeithaml and Bitner. The Nielsen Norman Group's definition is the closest thing to a modern standard: four layers (customer actions, frontstage, backstage, support processes), a physical evidence row, and three dividing lines (interaction, visibility, internal interaction).
But it's a convention, not a specification. There's no formal standard like UML or BPMN 2.0.
The opportunity
This is a gap worth filling. Service blueprints are used across UX, service design, and product teams. They map neatly to a structured text format — the layers are fixed, the flow is left-to-right, and the relationships between steps are the interesting bit.
A text syntax for service blueprints would mean:
- Version control — track how a service evolves over time
- Diffs and PRs — review blueprint changes alongside code
- Automation — generate blueprints from data, or extract data from blueprints
- Portability — no vendor lock-in to a specific drawing tool
I've started building this: mermaid-service-blueprints. The goal is a clean text syntax that renders as SVG, with a path toward becoming a Mermaid plugin via their external diagram API.
Further reading
- NNG: Service Blueprints — Definition
- Shostack, 1984: Designing Services That Deliver
- Kazemzadeh et al: Service Blueprinting vs BPMN
- Mermaid swimlane discussion (2025)
- Service Design Tools: Service Blueprint