Teams building AI features often struggle with a simple question: "where, exactly, does the AI live in our service, and how should people interact with it?" Designers face low AI literacy, engineers focus on models rather than experiences, and stakeholders worry about ethics and regulation. AI-driven service blueprints are a way to put all of this on one shared map—and in this post, that map is backed by an open-source analyser you can run from GitHub.
This article is for engineers, UX and service designers, and product/ops people working with AI who need a practical, inspectable way to design responsible, human-centred AI systems—without becoming machine learning experts.
What Is an AI-Driven Service Blueprint?
Traditional service blueprints show how a service works across time: customer actions, frontstage interactions, backstage processes, and supporting systems. AI-driven service blueprints extend this by adding a dedicated AI swimlane that makes model inputs, outputs, confidence levels, and human oversight points explicit.
A simple example for a content-moderation flow:
- User lane: user writes a post → submits.
- AI lane: model analyses text → outputs “safe/harmful” + confidence score.
- Human lane: moderator reviews low-confidence or contested cases.
- Governance lane: logs decisions, flags patterns (e.g. many user complaints against “safe” decisions).
By visualising the AI behaviour alongside human roles, teams can see where explanations are needed, where automation is unsafe, and where governance checks should sit—before the system is built.
Why We Need This: Gaps in Human-Centred AI Practice
Current HCAI and explainable AI work gives us model dashboards and post-hoc explanations, but offers less support during the conceptual design phase when service flows are being defined. Designers often lack tools to:
- understand realistic AI capabilities and limits,
- align model behaviour with user mental models, and
- check ethical and legal requirements in context (e.g. who can override what, when, and based on which evidence).
AI-driven service blueprints address these gaps by treating explainability and governance as service-level concerns, not just UI-level add-ons. They help multidisciplinary teams reason about AI as one more actor in the service, with clear responsibilities and constraints.
From Paper to Repo: AI-Driven Service Blueprint Analyzer
The CHI 2026 workshop paper introduced AI-driven service blueprints as a conceptual tool for human-centred AI experience design. To move from concept to practice, the GitHub project AI-DrivenServiceBlueprintAnalyzer implements an early prototype of an analyser that can inspect service blueprints and surface design questions.
Right now, the tool is intentionally minimal and aimed at technical users:
- it expects a JSON / JSONL representation of a service blueprint (lanes, steps, actors, AI components),
- a fine-tuned model (wrapped in a small Flask app) processes this structure,
- the model then produces observations about AI touchpoints, possible risks, and questions you can take into a design session.
There is no polished web front-end yet. For most designers, this is not plug-and-play; the current version is closer to an “engine” you can call from scripts or internal tools than a finished product. That limitation is deliberate: the research contribution comes first, and the interface will grow from there.
Getting Started (If You’re Comfortable with JSON)
If you are a developer, researcher, or technically inclined designer, you can already experiment with the analyser.
1.Clone the repo:
git clone https://github.com/Mehredad/AI-DrivenServiceBlueprintAnalyzer.git
cd AI-DrivenServiceBlueprintAnalyzer
2.Install dependencies:
pip install -r requirements.txt
3.Prepare a JSON/JSONL blueprint:
Create a small file, for example blueprint_example.json, that encodes your service flow. A simplified structure might include:
- actors (user, AI system, human staff, back-office systems),
- steps in order,
- links showing which actor performs which step,
- flags where AI is involved.
4.Call the Flask endpoint / script:
Depending on the repo’s current entrypoint, this might look like:
python analyze_blueprint.py --input blueprint_example.json --output report.md
or sending the JSON to a local Flask endpoint and capturing the response.
5.Use the output in workshops:
The model’s output can highlight:
- steps where AI makes decisions without human review,
- parts of the flow that lack explanations,
- points where confidence thresholds or audit trails are unclear.
This reflects what the research paper(ACM,2024) proposes conceptually: AI participates in blueprint evolution by monitoring the structure, surfacing discrepancies between expectations and behaviour, and feeding those insights back into participatory design.
Next Step: A Designer-Friendly Web Interface
From a human-centred design perspective, a JSON-only interface is not enough. Most service designers work visually, sketching and rearranging flows rather than editing structures by hand. The next step for this project is therefore clear:
- build a web application on top of the existing Flask backend,
- allow designers to create or import blueprints visually (e.g. drawing lanes and steps),
- call the fine-tuned model behind the scenes,
- overlay the model’s findings directly onto the blueprint as annotations, hotspots, and discussion prompts.
This would turn the analyser from a research prototype into a practical, everyday tool that fits existing service design workflows, while still grounding it in the methodological foundations described in the paper.
How to Use This in Your Team Today
Even in its current form, you can integrate the idea of AI-driven service blueprints into your process:
- Designers & PMs: sketch the blueprint with an explicit AI swimlane, and list questions you’d want the analyser to answer (e.g. “Where do we need human overrides?”).
- Engineers / Researchers: encode a simplified JSON version and run it through the analyser to generate prompts and risk flags.
- Together: review the output in a workshop and update the blueprint, noting where future UI support would make the process smoother.
This gives you a repeatable, research-backed method for aligning AI capabilities with human needs, regulatory expectations, and organisational responsibilities—even before the visual tooling is in place.
Why This Matters to practitioners?
For teams working on real AI products, AI-driven service blueprints are not just a research idea—they are a practical way to make model behaviour, explanations, and governance visible in the same diagram as your users, staff, and systems. They extend familiar service blueprinting so you can reason about non-deterministic AI behaviour and ethical risks at the service level, not only in the model console.
This project sits on top of peer‑reviewed work: the concept is introduced in “AI-Powered Service Blueprints for Enhancing Human-Centred AI Design Processes” (ACM, 2024), and the analyser moves that idea towards something you can actually run against your own flows. Referencing both the paper and the repo shows how research insights can be turned into concrete tooling for day‑to‑day product and design work.
If you are experimenting with AI in your organisation, you can start small: take one service, sketch an AI-driven blueprint, encode a lightweight JSON version, and run it through the analyser. If you find gaps, edge cases, or have ideas for a more designer‑friendly web interface, opening an issue or a discussion in the GitHub repo is the best way to shape the next iteration.
Links:
GitHub repo: AI-DrivenServiceBlueprintAnalyzer– https://github.com/Mehredad/AI-DrivenServiceBlueprintAnalyzer
AI-Powered Service Blueprints for Enhancing Human-Centred AI Design Processes– https://dl.acm.org/doi/10.1145/3701268.3701280
Top comments (0)