good-services-service-design

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Good Services Service Design

Good Services服务设计

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.

本技能可借助《Good Services》模型帮助你端到端地设计、诊断和改进服务：从用户视角定义服务，梳理跨渠道和跨运营的步骤/任务，随后依托优质服务设计15条原则进行评估和优化。

此处所指的服务是：帮助用户完成某件事的载体——由用户目标而非你的组织架构定义。

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”

当用户提出以下任意需求时可使用本技能：

“设计一个服务”/“重新设计一个服务”/“修复我们的服务”
“服务审计”/“服务复盘”/“我们的服务为什么运行不畅？”
“服务蓝图”/“旅程地图”/“服务地图”
“我们怎么让这个服务更容易被找到/理解/使用？”
“应用Good Services原则”/“应用那15条原则”

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)

纯UI样式/视觉设计需求（除非和服务旅程或运营相关）
不属于服务用途/预期说明范畴的营销/文案写作需求
无服务上下文的狭义技术调试（请改用工程/调试相关技能）

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

选择最匹配用户需求的轻量化模式即可。

快速审计（30-60分钟）

输出：原则评分卡+核心问题+推荐修复方案/待办事项
适用场景：用户需要快速确定优先级，或是诊断“服务运行不畅的原因”

完整设计/改进方案

输出：服务定义+旅程地图+服务蓝图+评分卡+优先级排序待办事项+服务标准
适用场景：用户需要（重新）设计服务，或是需要跨团队对齐目标

工作坊引导

输出：议程+练习+可实时填写的产出物（模板）
适用场景：需要让多名利益相关方对齐范围、权责和优先级

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.

从最少必要信息开始收集，仅在需要时扩展。

最少必要信息（每次都要询问）：

用一句话描述服务是什么，以及用户想要达成什么结果？
核心用户是谁？（2-3个群体即可）
当前有哪些可用渠道？（网页/应用/电话/邮件/线下/实体载体）
你想要解决的核心问题是什么？（现象+疑似原因）

补充信息（如果做的不只是快速审计可以询问）：

已知约束（政策/法律/技术/预算/服务水平协议）
当前服务量+故障点（用户流失、呼叫转移、投诉集中点）
你已有的任何用户研究、数据分析或一线洞察
当前的支持渠道（人工、话术、升级路径）

如果信息缺失，明确说明假设内容，并提供“后续需要收集的数据”列表。

Core workflow

核心工作流

Step 1 — Define the service (user-first)

步骤1——定义服务（用户优先）

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.

目标：锚定用户想要达成的目标，以及服务的起止边界。

使用模板：

references/templates/service-definition-canvas.md

执行动作：

将服务名称重写为用户会搜索的动词短语。
定义启动触发条件和完成条件（“服务完成”的标准是什么？）。
识别用户群体+可访问性需求。
列出渠道和核心触点。
明确成功衡量指标（用户侧+组织侧+社会侧）。

输出：填写完成的服务定义画布。

Step 2 — Map the journey (steps and tasks)

步骤2——梳理旅程（步骤和任务）

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

目标：将服务描述为用户朝着目标行动的一系列连续动作——跨组织边界和渠道。

使用模板：

```
references/templates/service-map.md
```
（旅程地图）

references/templates/service-blueprint.md

（前台/后台/支持侧）

执行动作：

将服务拆分为多个步骤（主要决策点/需要感知的关键节点）。
将步骤拆分为多个任务（单个动作）。
标注每个步骤/任务对应的渠道，以及团队/组织之间的交接节点。
记录痛点、用户流失点、用户寻求帮助的节点。

输出：旅程地图（最低要求）和服务蓝图（如果运营相关，通常都需要）。

Step 3 — Assess against the 15 principles

步骤3——对照15条原则评估

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.

目标：识别服务违反通用优质服务要求的点。

使用模板：

references/templates/principles-scorecard.md

```
references/15-principles.md
```
（详细指南+检查项）

执行动作：

为每条原则打分（0-2）并记录佐证。
列出 top 故障模式以及它们在旅程中出现的位置。
梳理跨环节的根本原因（语言、数据孤岛、激励机制、政策）。

输出：填写完成的原则评分卡+top5问题总结。

Step 4 — Design improvements and prioritise

步骤4——设计优化方案并排序

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

目标：将发现的问题转化为可落地的方案。

使用模板：

references/templates/improvement-backlog.md

执行动作：

提出直接对应故障点的修复方案（避免“锦上添花”的需求）。
优先选择可降低用户成本、明确用途/预期、消除死胡同的改动。
按照用户影响、风险、发生频率、实施成本排序优先级。
用用户侧结果的语言编写验收标准。

输出：按优先级排序的待办事项（现在/下一步/未来）。

Step 5 — Define the service standard and measurement

步骤5——定义服务标准和衡量方式

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.

目标：让服务可运营，且可长期迭代优化。

使用模板：

references/templates/service-standard.md

执行动作：

定义“优质”的标准：服务承诺、服务等级、可访问性门槛、支持模式。
定义核心衡量指标（不只是容易统计的指标）。
明确激励机制：你想要引导用户和工作人员产生什么行为？

输出：服务标准+衡量方案。

Step 6 — Validate and iterate

步骤6——验证和迭代

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)

15条原则（作为检查项）

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

好的服务易于查找
好的服务清晰说明自身用途
好的服务会明确用户对它的预期
好的服务能帮助用户完成他们想要达成的目标
好的服务的运作方式符合用户的熟悉认知
好的服务无需用户具备前置知识即可使用
好的服务不受组织架构的限制
好的服务完成所需步骤尽可能少
好的服务全程体验一致
好的服务不会出现死胡同
好的服务对所有人都同等可用
好的服务会引导用户和工作人员做出正确行为
好的服务能够快速响应变化
好的服务会清晰解释决策的原因
好的服务让获取人工协助变得简单

（可参考

references/15-principles.md

获取实操测试方法和优化动作。）

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.

交付结果时，请按照以下结构组织回复：

服务定义（1-2段文字+画布）
旅程地图（表格）
服务蓝图（如果相关）
原则评分卡（表格+核心问题）
优先级排序待办事项（现在/下一步/未来）
服务标准+衡量指标
验证方案（后续要测试的内容）

所有内容请使用平实语言，采用用户的术语（动词），不要使用内部缩写。

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

服务名称是用户会搜索的动词短语（不是内部名词/缩写）。
用户在旅程开始的10秒内就能明确服务用途。
时间/成本/准入资格的预期会在合适的节点告知用户。
旅程支持用户完整达成目标（包括售后和异常场景）。
不同渠道的设计模式和语言风格熟悉且一致。
没有步骤假设用户了解你的组织或流程的前置知识。
不会让用户陷入困境：每个“不通过”的结果都有下一步动作（替代方案、转介、申诉、人工帮助）。
可访问性是基础要求，不是附加功能。
指标和激励机制引导正确的行为（用户+工作人员+组织+社会）。
服务可以应对变化（用户信息、情况、政策、运营差异）。

Examples

示例

Example 1 — Quick audit

示例1——快速审计

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.

用户：“你能审计我们的在线预约服务吗？用户流失率很高。” 执行动作：

收集最少必要上下文（用户、目标、渠道、证据）。
产出旅程地图+评分卡（每条原则0-2分）。
识别top5根本原因，提出现在/下一步/未来的待办事项。

Example 2 — Blueprint + improvement plan

示例2——蓝图+优化方案

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

示例3——工作坊

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.

用户：“我们需要一个工作坊议程，帮助团队对齐服务重设计的目标。” 执行动作：

使用
```
references/workshop-agenda.md
```
模板。
提供可填写的模板和引导说明。
输出达成共识的待办事项和权责地图。

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.

明确执行步骤2（旅程梳理）时要覆盖所有交接节点。
参考第7条原则的指导，提出共享的标准/目标/激励机制。

Users keep calling / staff are overwhelmed

用户不断来电/工作人员负担过重

Check Principle 3 (expectations), 10 (dead ends), and 15 (human help model).
Look for incentive problems (Principle 12).

检查第3条原则（预期设置）、第10条原则（死胡同）、第15条原则（人工帮助模式）。
排查激励机制问题（第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.

明确说明假设内容。
提供“后续需要收集的最少证据”列表：top流失步骤、投诉集中点、一线痛点、可访问性问题。