从单一触点到完整服务生态

【背景】触点问题往往只是冰山一角：优化触点前，先定义清楚'问题到底是什么'。 【步骤】1. 想一个最近遇到的服务问题（App 登录失败/客服无效/挂号出错）；2. 把它定义为一个具体触点问题（谁、在哪、何时、发生什么）；3. 记录它对用户的实际影响。 【输出】触点问题定义（含影响）。

【背景】五问法（5 Whys）从触点现象追到系统根因，避免'修了表面漏了根'。 【步骤】1. 用 5 Whys 追踪触点问题根因（登录失败→超时→系统→...）；2. 每问一步记录证据（日志/规则/组织）；3. 指出根因属于技术、流程还是组织。 【输出】5 Whys 链条 + 根因归类。

【背景】'我可以优化这个触点'有时是傲慢：不经系统理解的优化可能把问题推向别处。 【步骤】1. 判断何时优化触点正确（问题确实局部）、何时傲慢（问题在系统）；2. 举一个'局部优化导致系统恶化'的例子；3. 给出你的判断原则。 【输出】'何时该优化触点'的判断原则。

【背景】服务生态地图把人物、组织、系统画进同一张网，让你看到触点之外的连接。 【步骤】1. 浏览'服务生态地图'（/relations/service-ecosystem）；2. 注意人物-组织-系统三类节点及其关系；3. 找出 1-2 条'看似无关却互相影响'的路径。 【输出】生态地图阅读笔记。

【背景】Helsinki Design Lab 的定位是'在复杂系统中找杠杆点'，而非'设计漂亮解决方案'。 【步骤】1. 阅读 Helsinki Design Lab 案例；2. 理解它为何拒绝'单点解决方案'；3. 记录'杠杆点思维'与'方案思维'的区别。 【输出】杠杆点 vs 方案的辨析。

【背景】利益相关方地图让'服务涉及谁'显形：每个利益相关方都有需求与约束。 【步骤】1. 选一项熟悉的公共服务；2. 绘制利益相关方地图（直接用户/间接用户/提供方/监管方/合作方/技术供应方）；3. 标注各方的核心利益与相互依赖。 【输出】利益相关方地图。

【背景】曼奇尼的'赋能而非替代'与系统思维的杠杆点相通：干预应增强系统能力而非替换部件。 【步骤】1. 阅读曼奇尼设计师页，理解'赋能'；2. 把它与'杠杆点'（改变系统结构的小支点）对照；3. 举一个'赋能式干预'的例子。 【输出】赋能与杠杆点的关系笔记。

【背景】杠杆点是'改变最少、影响最大'的干预点：回到触点问题，但不再只修触点。 【步骤】1. 回到你的触点问题；2. 回答：什么干预改变最少但影响最大（改规则/改流程/改数据/改责任）；3. 评估其可行性与副作用。 【输出】杠杆点方案 + 副作用评估。

【背景】杠杆有伦理风险：改变一个规则可能让一部分人获益、另一部分受损。 【步骤】1. 思考你的杠杆点会让谁获益、谁受损；2. 判断这种再分配是否可辩护（公平/必要/可补偿）；3. 提出缓解受损群体的设计。 【输出】杠杆伦理评估（获益/受损/缓解）。

【背景】政策约束不是设计的障碍，而是设计的参数：理解约束才能在其内创新。 【步骤】1. 浏览'服务版本'页中的政策约束标注；2. 区分'硬约束'（法律/安全）与'软约束'（惯例/流程）；3. 记录一个'约束反而激发好设计'的例子。 【输出】政策约束类型笔记 + 案例。

【背景】当用户需求与政策冲突，服务设计师要在合规与关怀之间做艰难判断。 【步骤】1. 面对冲突，评估四个选项：①政策内优化 ②提请政策修改 ③设计规避 ④拒绝服务；2. 判断每个选项的伦理与可行；3. 给出你的选择与理由。 【输出】冲突处理决策记录。

【背景】终局任务：把利益相关方地图、杠杆点、政策约束整合为一个生态级改进方案。 【步骤】1. 综合所学，为最初触点问题写生态系统改进方案（问题重定义→利益相关方→杠杆点→政策约束→实施方案）；2. 标注预期影响与风险。 【输出】生态系统改进方案文档。