Good Services Service Design

This skill helps you design, diagnose, and improve services end-to-end using the Good Services model: define the service from the user's perspective, map the steps/tasks across channels and operations, and then assess and improve using the 15 principles of good service design.

A service here means: something that helps someone to do something — defined by the user's goal, not your org chart.

When to use

Use this skill when the user asks for any of the following:

• “Design a service” / “redesign a service” / “fix our service”

• “Service audit” / “service review” / “why is our service failing?”

• “Service blueprint” / “journey map” / “service map”

• “How do we make this service easier to find / understand / use?”

• “Apply the Good Services principles” / “the 15 principles”

When NOT to use

• Pure UI styling/visual design requests (unless tied to a service journey or ops)

• Marketing/copywriting that isn't part of explaining the service purpose/expectations

• Narrow technical debugging with no service context (use engineering/debug skills instead)

Operating modes

Choose the lightest mode that fits the user's need.

• Quick audit (30–60 min)

• Output: principles scorecard + top issues + recommended fixes/backlog

• Best when: user wants fast prioritisation or a “why is this broken?” diagnosis

• Full design / improvement plan

• Output: service definition + journey map + service blueprint + scorecard + prioritised backlog + service standard

• Best when: user is (re)designing a service or needs cross-team alignment

• Workshop facilitation

• Output: agenda + exercises + artefacts to fill live (templates)

• Best when: multiple stakeholders need to align on scope, ownership, and priorities

Inputs to collect (progressive)

Start with the minimum and expand only as needed.

Minimum (always ask):

• What is the service (in one sentence) and what outcome does the user want?

• Who are the primary users? (2–3 groups is enough)

• What channels exist today? (web/app/phone/post/in-person/physical)

• What is the main problem you're trying to solve? (symptoms + suspected causes)

Helpful (ask if doing more than a quick audit):

• Known constraints (policy/legal/technical/budget/SLAs)

• Current volume + failure points (drop-offs, call deflection, complaint themes)

• Any research, analytics, or frontline insights you already have

• Where support happens today (humans, scripts, escalation routes)

If information is missing, make assumptions explicit and provide a “data needed next” list.

Core workflow

Step 1 — Define the service (user-first)

Goal: anchor on what the user is trying to achieve, and where the service starts/ends.

Use: references/templates/service-definition-canvas.md

Do:

• Rewrite the service name as a verb phrase users would search for.

• Define start trigger and done condition (what does “complete” mean?).

• Identify user groups + accessibility needs.

• List channels and key touchpoints.

• Capture success measures (user + organisation + societal).

Output: a filled Service Definition Canvas.

Step 2 — Map the journey (steps and tasks)

Goal: describe the service as one continuous set of actions towards the user's goal — across org boundaries and channels.

Use:

• references/templates/service-map.md (journey map)

• references/templates/service-blueprint.md (frontstage/backstage/support)

Do:

• Break the service into steps (major decision points / moments needing visibility).

• Break steps into tasks (individual actions).

• Note channel(s) per step/task and any handoffs between teams/orgs.

• Capture pain points, drop-offs, and where users seek help.

Output: a journey map (minimum) and blueprint (if ops matter, which they usually do).

Step 3 — Assess against the 15 principles

Goal: identify where the service violates universal good-service needs.

Use:

• references/templates/principles-scorecard.md

• references/15-principles.md (detailed guidance + checks)

Do:

• Score each principle (0–2) and record evidence.

• List the top failure modes and where they appear in the journey.

• Highlight cross-cutting root causes (language, data silos, incentives, policy).

Output: completed principles scorecard + summary of top 5 issues.

Step 4 — Design improvements and prioritise

Goal: turn findings into a realistic plan.

Use: references/templates/improvement-backlog.md

Do:

• Propose fixes that directly address failures (avoid “nice-to-haves”).

• Prefer changes that reduce user effort, clarify purpose/expectations, and remove dead ends.

• Prioritise by user impact, risk, frequency, and implementation effort.

• Write acceptance criteria in user-outcome language.

Output: prioritised backlog (Now / Next / Later).

Step 5 — Define the service standard and measurement

Goal: make the service operable and improvable over time.

Use: references/templates/service-standard.md

Do:

• Define what “good” looks like: promises, service levels, accessibility bar, support model.

• Define key measures (not just what’s easy to count).

• Make incentives explicit: what behaviours are you encouraging in users and staff?

Output: service standard + measurement plan.

Step 6 — Validate and iterate

Goal: ensure improvements work for real users and real staff.

Do:

• List the riskiest assumptions (who/what/when/why/how).

• Propose a lightweight validation plan (research, prototype, pilot, operational test).

• Plan for change: what user circumstances can change, and how will the service respond?

Output: validation plan + “unknowns / next evidence to collect”.

The 15 principles (as checks)

• A good service is easy to find

• A good service clearly explains its purpose

• A good service sets the expectations a user has of it

• A good service enables a user to complete the outcome they set out to do

• A good service works in a way that’s familiar

• A good service requires no prior knowledge to use

• A good service is agnostic to organisational structures

• A good service requires as few steps as possible to complete

• A good service is consistent throughout

• A good service should have no dead ends

• A good service is usable by everyone, equally

• A good service encourages the right behaviours from users and staff

• A good service should respond to change quickly

• A good service clearly explains why a decision has been made

• A good service makes it easy to get human assistance

(Use references/15-principles.md for practical tests and improvement moves.)

Output format (recommended)

When delivering results, structure the response like this:

• Service definition (1–2 paragraphs + canvas)

• Journey map (table)

• Service blueprint (if relevant)

• Principles scorecard (table + top issues)

• Prioritised backlog (Now/Next/Later)

• Service standard + measures

• Validation plan (what to test next)

Keep everything in plain language, using the user's terms (verbs), not internal acronyms.

Quality checklist (before finalising)

• The service name is a verb users would search for (not an internal noun/acronym).

• Purpose is clear in the first 10 seconds of the journey.

• Time/cost/eligibility expectations are set at the right moments.

• The journey supports the full user outcome (including aftercare and exceptions).

• Patterns and language are familiar and consistent across channels.

• No step assumes prior knowledge of your organisation or process.

• No user is stranded: every “no” has a next step (alternative, referral, appeal, human help).

• Accessibility is treated as a baseline, not a bolt-on.

• Metrics and incentives encourage the right behaviours (users + staff + organisation + society).

• The service can handle change (user details, circumstances, policy, operational variance).

Examples

Example 1 — Quick audit

User: “Can you audit our online appointment booking service? Drop-off is high.” Actions:

• Collect minimal context (users, outcome, channels, evidence).

• Produce journey map + scorecard (0–2 per principle).

• Identify top 5 root causes and propose a Now/Next/Later backlog.

Example 2 — Blueprint + improvement plan

User: “Design an end-to-end ‘cancel my subscription’ service across web + phone.” Actions:

• Define service boundaries (start, done, aftercare).

• Map journey and blueprint (frontstage/backstage/support).

• Check dead ends, expectations, and human assistance.

• Produce a service standard (what “good” means) + measures.

Example 3 — Workshop

User: “We need a workshop agenda to align teams around our service redesign.” Actions:

• Use references/workshop-agenda.md .

• Provide templates to fill and facilitation notes.

• End with an agreed backlog and ownership map.

Troubleshooting

The request is too broad (“fix our whole customer experience”)

• Narrow to one user outcome and define service boundaries.

• If needed, split into multiple services (each with its own “done”).

The org is siloed / no single owner

• Run Step 2 (map) explicitly across handoffs.

• Use Principle 7 guidance to propose shared standards/goals/incentives.

Users keep calling / staff are overwhelmed

• Check Principle 3 (expectations), 10 (dead ends), and 15 (human help model).

• Look for incentive problems (Principle 12).

Not enough data

• Make assumptions explicit.

• Provide a “minimum evidence to collect next” list: top drop-off steps, complaint themes, frontline pain points, accessibility issues.