good-services-service-design

端到端服务设计

根据人们需要达成的结果定义服务，而不是根据提供方的组织架构或某个页面。将《Good Services》作为从业者框架，用于发现问题和改进机会，而非法律标准、自动认证，或证明未经测试的设计有效的衡量依据。

选择恰当的范围

阅读提供的简报、研究、分析数据、一线反馈、政策和运营约束。确定用户结果、启动触发条件、完成条件、用户群体、渠道和痛点。优先使用已有答案，而非总是重复进行需求收集问卷。说明缺失的假设，并根据现有证据能够支持的部分继续；只有在未解决的事实会阻碍合理建议时才提问。

快速评审需要最重要的发现和下一步所需证据，而非每一份材料。跨团队重新设计可能需要定义、旅程、蓝图、待办事项清单、服务标准和验证计划。工作坊请求需要引导计划和待填写的模板，而不是虚构工作坊共识。根据请求调整产出；不要将完整的七部分材料包视为必需。

跟进用户的完整旅程

在有助于厘清任务时，使用服务定义、服务地图和蓝图。在适用情况下，梳理发现、资格判定、准备、决策、交易、等待、支持、完成、变更、取消和后续服务。纳入失败和替代路径，而不只是顺利路径。

将用户可见的操作和信息与员工、系统、政策及交接分开呈现。记录每个步骤的证据、这些证据代表谁的体验，以及尚未覆盖的部分。不要臆造用户情绪、数量、放弃原因、员工产能或跨团队归属。利益相关方的假设不等于观察到的用户研究；流失指标本身并不能证明人们为何离开，或是否通过其他途径达成了目标。

根据证据评审原则

将原则作为评估易发现性、目标、预期、完成、熟悉度、先验知识、组织交接、付出、连贯性、死胡同、包容性、激励、变化、决策和人工协助的提示。明确呈现预期用户结果和实际受影响群体，不要通过取平均值掩盖排斥问题。

仅在评分有助于决策时使用本地评分表。它将有证据支持的失败、部分达标和良好表现，与未经验证和不在范围内区分开来。不要仅仅因为模板中有空白单元格就给出分数。范围狭窄的 2 分并不能证明整个服务对所有人都有效，分数也不是可相加并得出通用质量百分比的区间尺度。

本套件的 0–2 评分标准是内部简写。Lou Downe 发布的《Good Services》量表使用 0–4；不要将本地工作表说成官方量表，也不要在没有实际定义的情况下进行换算。若要正式使用已发布的量表，请查阅作者的最新资料。

改进服务，而不是分数

优先处理已证实的用户伤害、结果未达成、发生频率、排斥问题、运营风险和所需投入。区分已确认的原因与假设。根据证据评估每项拟议修复方案；在已知时注明负责人、依赖项、验收标准，以及用于确认改进的观察结果。必要时使用待办清单和服务标准。

减少不必要的负担，而不是不计代价地减少点击次数。暂停、确认、申诉或与人工沟通，都可能有助于保障理解和自主权。不要隐藏取消选项、迫使人们使用自助服务，也不要一边让支持更难获得，一边优化电话转接率。说明拒绝申请或发生错误后会怎样，包括可行的替代方案和升级处理方式；不要捏造资格条件或申诉权利。

无障碍和包容性需要根据相关需求和渠道进行实际测试。视觉审查无法证明人人都能平等访问。检查当前适用的要求、隐私和保障措施；不要把从业者原则说成法律建议。评估转移给工作人员、照护者、合作机构，以及缺少文件、网络连接、语言能力、时间或信心的用户的负担。

验证并报告

针对风险最高的假设，制定小规模测试或试点，并明确可观察的用户结果、运营指标和防护措施。区分原型的预期与实际观察到的结果。说明抽样方式、渠道覆盖范围、时间窗口和尚未解决的局限。如果研讨会、调查、可用性测试或生产试点只是拟议方案，就不要声称已经开展。

交付有助于决策的地图、发现、补丁或计划，并提供证据和具体的后续验证步骤。举办研讨会时，使用现有议程，并根据实际请求调整角色、时长和参与需求。在达成一致或明确分配职责之前，不要暗示利益相关方已达成共识或已有负责人。

审阅来源，日期为 2026-09-13：作者的原则和作者对规模的说明。详细的本地模板是本软件包的改编内容，并非新的官方标准。元数据遵循Agent Skills 规范。