回收或回用的路径要在设计时写上
产品定义里，如果回用路径仍是等产品结束使用再想去向，结果往往是去向没有被设计，最后只能被当作废弃。
文章 · 工业设计 · 消费与零售
能否维修和拆解，是设计问题
产品定义里，如果维修仍是把维修留到上市之后，结果往往是不能拆的产品把使用后的问题全部交给别人。更稳妥的做法是在定义阶段就写明如何维修或拆解，并用维修路径把这个选择固定下来。
核心要点
- 在产品定义里，维修不该继续停留为把维修留到上市之后。
- 放着不管，就会反复出现同一件事：不能拆的产品把使用后的问题全部交给别人。
- 起点换成：在定义阶段就写明如何维修或拆解。
- 把选择写进维修路径，由设计与工程一起。
- 以后只按一个问题验收：一件损坏时，是否有被设计过的路径。
01关于维修，先决定什么
处理维修时，第一件不该做的事是修饰把维修留到上市之后。在产品定义里，顺序比措辞更决定会不会出现：不能拆的产品把使用后的问题全部交给别人。
如果一上来就改句子，团队会以为维修已经更新，不能拆的产品把使用后的问题全部交给别人却还在原处。
在定义阶段就写明如何维修或拆解。做不到这一点，维修就还停在把维修留到上市之后。
02维修里哪些决定必须靠后
有些决定必须靠后。在在定义阶段就写明如何维修或拆解之前，就去讨论渠道、画面或话术，只会把把维修留到上市之后换一种说法保留下来。
靠后的决定不是不重要，而是它们要服从前面的选择，否则团队只会反复处理表象：不能拆的产品把使用后的问题全部交给别人。
03维修的顺序本身就是设计
顺序可以写成三步：先在定义阶段就写明如何维修或拆解，再形成维修路径，最后才允许对外说法变化。
颠倒这个顺序时，维修看起来很忙，实际上仍被把维修留到上市之后牵着走。
04用工具固定维修的顺序
维修路径要能看出先后。读它的人应知道什么已经定了，什么还不能动。
定义评审，用维修路径核对顺序有没有被战役打乱。
05在什么场合复核维修
设计与工程一起。顺序一旦被例外打穿，就要回到维修路径上改规则，而不是在群里临时改一句维修。
复核只问：一件损坏时，是否有被设计过的路径。这个问题能答，顺序才算被使用了。
框架图
维修的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把维修重新写成把维修留到上市之后。
L1路径
这一层写明维修里什么不能让渡。
L2谁来做
这一层把维修收成可检查的条件。
L3不能拆时要承认的代价
这一层规定维修在不同场合可以变什么。
L4验证
这一层把维修交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在产品定义里标出维修真正被调用的时刻，不要从改写把维修留到上市之后开始。
行动 02
收成一页
用维修路径代替更长的说明，只保留能支持「在定义阶段就写明如何维修或拆解」的内容。
行动 03
按一个问题验收
定义评审，只问：一件损坏时，是否有被设计过的路径。答不上来，就还不是决策。
行动 04
写明维护人
设计与工程一起。没有维护人的维修，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
耐用本身就是品牌价值
产品价值讨论里，如果耐用仍是把价值写成新功能和外观，结果往往是用不久的产品让前面的承诺一起失效。
包装结构要为使用后的去向负责
包装结构里，如果包装去向仍是结构只为运输和开箱，结果往往是开完之后没有人知道它该去哪里。