What are you trying to show?
I want to show how a service actually runs across a few stages: what the customer does, what they can see, and what stays hidden. The reader should see the line of visibility — the moment a failure is backstage (a billing job, a fraud check, a queue) even though the customer row still looks like a simple retry.
A user journey is the wrong figure here. That type is for how the experience feels. A swimlane is also wrong: that type is flow across owners, not a census of onstage vs offstage work. A process diagram is sequential handoffs, not a layered split.
Sketch of the claim:
Sign up Activate Hit limit Upgrade Invoice
Customer Create acct Use product Retry pay Pick plan Read bill
────────────────────────────────────────────────────────────
Front Welcome In-app nags Pay modal Checkout Receipt
========== visibility ================================================
Back CRM write Usage meter Dunning job* Tax calc Ledger
Support Email Analytics Card processor GL
* the one cell the figure exists to show
Proposed solution
A new visual type, Service blueprint, with the usual shipping set: references/type-service-blueprint.md, light / dark / full examples, gallery tab, SKILL.md selection row, and a verifier that the visibility line sits between frontstage and backstage on one shared stage grid.
No arrows in the first version — stage order is the sequence. Wait times and system names are cell text. One accent cell.
Route away from journey / swimlane / process in those references so the skill does not draw the wrong figure.
Scope
New diagram type (reference + 3 examples + gallery)
Design-system fit
What are you trying to show?
I want to show how a service actually runs across a few stages: what the customer does, what they can see, and what stays hidden. The reader should see the line of visibility — the moment a failure is backstage (a billing job, a fraud check, a queue) even though the customer row still looks like a simple retry.
A user journey is the wrong figure here. That type is for how the experience feels. A swimlane is also wrong: that type is flow across owners, not a census of onstage vs offstage work. A process diagram is sequential handoffs, not a layered split.
Sketch of the claim:
* the one cell the figure exists to show
Proposed solution
A new visual type, Service blueprint, with the usual shipping set:
references/type-service-blueprint.md, light / dark / full examples, gallery tab, SKILL.md selection row, and a verifier that the visibility line sits between frontstage and backstage on one shared stage grid.No arrows in the first version — stage order is the sequence. Wait times and system names are cell text. One accent cell.
Route away from journey / swimlane / process in those references so the skill does not draw the wrong figure.
Scope
New diagram type (reference + 3 examples + gallery)
Design-system fit