Inspect before downloading
See what is inside
These previews come from the published bundle files, so you can judge the method and writing before using it.
Role guide
Service Designer Role Guide
Record the user's goal, policy or organizational intent, start and end, included and excluded journeys, jurisdictions, channels, products, content, actors, organizations, and lifecycle stage.
Read the fileOverview
Overview
Service design examines how an end-to-end service helps a person complete a goal and how the participating organization or organizations deliver it.
Read the fileQuality rubric
Service Designer Quality Check
- Role grounding: Distinguishes service design from interaction design, user research, product management, service ownership, and live operations while preserving collaboration.
Read the fileBundle file
Service Design Review Workflow
1. Record the request, intended audience, decision, user goal, policy or organizational intent, jurisdiction, service context, evidence supplied, and evidence date. 2.
Read the fileIs this bundle right for your task?
Who it is for
- People performing or supporting Service Designer work, plus teams reviewing its decisions and outputs
- Teams working in government services, public services, financial services
When to use it
- A Service Designer task needs a structured plan, evidence checklist, or review-ready output.
- A recommendation needs its assumptions, owners, risks, dependencies, and success measures made explicit.
What you need to provide
- The task objective, intended audience, working context, constraints, source material, and decision owner.
- Relevant reports, exports, examples, policies, prior decisions, and success measures available for the task.
Tasks and expected outputs
Questions it helps answer
- define a whole-service boundary
- map current and proposed service delivery
- review cross-channel handoffs and improvements without inventing ownership
What it helps produce
- service scope and ecosystem map
- current and proposed service blueprint
- cross-channel journey and handoff review
- service evidence and decision brief
Practical example
Use it with an agent
Load the bundle as context, provide the evidence named above, then adapt this example to your situation.
Provide the task objective, intended audience, working context, constraints, source material, and decision owner. Ask the agent to approach Service Designer work by producing service scope and ecosystem map with a prioritized plan, evidence checks, owners, risks, and unresolved questions. Begin with UK Government service designer, then confirm that the reference is current and applicable. Inspect Service Designer Role Guide before drafting.
Context path: bundles/roles/service-designer
What the bundle includes
Frameworks
- whole-service boundary map
- actor-touchpoint-backstage-support blueprint
- evidence-decision-ownership ledger
Evaluations
- Service Designer quality check
Sources used to build this bundle
These are the public references behind the role definition and operating guidance. The bundle does not replace current documentation or evidence from your site.
Limitations and safe use
Do not use this for
- Treating the bundle as a substitute for organization-specific authority, firsthand evidence, or accountable review.
Known limitations
- Role-support bundle only; not authority to conduct research, set product priorities, own service outcomes, change policy or operations, direct staff or suppliers, commit funding, access systems or data, publish artifacts, or certify a service.
- Service Designer scope varies by organization, role level, service model, jurisdiction, team composition, and local charter; service design is not synonymous with service ownership.
- O*NET 15-1255.00 and SOC 15-1255 are broad interface-design proxies; no distinct ESCO or ISCO mapping was verified for this bundle.
Safety notes
- Protect participant, customer, employee, case, eligibility, health, accessibility, complaint, operational, security, policy, commercial, supplier, and unreleased-service information.
- Verify policy intent, user evidence, service boundaries, actors, processes, systems, controls, access, metrics, owners, and approval paths before relying on a deliverable.
- Require explicit confirmation before participant contact, policy or operational change, staffing or budget commitment, procurement, system or data access, publication, or external communication.