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.

1. 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

1. 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

1. 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:

1. Rewrite the service name as a verb phrase users would search for.
2. Define start trigger and done condition (what does “complete” mean?).
3. Identify user groups + accessibility needs.
4. List channels and key touchpoints.
5. 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:

1. Break the service into steps (major decision points / moments needing visibility).
2. Break steps into tasks (individual actions).
3. Note channel(s) per step/task and any handoffs between teams/orgs.
4. 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:

1. Score each principle (0–2) and record evidence.
2. List the top failure modes and where they appear in the journey.
3. 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:

1. Propose fixes that directly address failures (avoid “nice-to-haves”).
2. Prefer changes that reduce user effort, clarify purpose/expectations, and remove dead ends.
3. Prioritise by user impact, risk, frequency, and implementation effort.
4. 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:

1. Define what “good” looks like: promises, service levels, accessibility bar, support model.
2. Define key measures (not just what’s easy to count).
3. 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:

1. List the riskiest assumptions (who/what/when/why/how).
2. Propose a lightweight validation plan (research, prototype, pilot, operational test).
3. 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)

1. A good service is easy to find
2. A good service clearly explains its purpose
3. A good service sets the expectations a user has of it
4. A good service enables a user to complete the outcome they set out to do
5. A good service works in a way that’s familiar
6. A good service requires no prior knowledge to use
7. A good service is agnostic to organisational structures
8. A good service requires as few steps as possible to complete
9. A good service is consistent throughout
10. A good service should have no dead ends
11. A good service is usable by everyone, equally
12. A good service encourages the right behaviours from users and staff
13. A good service should respond to change quickly
14. A good service clearly explains why a decision has been made
15. 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:

1. Service definition (1–2 paragraphs + canvas)
2. Journey map (table)
3. Service blueprint (if relevant)
4. Principles scorecard (table + top issues)
5. Prioritised backlog (Now/Next/Later)
6. Service standard + measures
7. 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:

1. Collect minimal context (users, outcome, channels, evidence).
2. Produce journey map + scorecard (0–2 per principle).
3. 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:

1. Define service boundaries (start, done, aftercare).
2. Map journey and blueprint (frontstage/backstage/support).
3. Check dead ends, expectations, and human assistance.
4. 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:

1. Use references/workshop-agenda.md.
2. Provide templates to fill and facilitation notes.
3. 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.