Service Blueprint Architect — Self-Initiated-Proprietary working Product

Self-Initiated-Proprietary working Product

Service Blueprint Architect

Product Designer & Architect·14 weeks (planned)·2026

Service Blueprint Architect is a self-initiated product design project: a mobile-first, web-based platform that helps UX designers create, manage, and govern service blueprints collaboratively. The work covered the full spectrum of product design — from strategic architecture through data modelling, RBAC system design, API specification, and a five-phase implementation plan.

Client
Self-Initiated
Role
Product Designer & Architect
Duration
14 weeks (planned)
Year
2026

The Problem Statement

The Problem Statement

Service design is inherently collaborative, yet most teams were using disconnected tools: whiteboards, spreadsheets, Google Slides, and email chains. There was no single source of truth — and no way to govern changes, track approvals, or maintain version history across a team.

Service designers need to visualise complex user journeys across multiple actors, touchpoints, and phases. Teams need to approve changes, coordinate tasks, and audit decisions. Yet existing tools are either too simple for team use or too heavyweight and generic for service design specifically.

The core challenge: how do you build a tool that serves a solo designer, scales to a multi-person team with a governance workflow, and does all of this accessibly on mobile?

The Strategy

The Strategy

Five architectural decisions shaped everything that followed.

CMS-style staging over real-time collaboration — governance requires explicit approval. One draft per user per blueprint eliminates merge conflicts and supports decision-making workflows without the complexity of operational transformation. Simpler architecture, clearer team alignment.

WCAG 2.1 AA accessibility from Phase 1, not Phase 5 — accessibility forces clarity. Clear focus states, semantic HTML, and logical keyboard navigation benefit all users, and a mobile-first approach naturally emerges from the same constraints.

A four-role RBAC system (Owner, Editor, Stakeholder, Viewer) — roles that map to actual team personas rather than an admin/user dichotomy. Separating editing from approving from publishing removes ambiguity and enables genuine governance.

A canonical data schema as a single source of truth — one JSON structure that all input formats, transformations, and exports conform to. Consistency, testability, and future-proof integrations follow.

A five-phase modular build plan — breaking 14 weeks into pauseable, testable phases means an MVP can ship after Phase 2 without abandoning the broader vision.

Service Blueprint Architect — architectural decision overview.
Service Blueprint Architect — architectural decision overview.

Approach

Approach

The design work spanned five distinct activities, each producing a concrete artefact that feeds into the implementation.

01

Problem Definition & Scope Setting

Mapping the gap between how service design teams actually work (disconnected tools, email approval chains, lost version history) and what a purpose-built platform could provide. Defined the initial scope as a mobile-friendly blueprint creation tool, which evolved into a full collaborative platform with drafting, approval workflows, task management, version control, and RBAC.

02

Architectural Decision-Making

Evaluating the core trade-offs: real-time collaboration vs CMS-style staging; granular permissions vs semantic roles; format-specific data models vs a canonical schema. Each decision was documented with the alternatives considered and the rationale for the chosen approach — producing a decision log that any developer can follow.

03

Data Modelling & API Specification

Designing eight normalised PostgreSQL tables covering users, blueprints, drafts, tasks, approval workflows, audit logs, notifications, and permissions. Specifying 26 REST API endpoints with RBAC applied at every layer — authentication, authorisation, and business logic kept cleanly separated.

04

Governance & RBAC System Design

Designing the four-role permission system and the approval workflow engine — how drafts move from creation through review to published state, how Stakeholders approve without editing access, and how the audit log captures every state change for accountability.

05

Phased Implementation Planning

Producing a 14-week plan with five self-contained, pauseable phases: Foundation (auth + schema), Core Editor (input parsing + export), Collaboration (drafts + approvals), Task Management, and Real-Time + Accessibility polish. Each phase has clear completion criteria so work can pause and resume without losing context.

The Solution

The Solution

The output is a complete product specification — 15,000+ words covering every layer of the platform.

The frontend is React with a mobile-first responsive design (320px, 640px, 1024px breakpoints), touch-first interaction targets, keyboard navigation, ARIA labelling, and prefers-reduced-motion support throughout.

The core logic is four modular subsystems: an Input Layer accepting prose, CSV, Q&A, and image-based entry; an Enrichment Layer that suggests touchpoints and infers pain points; a Visualisation Layer producing HTML, SVG, XLSX, and Figma exports; and the Canonical Schema binding them all together.

The backend is Node.js with PostgreSQL — JWT authentication with refresh tokens, RBAC on every endpoint, a draft/publish workflow, an approval engine, task management, audit logging, and WebSocket support for real-time notifications.

The first thing I would do is probably use the tool to build out a stable blueprint. I can use AI to help get it setup and then start from a point of familiarity to test the collaboration and governance workflows with real users.
The first thing I would do is probably use the tool to build out a stable blueprint. I can use AI to help get it setup and then start from a point of familiarity to test the collaboration and governance workflows with real users.
RBAC and account management workflows — the Owner creates a blueprint, invites Editors and Stakeholders, and manages permissions. Editors can create drafts, but only Stakeholders can approve them to publish. This can happen anywhere, anytime.
RBAC and account management workflows — the Owner creates a blueprint, invites Editors and Stakeholders, and manages permissions. Editors can create drafts, but only Stakeholders can approve them to publish. This can happen anywhere, anytime.

Outputs

Outputs

15,000+Word architectural specification, ready for developer handoff
26REST API endpoints fully defined with RBAC applied
WCAG 2.1 AAAccessibility standard targeted from Phase 1, not Phase 5

The project produced a complete, implementation-ready specification: a five-phase plan, a database schema with eight normalised tables, 26 fully defined REST API endpoints, a four-role RBAC system, a mobile-first responsive design, a WCAG 2.1 AA compliance framework, and a progress tracking system so development can pause and resume at any phase boundary without losing momentum.

Reflection

Reflection

The clearest lesson from this project was that governance is architecture — approval workflows, role separation, and version control aren't features you bolt on at the end, they're decisions that shape the entire platform from the data model upward. Choosing CMS-style staging over real-time editing wasn't a compromise; it was the right architectural fit for the domain.

Building for accessibility from the start also proved its value. Designing for keyboard navigation, semantic HTML, and clear focus states forced better UX decisions across the board — it made the mobile experience sharper, not harder.

The main thing I would do differently: validate the collaboration workflow with real service design teams earlier, before the data model is fully locked. The RBAC system reflects reasonable assumptions about team structure, but the approval workflow in particular would benefit from observational research with teams doing live governance work.

Project Gallery

Project Gallery

Use this tool to communicate the vision to executives and developers alike — the architectural decisions, the rationale, and the implementation plan all in one place.
Use this tool to communicate the vision to executives and developers alike — the architectural decisions, the rationale, and the implementation plan all in one place.
Mobiles and tablets are the benchmark for on the move work. Edit, assign tasks, comment and approve from anywhere, on any device.
Mobiles and tablets are the benchmark for on the move work. Edit, assign tasks, comment and approve from anywhere, on any device.
Do your heavy lifting, thinking work, and complex decision-making in the early phases. The later phases are for polish, real-time collaboration, and accessibility improvements — not core functionality.A good balance of strategic foresight and tactical pragmatism is key to a project like this.
Do your heavy lifting, thinking work, and complex decision-making in the early phases. The later phases are for polish, real-time collaboration, and accessibility improvements — not core functionality.A good balance of strategic foresight and tactical pragmatism is key to a project like this.
Do your heavy lifting, thinking work, and complex decision-making in the early phases. The later phases are for polish, real-time collaboration, and accessibility improvements — not core functionality.A good balance of strategic foresight and tactical pragmatism is key to a project like this.
Do your heavy lifting, thinking work, and complex decision-making in the early phases. The later phases are for polish, real-time collaboration, and accessibility improvements — not core functionality.A good balance of strategic foresight and tactical pragmatism is key to a project like this.
As you work through the phases, the platform becomes more and more usable — even if you paused after Phase 2, you'd have a functional blueprint editor with export capabilities. The later phases add collaboration and polish, but the core value is there from the start.
As you work through the phases, the platform becomes more and more usable — even if you paused after Phase 2, you'd have a functional blueprint editor with export capabilities. The later phases add collaboration and polish, but the core value is there from the start.
As you work through the phases, the platform becomes more and more usable — even if you paused after Phase 2, you'd have a functional blueprint editor with export capabilities. The later phases add collaboration and polish, but the core value is there from the start.
As you work through the phases, the platform becomes more and more usable — even if you paused after Phase 2, you'd have a functional blueprint editor with export capabilities. The later phases add collaboration and polish, but the core value is there from the start.
Aitken Interactive Brand

Next Project

Aitken Interactive Brand

→