1. 从顶点计划这个名字说起设计思维到底在解决什么问题第一次看到顶点计划这四个字很多人会以为是某个技术攻关项目或者毕业设计代号。但真正参与过的人会告诉你它更像是一场针对思维方式的集中训练——用设计思维Design Thinking去拆解一个真实存在的复杂问题从零到一跑完整个流程。我前后跟过几轮类似的项目也带过不同背景的人做这种训练最大的感受是设计思维不是教你画好看的图也不是让你背一套流程模板而是逼着你在还没想清楚的状态下先动手在动手的过程中把问题想清楚。这个顶点计划的核心其实就是把设计思维从概念变成肌肉记忆。它要解决的问题很具体大多数人面对一个模糊需求时第一反应是我该怎么做而不是用户到底遇到了什么。设计思维的价值就在于把顺序倒过来——先共情、再定义、再发散、再收敛、最后验证。听起来简单但真正做起来每一步都有大量反直觉的地方。适合谁来参考这篇总结如果你正在准备一个需要从用户需求出发的创新型项目或者你带团队做产品定义、服务设计、流程优化甚至你只是想让自己在面对复杂问题时不再一团乱麻那这套东西都能直接用。它不挑行业不挑技术栈挑的是你愿不愿意放下我早就知道答案的执念。我见过太多人把设计思维当成一个创意工作坊来玩贴满一墙便利贴拍完照就结束了。但顶点计划这种级别的训练重点恰恰不在那面墙而在于墙背后那套反复迭代、不断证伪的思考习惯。下面我就按实际操作的顺序把整个流程里真正值得总结的东西拆开讲。2. 共情阶段你以为的用户需求可能全是错的2.1 为什么第一步不是调研而是放下假设设计思维的第一个动作是共情Empathize但很多人把它等同于做用户访谈。我一开始也这么理解结果第一次做的时候就翻车了。当时我们针对一个校园场景做优化团队里每个人都觉得自己是用户讨论得热火朝天直接跳过了访谈环节。等到方案做出来拿给真实用户看对方第一句话就是你们这个功能我根本用不上。问题出在哪出在我们把自己的体验当成了用户的体验。共情阶段最核心的任务不是收集信息而是清空自己已有的判断。你要像一个完全不懂这个领域的人一样去观察、去提问、去记录而不是急着验证自己的猜想。具体怎么做我总结下来有三个动作特别有效观察而不打断看用户在实际场景里怎么操作不要在他做错的时候立刻纠正记录他卡住的瞬间。追问为什么至少三层用户说我想要一个更快的按钮第一层问为什么他说因为现在太慢第二层问为什么觉得慢他说因为我要点三次第三层问为什么要点三次他说因为第一次点完不知道有没有成功。到第三层你才发现真正的问题是反馈缺失而不是按钮速度。记录情绪词而不是功能词用户说烦慌不确定怕出错这些词比我想要XX功能有价值得多。注意共情阶段最忌讳的就是带着解决方案去提问。一旦你问出如果有一个XX功能你会用吗用户大概率会礼貌地说会但这个答案没有任何参考价值。2.2 访谈记录怎么整理才不浪费做完访谈手里一堆录音和笔记很多人直接扔进文档就完事了。但顶点计划里有一个关键动作叫信息解码——把原始记录翻译成需求洞察。我自己的做法是分三步走第一步把每个受访者的话拆成事实和观点两类。事实是我每天要花20分钟找文件观点是我觉得这个系统很难用。事实可以用来定义问题观点只能用来理解情绪。第二步找矛盾点。比如三个人都说我不在意速度但实际操作时每个人都在频繁看进度条。这种言行不一致的地方往往藏着最真实的需求。第三步把高频出现的场景和情绪做成一张共情地图。横轴是用户在不同阶段的行为纵轴是他的想法和感受。这张图不用很精美但必须能让你一眼看出用户在哪个环节最焦虑在哪个环节最容易放弃。我试过用纯文字记录也试过用表格最后发现最顺手的是场景-行为-情绪-原话四列结构。原话一定要保留因为后面定义问题的时候原话是最有力的证据。2.3 一个容易被忽略的细节访谈对象的选择很多人做用户访谈习惯找典型用户。但设计思维里有一个反直觉的建议至少找两个极端用户。一个是对这个场景非常熟悉的老手一个是从未接触过的新手。老手会告诉你现有流程的潜规则新手会暴露流程里最反人性的设计。我在一次流程优化项目里就吃过亏。当时只访谈了熟练用户他们觉得一切都挺顺的结果方案上线后新手用户完全跑不通。后来补做了新手访谈才发现第一步的引导文案里有一个专业术语老手自动忽略了新手却卡在那里不知道该怎么办。所以共情阶段的人员配比我建议是熟练用户2-3人新手用户2-3人边缘用户1-2人比如偶尔使用但频率很低的人。这个组合能覆盖大部分盲区。3. 定义问题把一团乱麻变成一句可执行的话3.1 问题定义为什么比解决方案更重要设计思维里有一个经典的说法把问题定义清楚问题就解决了一半。这话听起来像鸡汤但实际操作中你会发现它是真的。因为大多数项目失败不是因为方案不够好而是因为解决了一个错误的问题。举个例子。某团队发现用户经常在填写表单时放弃第一反应是表单太长了要缩短。但重新定义问题之后他们发现真正的问题是用户不知道填完能得到什么。于是方案从缩短表单变成了在表单开头明确告知完成后的收益放弃率直接降了一半。定义问题的核心动作是收敛。共情阶段你收集了大量信息定义阶段你要从这些信息里提炼出一句用户需要什么因为什么原因。这句话的格式通常是[某类用户] 需要 [某种方式] 来实现 [某个目标]因为 [某种原因]。这句话必须满足三个条件具体、可验证、不包含解决方案。比如用户需要一个更快的按钮就不合格因为更快的按钮已经是解决方案了。合格的版本是用户在提交后需要立刻知道操作是否成功因为不确定感会让他重复操作。3.2 从洞察到问题陈述的完整推导链我自己的推导流程是这样的列出所有观察到的痛点不要筛选全部写出来。按频率和严重程度排序高频且严重的排前面。对每个痛点追问所以呢直到问出一个人的需求而不是系统的缺陷。合并同类项把本质相同的痛点合并成一个问题陈述。用我们是否在解决一个真实问题来检验如果这个问题不存在用户现在是怎么凑合过的最后一步特别关键。如果用户现在完全没有替代方案那说明这个问题可能不够痛如果用户已经在用很笨的办法解决那说明这个问题值得做。3.3 问题陈述写完之后必须做的一件事写完问题陈述不要急着进入发散阶段。先做一次反向验证把问题陈述读给一个完全没参与项目的人听问他你觉得这个问题真实吗如果对方能立刻举出一个自己遇到的类似场景说明定义得准如果对方一脸茫然说明你定义得太抽象或者太内部视角了。我在一次服务设计项目里问题陈述写的是用户需要更高效地完成跨部门协作。读给一个外部朋友听他说这不废话吗谁不想更高效。这就是典型的无效定义。后来改成用户在等待其他部门确认时不知道对方是否已经看到消息因为系统没有已读反馈这才具体到可以动手。4. 发散与收敛创意不是拍脑袋而是有节奏的放和收4.1 发散阶段数量比质量重要定义清楚问题之后进入发散阶段Ideate。这个阶段的目标是产出尽可能多的解决方案而不是找到最好的那个。很多人在这里犯的错是想到一个不错的点子就停下来开始打磨结果错过了更好的可能性。我常用的发散方法有三种头脑风暴经典但有效关键是规则要严——不批评、不打断、鼓励疯狂想法、追求数量。逆向思维假设你要让问题变得更糟你会怎么做然后把那些做法反过来。类比迁移其他行业是怎么解决类似问题的比如医院的分诊流程能不能用到客服系统里发散阶段的时间控制很重要。我一般会设一个25分钟的计时器前15分钟自由发散后10分钟做快速归类。归类不是为了筛选而是为了发现哪些方向已经被充分探索了哪些方向还是空白。4.2 收敛阶段用什么标准筛掉80%的想法发散完之后手里可能有几十个想法。收敛阶段的任务是用明确的标准筛出值得验证的几个。我常用的筛选维度是维度问题权重建议用户价值这个方案能解决定义阶段确认的核心痛点吗高可行性现有资源和技术条件下能实现吗高差异化和现有方案相比用户能感知到明显不同吗中成本实现和维护的成本是否可接受中风险如果失败后果是否可控低筛选的时候不要追求最优解而是找最值得验证的解。因为设计思维的核心是快速试错不是一次做对。提示收敛阶段最容易出现的分歧是我觉得这个好和我觉得那个好。解决办法是回到问题陈述问一句哪个方案更直接地回应了这个问题。如果还是争不出结果就两个都做原型用用户反馈来决定。4.3 发散和收敛要反复交替不是一次就完很多人以为发散和收敛各做一次就结束了。但实际操作中这两个动作要反复交替。比如你筛出三个方案做了一轮原型测试发现其中一个方向用户反馈很好但细节有问题这时候就要针对这个方向再做一次小范围发散优化细节。我在一个界面优化项目里的节奏是这样的第一轮发散出20个想法收敛到3个第二轮针对3个方向各做2-3个变体收敛到1个主方案加2个备选第三轮针对主方案的交互细节再做一次发散最后定稿。整个过程大概两周比一次性做完再改要高效得多。5. 原型与测试用最低成本换取最真实的反馈5.1 原型要低 fidelity到什么程度设计思维里强调低保真原型但很多人不理解为什么要故意做得粗糙。原因很简单高保真原型会让用户不好意思批评。你花三天画了一张精美的界面图用户看到之后第一反应是挺好的而不是这里我不太明白。低保真原型的核心是够用就好。纸面草图、白板流程、甚至用几张卡片模拟操作步骤都可以。关键是让用户能走一遍流程而不是只看静态图。我常用的低保真形式有三种纸面原型适合流程和布局验证成本极低改起来快。角色扮演适合服务设计一个人扮演用户一个人扮演系统把流程演出来。可点击的线框图适合界面交互用最简单的工具做出能点击跳转的版本但不加视觉设计。5.2 测试时最容易犯的三个错误原型测试看起来简单但实际操作中有三个坑特别常见第一个坑问用户你喜欢吗。这个问题得到的答案没有意义。应该问你刚才在找什么你为什么会点这里如果这一步失败了你会怎么办。第二个坑引导用户操作。用户卡住的时候不要告诉他你应该点这里而是记录他卡住的位置和时长。那个卡住的地方就是设计问题所在。第三个坑只测一次就下结论。一个用户的行为可能是偶然的至少测5个用户才能看出模式。如果5个人里有3个人在同一位置卡住那就是设计问题如果只有1个人卡住可能是个人习惯。5.3 从测试反馈到迭代决策的完整链路测试完拿到一堆反馈怎么决定改什么、不改什么我的做法是按频率×严重程度给每个问题打分高频且严重的问题优先改。区分理解问题和操作问题理解问题是用户不知道这是什么操作问题是用户知道但做不到。前者改文案和结构后者改交互和反馈。每次迭代只改最重要的2-3个问题改太多会导致下一轮测试无法判断是哪个改动起了作用。保留一个不改的对照组如果条件允许留一个旧版本做对比避免改了之后感觉好了但实际没有数据支撑。我在一次流程优化里第一轮测试发现用户在第3步和第5步都卡住了。按打分第3步是高频严重第5步是低频严重。于是第一轮只改第3步第二轮再改第5步。结果第一轮改完之后第5步的卡顿也减轻了——因为第3步的改动让用户对整个流程的理解更顺畅了。这种连锁反应只有一次只改一个地方才能观察到。6. 顶点计划里那些没人告诉你但很重要的经验6.1 时间分配共情和定义要占一半以上很多人做设计思维项目时间分配是共情10%、定义10%、发散30%、原型30%、测试20%。但实际跑下来最合理的分配是共情30%、定义25%、发散15%、原型15%、测试15%。前面两个阶段看起来没产出但它们决定了后面所有工作的方向。方向错了后面做得再快也是白费。我自己的习惯是在共情和定义阶段结束时各设一个检查点。如果检查点没过宁可推迟后面的进度也不要带着模糊的问题定义往下走。6.2 团队角色需要一个唱反调的人设计思维项目里团队通常有推动者、记录者、执行者。但最容易被忽略也最重要的是质疑者。这个人的任务不是否定一切而是在大家达成共识的时候问一句有没有可能我们想错了。我在一次项目里团队一致认为某个方案很好质疑者问了一句如果用户根本不想用手机操作呢。结果一查目标用户里有一半是老年人手机操作对他们来说本身就是障碍。这个问题如果没被提出来整个方案就废了。6.3 文档记录过程比结果更有价值顶点计划这种训练最后交付的不只是一个方案还有整个过程的记录。我建议从第一天就开始记决策日志今天做了什么、为什么这么做、放弃了什么、当时是怎么想的。这些记录在复盘的时候比方案本身更有价值因为方案可能只适用于这一个场景但决策逻辑可以迁移到下一个项目。6.4 什么时候该停下来设计思维强调迭代但迭代不是无限循环。什么时候该停我的判断标准是当下一轮迭代的预期收益小于投入成本时就停。具体来说如果连续两轮测试都没有发现新的严重问题或者发现的问题都是改了更好但不改也能用的级别就可以收尾了。注意停下来不等于完美了而是在当前资源和时间条件下已经达到了可交付的质量。接受不完美是设计思维的一部分。7. 把这套东西带走从顶点计划到日常工作的迁移顶点计划结束之后真正有价值的是你能不能把这套思维方式用到日常里。我自己的做法是把它拆成三个最小可执行的动作第一个动作遇到任何需求先问谁遇到了什么问题。不要一上来就想解决方案先花5分钟把问题写清楚。这个习惯能过滤掉至少一半的无效工作。第二个动作做任何方案先做一个最粗糙的版本给人看。不要等做好了再拿出去因为做好了往往意味着改不动了。粗糙版本得到的反馈比精美版本得到的赞美有价值得多。第三个动作每次做完一件事记一句当时为什么这么决定。这句话在下次遇到类似场景时能帮你省掉大量重新思考的时间。设计思维不是什么高深的理论它就是把先想清楚再动手和先动手再想清楚这两件事按正确的顺序组合起来。顶点计划给我的最大收获不是学会了某个工具或模板而是养成了一个习惯在不确定的时候用最小的成本去获取最真实的信息然后根据信息做决定而不是根据猜测做决定。这个习惯一旦养成你会发现它不只适用于做项目也适用于做选择。 
长河君 · 2026/10/15 23:42:46 · 阅读 1.2k 顶点计划：设计思维从共情到原型，解决复杂问题的实战总结
1. 从顶点计划这个名字说起设计思维到底在解决什么问题第一次看到顶点计划这四个字很多人会以为是某个技术攻关项目或者毕业设计代号。但真正参与过的人会告诉你它更像是一场针对思维方式的集中训练——用设计思维Design Thinking去拆解一个真实存在的复杂问题从零到一跑完整个流程。我前后跟过几轮类似的项目也带过不同背景的人做这种训练最大的感受是设计思维不是教你画好看的图也不是让你背一套流程模板而是逼着你在还没想清楚的状态下先动手在动手的过程中把问题想清楚。这个顶点计划的核心其实就是把设计思维从概念变成肌肉记忆。它要解决的问题很具体大多数人面对一个模糊需求时第一反应是我该怎么做而不是用户到底遇到了什么。设计思维的价值就在于把顺序倒过来——先共情、再定义、再发散、再收敛、最后验证。听起来简单但真正做起来每一步都有大量反直觉的地方。适合谁来参考这篇总结如果你正在准备一个需要从用户需求出发的创新型项目或者你带团队做产品定义、服务设计、流程优化甚至你只是想让自己在面对复杂问题时不再一团乱麻那这套东西都能直接用。它不挑行业不挑技术栈挑的是你愿不愿意放下我早就知道答案的执念。我见过太多人把设计思维当成一个创意工作坊来玩贴满一墙便利贴拍完照就结束了。但顶点计划这种级别的训练重点恰恰不在那面墙而在于墙背后那套反复迭代、不断证伪的思考习惯。下面我就按实际操作的顺序把整个流程里真正值得总结的东西拆开讲。2. 共情阶段你以为的用户需求可能全是错的2.1 为什么第一步不是调研而是放下假设设计思维的第一个动作是共情Empathize但很多人把它等同于做用户访谈。我一开始也这么理解结果第一次做的时候就翻车了。当时我们针对一个校园场景做优化团队里每个人都觉得自己是用户讨论得热火朝天直接跳过了访谈环节。等到方案做出来拿给真实用户看对方第一句话就是你们这个功能我根本用不上。问题出在哪出在我们把自己的体验当成了用户的体验。共情阶段最核心的任务不是收集信息而是清空自己已有的判断。你要像一个完全不懂这个领域的人一样去观察、去提问、去记录而不是急着验证自己的猜想。具体怎么做我总结下来有三个动作特别有效观察而不打断看用户在实际场景里怎么操作不要在他做错的时候立刻纠正记录他卡住的瞬间。追问为什么至少三层用户说我想要一个更快的按钮第一层问为什么他说因为现在太慢第二层问为什么觉得慢他说因为我要点三次第三层问为什么要点三次他说因为第一次点完不知道有没有成功。到第三层你才发现真正的问题是反馈缺失而不是按钮速度。记录情绪词而不是功能词用户说烦慌不确定怕出错这些词比我想要XX功能有价值得多。注意共情阶段最忌讳的就是带着解决方案去提问。一旦你问出如果有一个XX功能你会用吗用户大概率会礼貌地说会但这个答案没有任何参考价值。2.2 访谈记录怎么整理才不浪费做完访谈手里一堆录音和笔记很多人直接扔进文档就完事了。但顶点计划里有一个关键动作叫信息解码——把原始记录翻译成需求洞察。我自己的做法是分三步走第一步把每个受访者的话拆成事实和观点两类。事实是我每天要花20分钟找文件观点是我觉得这个系统很难用。事实可以用来定义问题观点只能用来理解情绪。第二步找矛盾点。比如三个人都说我不在意速度但实际操作时每个人都在频繁看进度条。这种言行不一致的地方往往藏着最真实的需求。第三步把高频出现的场景和情绪做成一张共情地图。横轴是用户在不同阶段的行为纵轴是他的想法和感受。这张图不用很精美但必须能让你一眼看出用户在哪个环节最焦虑在哪个环节最容易放弃。我试过用纯文字记录也试过用表格最后发现最顺手的是场景-行为-情绪-原话四列结构。原话一定要保留因为后面定义问题的时候原话是最有力的证据。2.3 一个容易被忽略的细节访谈对象的选择很多人做用户访谈习惯找典型用户。但设计思维里有一个反直觉的建议至少找两个极端用户。一个是对这个场景非常熟悉的老手一个是从未接触过的新手。老手会告诉你现有流程的潜规则新手会暴露流程里最反人性的设计。我在一次流程优化项目里就吃过亏。当时只访谈了熟练用户他们觉得一切都挺顺的结果方案上线后新手用户完全跑不通。后来补做了新手访谈才发现第一步的引导文案里有一个专业术语老手自动忽略了新手却卡在那里不知道该怎么办。所以共情阶段的人员配比我建议是熟练用户2-3人新手用户2-3人边缘用户1-2人比如偶尔使用但频率很低的人。这个组合能覆盖大部分盲区。3. 定义问题把一团乱麻变成一句可执行的话3.1 问题定义为什么比解决方案更重要设计思维里有一个经典的说法把问题定义清楚问题就解决了一半。这话听起来像鸡汤但实际操作中你会发现它是真的。因为大多数项目失败不是因为方案不够好而是因为解决了一个错误的问题。举个例子。某团队发现用户经常在填写表单时放弃第一反应是表单太长了要缩短。但重新定义问题之后他们发现真正的问题是用户不知道填完能得到什么。于是方案从缩短表单变成了在表单开头明确告知完成后的收益放弃率直接降了一半。定义问题的核心动作是收敛。共情阶段你收集了大量信息定义阶段你要从这些信息里提炼出一句用户需要什么因为什么原因。这句话的格式通常是[某类用户] 需要 [某种方式] 来实现 [某个目标]因为 [某种原因]。这句话必须满足三个条件具体、可验证、不包含解决方案。比如用户需要一个更快的按钮就不合格因为更快的按钮已经是解决方案了。合格的版本是用户在提交后需要立刻知道操作是否成功因为不确定感会让他重复操作。3.2 从洞察到问题陈述的完整推导链我自己的推导流程是这样的列出所有观察到的痛点不要筛选全部写出来。按频率和严重程度排序高频且严重的排前面。对每个痛点追问所以呢直到问出一个人的需求而不是系统的缺陷。合并同类项把本质相同的痛点合并成一个问题陈述。用我们是否在解决一个真实问题来检验如果这个问题不存在用户现在是怎么凑合过的最后一步特别关键。如果用户现在完全没有替代方案那说明这个问题可能不够痛如果用户已经在用很笨的办法解决那说明这个问题值得做。3.3 问题陈述写完之后必须做的一件事写完问题陈述不要急着进入发散阶段。先做一次反向验证把问题陈述读给一个完全没参与项目的人听问他你觉得这个问题真实吗如果对方能立刻举出一个自己遇到的类似场景说明定义得准如果对方一脸茫然说明你定义得太抽象或者太内部视角了。我在一次服务设计项目里问题陈述写的是用户需要更高效地完成跨部门协作。读给一个外部朋友听他说这不废话吗谁不想更高效。这就是典型的无效定义。后来改成用户在等待其他部门确认时不知道对方是否已经看到消息因为系统没有已读反馈这才具体到可以动手。4. 发散与收敛创意不是拍脑袋而是有节奏的放和收4.1 发散阶段数量比质量重要定义清楚问题之后进入发散阶段Ideate。这个阶段的目标是产出尽可能多的解决方案而不是找到最好的那个。很多人在这里犯的错是想到一个不错的点子就停下来开始打磨结果错过了更好的可能性。我常用的发散方法有三种头脑风暴经典但有效关键是规则要严——不批评、不打断、鼓励疯狂想法、追求数量。逆向思维假设你要让问题变得更糟你会怎么做然后把那些做法反过来。类比迁移其他行业是怎么解决类似问题的比如医院的分诊流程能不能用到客服系统里发散阶段的时间控制很重要。我一般会设一个25分钟的计时器前15分钟自由发散后10分钟做快速归类。归类不是为了筛选而是为了发现哪些方向已经被充分探索了哪些方向还是空白。4.2 收敛阶段用什么标准筛掉80%的想法发散完之后手里可能有几十个想法。收敛阶段的任务是用明确的标准筛出值得验证的几个。我常用的筛选维度是维度问题权重建议用户价值这个方案能解决定义阶段确认的核心痛点吗高可行性现有资源和技术条件下能实现吗高差异化和现有方案相比用户能感知到明显不同吗中成本实现和维护的成本是否可接受中风险如果失败后果是否可控低筛选的时候不要追求最优解而是找最值得验证的解。因为设计思维的核心是快速试错不是一次做对。提示收敛阶段最容易出现的分歧是我觉得这个好和我觉得那个好。解决办法是回到问题陈述问一句哪个方案更直接地回应了这个问题。如果还是争不出结果就两个都做原型用用户反馈来决定。4.3 发散和收敛要反复交替不是一次就完很多人以为发散和收敛各做一次就结束了。但实际操作中这两个动作要反复交替。比如你筛出三个方案做了一轮原型测试发现其中一个方向用户反馈很好但细节有问题这时候就要针对这个方向再做一次小范围发散优化细节。我在一个界面优化项目里的节奏是这样的第一轮发散出20个想法收敛到3个第二轮针对3个方向各做2-3个变体收敛到1个主方案加2个备选第三轮针对主方案的交互细节再做一次发散最后定稿。整个过程大概两周比一次性做完再改要高效得多。5. 原型与测试用最低成本换取最真实的反馈5.1 原型要低 fidelity到什么程度设计思维里强调低保真原型但很多人不理解为什么要故意做得粗糙。原因很简单高保真原型会让用户不好意思批评。你花三天画了一张精美的界面图用户看到之后第一反应是挺好的而不是这里我不太明白。低保真原型的核心是够用就好。纸面草图、白板流程、甚至用几张卡片模拟操作步骤都可以。关键是让用户能走一遍流程而不是只看静态图。我常用的低保真形式有三种纸面原型适合流程和布局验证成本极低改起来快。角色扮演适合服务设计一个人扮演用户一个人扮演系统把流程演出来。可点击的线框图适合界面交互用最简单的工具做出能点击跳转的版本但不加视觉设计。5.2 测试时最容易犯的三个错误原型测试看起来简单但实际操作中有三个坑特别常见第一个坑问用户你喜欢吗。这个问题得到的答案没有意义。应该问你刚才在找什么你为什么会点这里如果这一步失败了你会怎么办。第二个坑引导用户操作。用户卡住的时候不要告诉他你应该点这里而是记录他卡住的位置和时长。那个卡住的地方就是设计问题所在。第三个坑只测一次就下结论。一个用户的行为可能是偶然的至少测5个用户才能看出模式。如果5个人里有3个人在同一位置卡住那就是设计问题如果只有1个人卡住可能是个人习惯。5.3 从测试反馈到迭代决策的完整链路测试完拿到一堆反馈怎么决定改什么、不改什么我的做法是按频率×严重程度给每个问题打分高频且严重的问题优先改。区分理解问题和操作问题理解问题是用户不知道这是什么操作问题是用户知道但做不到。前者改文案和结构后者改交互和反馈。每次迭代只改最重要的2-3个问题改太多会导致下一轮测试无法判断是哪个改动起了作用。保留一个不改的对照组如果条件允许留一个旧版本做对比避免改了之后感觉好了但实际没有数据支撑。我在一次流程优化里第一轮测试发现用户在第3步和第5步都卡住了。按打分第3步是高频严重第5步是低频严重。于是第一轮只改第3步第二轮再改第5步。结果第一轮改完之后第5步的卡顿也减轻了——因为第3步的改动让用户对整个流程的理解更顺畅了。这种连锁反应只有一次只改一个地方才能观察到。6. 顶点计划里那些没人告诉你但很重要的经验6.1 时间分配共情和定义要占一半以上很多人做设计思维项目时间分配是共情10%、定义10%、发散30%、原型30%、测试20%。但实际跑下来最合理的分配是共情30%、定义25%、发散15%、原型15%、测试15%。前面两个阶段看起来没产出但它们决定了后面所有工作的方向。方向错了后面做得再快也是白费。我自己的习惯是在共情和定义阶段结束时各设一个检查点。如果检查点没过宁可推迟后面的进度也不要带着模糊的问题定义往下走。6.2 团队角色需要一个唱反调的人设计思维项目里团队通常有推动者、记录者、执行者。但最容易被忽略也最重要的是质疑者。这个人的任务不是否定一切而是在大家达成共识的时候问一句有没有可能我们想错了。我在一次项目里团队一致认为某个方案很好质疑者问了一句如果用户根本不想用手机操作呢。结果一查目标用户里有一半是老年人手机操作对他们来说本身就是障碍。这个问题如果没被提出来整个方案就废了。6.3 文档记录过程比结果更有价值顶点计划这种训练最后交付的不只是一个方案还有整个过程的记录。我建议从第一天就开始记决策日志今天做了什么、为什么这么做、放弃了什么、当时是怎么想的。这些记录在复盘的时候比方案本身更有价值因为方案可能只适用于这一个场景但决策逻辑可以迁移到下一个项目。6.4 什么时候该停下来设计思维强调迭代但迭代不是无限循环。什么时候该停我的判断标准是当下一轮迭代的预期收益小于投入成本时就停。具体来说如果连续两轮测试都没有发现新的严重问题或者发现的问题都是改了更好但不改也能用的级别就可以收尾了。注意停下来不等于完美了而是在当前资源和时间条件下已经达到了可交付的质量。接受不完美是设计思维的一部分。7. 把这套东西带走从顶点计划到日常工作的迁移顶点计划结束之后真正有价值的是你能不能把这套思维方式用到日常里。我自己的做法是把它拆成三个最小可执行的动作第一个动作遇到任何需求先问谁遇到了什么问题。不要一上来就想解决方案先花5分钟把问题写清楚。这个习惯能过滤掉至少一半的无效工作。第二个动作做任何方案先做一个最粗糙的版本给人看。不要等做好了再拿出去因为做好了往往意味着改不动了。粗糙版本得到的反馈比精美版本得到的赞美有价值得多。第三个动作每次做完一件事记一句当时为什么这么决定。这句话在下次遇到类似场景时能帮你省掉大量重新思考的时间。设计思维不是什么高深的理论它就是把先想清楚再动手和先动手再想清楚这两件事按正确的顺序组合起来。顶点计划给我的最大收获不是学会了某个工具或模板而是养成了一个习惯在不确定的时候用最小的成本去获取最真实的信息然后根据信息做决定而不是根据猜测做决定。这个习惯一旦养成你会发现它不只适用于做项目也适用于做选择。