企业官网建设流程全解析

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 从洞察到问题陈述的完整推导链

我自己的推导流程是这样的：

1. 列出所有观察到的痛点：不要筛选，全部写出来。
2. 按频率和严重程度排序：高频且严重的排前面。
3. 对每个痛点追问"所以呢"：直到问出一个"人的需求"而不是"系统的缺陷"。
4. 合并同类项：把本质相同的痛点合并成一个问题陈述。
5. 用"我们是否在解决一个真实问题"来检验：如果这个问题不存在，用户现在是怎么凑合过的？

最后一步特别关键。如果用户现在完全没有替代方案，那说明这个问题可能不够痛；如果用户已经在用很笨的办法解决，那说明这个问题值得做。

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 从测试反馈到迭代决策的完整链路

测试完拿到一堆反馈，怎么决定改什么、不改什么？我的做法是：

1. 按"频率×严重程度"给每个问题打分：高频且严重的问题优先改。
2. 区分"理解问题"和"操作问题"：理解问题是用户不知道这是什么，操作问题是用户知道但做不到。前者改文案和结构，后者改交互和反馈。
3. 每次迭代只改最重要的2-3个问题：改太多会导致下一轮测试无法判断是哪个改动起了作用。
4. 保留一个"不改"的对照组：如果条件允许，留一个旧版本做对比，避免"改了之后感觉好了"但实际没有数据支撑。

我在一次流程优化里，第一轮测试发现用户在第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分钟把问题写清楚。这个习惯能过滤掉至少一半的无效工作。

第二个动作：做任何方案，先做一个最粗糙的版本给人看。不要等"做好了"再拿出去，因为"做好了"往往意味着"改不动了"。粗糙版本得到的反馈，比精美版本得到的赞美有价值得多。

第三个动作：每次做完一件事，记一句"当时为什么这么决定"。这句话在下次遇到类似场景时，能帮你省掉大量重新思考的时间。

设计思维不是什么高深的理论，它就是把"先想清楚再动手"和"先动手再想清楚"这两件事，按正确的顺序组合起来。顶点计划给我的最大收获，不是学会了某个工具或模板，而是养成了一个习惯：在不确定的时候，用最小的成本去获取最真实的信息，然后根据信息做决定，而不是根据猜测做决定。

这个习惯一旦养成，你会发现它不只适用于做项目，也适用于做选择。