企业官网建设流程全解析

1. 方向上做对的第一件事：用“不做什么”给项目划定边界

我是产品设计师，在缪斯项目里跟着团队从概念走到工程样机交付，前后一共 14 个月。项目代号“缪斯”，最初目标很模糊，只说要做一款“下一代自然交互设备”，没有定义用户、没有定义场景、也没有定义成功标准。今天复盘回头看，这个项目最后能活下来，甚至在公司内部沉淀出一套交互规范，最关键的不是用了什么先进算法，而是我们在第一轮就学会了划边界。

1.1 项目一开始的混乱：所有人都在做功能，但没人说得清目标

立项后的前五周，团队只有十几个人的规模，但产品方案里已经塞进了五条线：语音助手、手势隔空操作、健康监测、AR 投影、脑电波情绪识别。每周评审都是一场功能展示秀，大家把 demo 跑得飞起，却没人能回答最基础的两个问题：用户为什么要用这个设备？这个设备在做哪个场景时比手机强？

我当时在评审表上写了一句“像是给一个没有形状的物体不断加装饰”，惹得项目负责人笑了，但也正因为这句话，团队决定停下所有开发，先做一轮“反向脑暴”。这件事给我的第一课是：探索型项目最怕的不是没有想法，而是想法太多却没有一个共享的坐标系。每个角色都在用自己的专业背景理解项目，设计师觉得应该做体验，算法觉得应该做识别，硬件觉得应该做结构，最后产品方案就变成了一锅粥。

1.2 反向脑暴：把“绝不做的五件事”贴在墙上

反向脑暴的规则很简单，每人必须在 20 分钟内写出至少 5 件“这个项目绝不做的事”，不能写功能名，要写行为描述。比如不允许写“不做脑电波”，要写“不能让用户为了控制设备而学习集中注意力，因为这种学习成本会把普通用户挡在门外”。

最后一共收到 40 多条，我们归纳成五条：

• 不做手机替代品；
• 不做专业健康设备；
• 不做需要凝视屏幕的交互；
• 不做强调“技术表演”的功能；
• 不做需要训练手势的复杂指令。

这五条直接成为后续所有方案评审的筛子。任何新功能如果不能通过这五条，就算再性感也进不了下一轮。这里需要解释一下为什么“不做”比“要做”更有用：立项初期团队对成功标准没有共识，如果只讨论“要做”，大家会越聊越扩大选项，最后无法收敛；改成“不做”之后，每一次否定都是在共同确认边界，这也是减少内耗最有效的方法。

1.3 硬件约束反而让交互思路清晰了

划定产品边界之后，硬件约束就变成了设计的重要输入。缪斯项目的工程样机只有一枚拇指大的模块，没有屏幕，没有扬声器，电池只能支持典型用户一天一充，算力只够跑小规模的端侧识别模型。最初好多同事觉得这是劣势，但后来我们意识到：硬件“笨”一点，反而逼出了更干净的设计。

既然屏幕不存在，就不能指望用户看提示；既然算力不够做语义理解，就不做开放式对话，只做离散指令；既然电池有限，就不让任何功能处于高频扫描状态。整个场景收敛为“用户在视觉和注意力都放在别处时，用单手手指的微动作完成高频小任务”。这让我想到一个类比：画布太小的时候，你没办法堆砌内容，必须把每一笔都放在真正重要的地方。产品设计也是一样，约束不是敌人，它是告诉资源应该往哪集中的信号。

1.4 一页纸问题定义带来的一连串连锁反应

第五周结束时，我们把项目定义收敛成了一页纸，现在还留在我的工作笔记里：目标用户是“经常在走路、做饭、开会时被手机打扰的人”；核心场景是“不拿出手机、不移动视线的前提下，完成静音、切歌、关闭闹钟、确认或取消提醒”；物理约束是“设备重量小于 45 克，单次充电支持 24 小时使用”；成功标准是“盲操作任务完成率达到 90%，误触率低于 5%，用户学习时间少于 10 分钟”。

这个定义写完之后，团队内部突然安静了，因为每个角色都拿到了自己可以死磕的指标。设计师知道了要设计什么交互，工程师知道了要优化什么识别，测试人员也知道了怎样才算通过。很多探索型项目死在“什么都想做”上，缪斯项目能走完研发周期，第一功臣就是这页纸。它可能不是最性感的文档，却是最值钱的那个。

2. 用户研究里做对的第二件事：让真实场景倒逼设计决策

2.1 低成本研究工具先行：纸模型和彩泥比样机更早介入

项目立项早期，硬件团队还没有可用的样机，如果我们等样机出来再做用户测试，至少浪费两个半月。我们当时做了一件事：用纸板和彩泥捏了一个非常粗糙的“手腕模块”，它没有传感器，但重量和厚度按预估尺寸做了 1:1 复刻。然后找了 12 位从来没有接触过可穿戴设备的人，让他们把这个模型戴在手腕上，完成几个模拟任务。

比如，我们在纸上画了一个正在响的手机界面，请用户用最简单的动作表达“想把闹钟关掉”。很多人会下意识地抬起手腕，用另一只手的大拇指轻轻按两下，这个动作被我们完整记录下来，成为后来“双指轻点”手势的起点。

这里有一个容易被忽略的点：研究工具的价值不是逼真，而是能激发真实行为。彩泥模型虽然粗糙，但它占用了真实的手腕位置，用户会自然地做出动作，我们看到的不是“用户想象中的未来设备”，而是“用户基于身体本能的第一反应”。

2.2 用户真正焦虑的不是手势不够酷，而是“到底有没有被识别”

第一轮 12 人测试结束后，我们得出一个反直觉的结论：用户最担心的不是识别不准，也不是隐私，而是“我操作完之后，设备到底听没听到”。在模拟任务里，很多人做了手势之后会立刻抬起手腕看模型是否有反应，这与我们“不看屏幕”的目标完全矛盾。

我们注意到，当设备能给出一个明确、及时、不打断当前注意力的反馈时，用户的焦虑会迅速下降。这直接催生了设计原则的第一条：反馈必须在 100 毫秒内出现，且优先用触觉而不是视觉。我们后来把震动反馈做成三种强度：确认成功、识别中、失败需要重来。

这个过程让我领悟到，用户研究不是给设计方案找证据，而是要跳出设计师的自嗨。比如当时团队内部最喜欢讨论“手势库设计”，以为问题在于动作本身的逻辑，但真实需求是“安全感和可控感”。没有这轮研究，我们大概率会把精力花在丰富手势库上，而不是打磨反馈机制。

2.3 高频场景排序：为什么最后留下的是“静音、切歌、关闭闹钟”

在确定核心场景时，我们用了一周时间做了一个轻量级日志研究：招募了 30 位参与者，不让他们进入实验室，只是在自己手机里记录“一整天中被手机打扰的次数、场景和当时的情绪”。回收日志后，高频场景和我们最初预想的完全不同。

我们原以为最需要的是“开车时快速回复消息”“办公时快捷切换应用”，但日志显示这些场景发生频率并不高，而且用户更倾向于直接用手机解决。真正的痛点是三个看起来很小的事情：

这个排序后来直接决定了手势原型的优先级。真正的价值不是“让你更高效地操作手机”，而是“让你在不离开当前活动的情况下处理打扰”。那些看起来很宏大但其实低频的“办公室 AR 控制中心”，从此彻底出了局。

2.4 落地成可执行的设计原则：盲操作、两秒反馈、可撤销

有了场景排序，我们把设计原则落成三条可测试的规则：

• 核心操作必须支持盲操作，用户不需要看手腕也知道在哪里点击；
• 从用户产生意图到完成操作并收到反馈，总时长不超过两秒；
• 每个可能造成后果的手势，都要有一个“撤销”动作，比如翻掌取消。

这三条原则不是拍脑袋，而是从用户研究里长出来的：盲操作来自“注意力不在这里”的现场观察，两秒来自我们对“被打扰容忍度”的测试，可撤销来自用户对误操作的恐惧。测试时我们做的是“蒙眼任务”：让用户戴上眼罩，只靠触觉和震动完成“关闭正在响铃的闹钟”任务。

最初成功率只有 61%，拿回数据后我们把点击区域从 9 格减少到 3 格，又把震动反馈从 200ms 延长到 350ms，成功率才慢慢爬到了 94%。这个数字最终写进了我们的定义文档。这里我想提醒所有做产品的人：设计原则如果只挂在墙上，那只是一句标语；只有当它变成了一个可以被测试的通过/失败条件时，它才真正开始保护用户体验。

3. 协作机制上做对的第三件事：双轨原型让设计、硬件、算法同步进化

3.1 什么是双轨原型，为什么它不是简单的“先做设计后接硬件”

双轨原型是我们项目里最实用的协作机制。简单说，一条轨道是“交互设计原型”，运行在一台开发板上，用按钮和屏幕模拟未来的手势反馈；另一条轨道是“硬件算法原型”，使用真实的传感器和端侧模型识别手势。两条轨道在每周固定时间“合轨”一次，把交互轨道接到真实硬件轨道上做完整任务测试。

为什么不能等到硬件成熟再接入设计？因为硬件和算法的不确定性太高，你永远不可能等到它们稳定；为什么不能只做设计原型而不碰硬件？因为那样最后合轨时一定会出现“地震”。双轨原型相当于给双方各买了一份并行保险，设计团队不用等硬件，硬件团队也不用等设计。

这个机制的关键在于“每周合轨”而不是“最后合轨”，即使第一次合轨时两个模块都不完美，但问题暴露得越早，修复成本越低。后来我参与其他项目时，见过太多团队把“集成”放在最后一两个月，结果一切都在赶工中崩塌。双轨原型不是多此一举，而是把集成风险均匀分摊到整个研发周期里。

3.2 每一张设计图都带着“系统假设”的三行注释

在双轨原型里，设计师很容易把交互画得过于理想，比如一个手势必须 100% 准确、反馈必须 0 延迟。为了不让工程师拿到设计稿后内心翻白眼，我们强行规定：每张交互稿右下角必须写三段注释——算法置信度假设、系统延迟预算、失败兜底方案。

举个例子，单指轻点的手势注释是：

系统触发：食指轴向加速度超过阈值 A 算法置信度：>= 0.75 端侧推理延迟：<= 50ms 失败兜底：1 秒内无二次确认，则触发一次震动“未识别”

这段注释让工程师一看到就知道设计有没有挑战硬件，也让设计师提前思考“如果算法不完美怎么办”。它最直接的好处是消灭了会议里的夺命三连问：这样做算法能不能支持？延迟会不会爆？没识别到时怎么办？这些问题在设计阶段就已经被自己回答了一部分。

3.3 每周一次的场景脚本联调代替了PPT汇报

那个阶段最痛苦的会议是每周三下午的“场景脚本联调”。我们准备了一批卡片，每张卡片是一个完整用户任务，比如“手机在裤兜震动，用户抬起手腕，用无名指轻点一下，确认是一条低优先级通知，然后继续手里的咖啡”。会议开始时不允许讲 PPT，只能直接从卡片里抽一张，现场执行整个链路。

执行失败后，设计师和工程师必须当场判断：是手势设计不合理，还是算法没有收敛，还是反馈时序不对。这个流程非常折磨人，但正是它让原型从“每个模块单独看都还行”变成了“整体链路可用”。

有一段时间我们连续三周都卡在“识别到手势之后，动画播放完成前，用户已经把手放下”这个时序问题上，原因是界面反馈太快而硬件识别太慢。最后是设计师主动把反馈动画拆成了两步：先给 50ms 的触觉脉冲表示“收到了”，再在 300ms 内补完视觉动效。这个决定如果没有联调会，根本不可能发现。

3.4 双轨原型实际救了我们一次：反馈时序的发现

现在展开讲那次救命的经历。当时我们原本的设计是：用户点击后，系统先给一个圆形的视觉涟漪，然后手腕震动确认。但联调时我们发现，从算法识别到界面反馈渲染完成需要 180ms，用户在这个时间里已经经历了一段“空白期”，开始不安地再次点击，造成重复触发。

问题出在“视觉反馈和触觉反馈是串行的”，我们把它改成并行：触觉反馈直接挂在算法识别回调上，视觉反馈则异步补上第二层。这个改动让任务完成率提高了近 20 个百分点。

如果双轨原型没有把两边提前接在一起，这个问题大概率会拖到正式整机验证时才发现，届时成本和压力都会大得多。这件事在我看来是“做对了什么”里最值得复制的部分：项目管理层面不追求每个阶段的完美，而是追求让不可控因素尽早暴露。原型糙一点没关系，错误发现得越早，越有机会把它变成设计优化点，而不是项目危机。

4. 产品决策中做对的第四件事：果断砍掉“很酷但没人用”的功能

4.1 “空中画布”：一个让所有人兴奋却让用户无感的功能

项目进行到第四个月时，算法团队展示了“空中画布”功能：用户可以在空中滑动手指，通过设备的加速度计和摄像头，把任何平面变成一块虚拟绘图板。这个功能在内部演示时全场欢呼，管理层甚至当场发邮件希望把它放进量产路线图。

但我们随后做了 10 人可用性测试和 3 天日记研究，结果是让人尴尬的：只有 6% 的参与者表示愿意每天使用超过一次，绝大多数人反馈“很惊艳，但想不到什么时候用”。更致命的是，这个功能需要设备保持高功耗的视觉追踪状态，样机表面温度在两分钟内上升了 4 度，电池续航直接少了 6 个小时。

这个例子几乎是探索型项目的典型陷阱：技术能力强，演示效果好，但没有任何真实场景能够支撑它每天被需要。作为产品设计师，我当时顶住了内部极大的压力，坚持先做场景再确认技术，这也是项目能保持克制的原因之一。

4.2 用价值成本评估表给功能排优先级，而不是靠嗓门

为了在评审会上有据可依，我们建立了一张“价值-成本”评估表，所有候选功能都用四个维度打分：

最后计算“用户价值 × 使用频率 − 技术成本 − 维护成本”，按得分排序决定保留、观望、砍掉。空中画布的用户价值很高有 5 分，但使用频率只有 1 分，技术成本是 5 分，维护成本是 4 分，算完只有负分，只能进“待重审”。

真正留下来的“手指双击静音”“翻掌撤销”“双指滚轮计”等，都是高频、低成本、低学习门槛的功能。这张表也帮助团队统一了语言：大家不再为一个功能吵得脸红脖子粗，而是对照评分和理由逐项讨论。产品设计里很多撕扯，其实是因为缺少一个共同认可的度量标准，这张表就是那个标准。

4.3 帮我们成功“自宫”的谈话方式：两分钟任务Demo

砍功能最难的关卡不是团队内部，而是决策层。决策层喜欢看到刺激的功能，因为他们不负责日常体验。我们的办法是准备“两分钟任务 Demo”：不介绍概念，一进会议室就让决策层亲自佩戴原型，重复执行“手机来电→盲操作静音→继续聊天”和“切歌→确认播放→收回手”这两个闭环任务。

他们实际体验之后发现，连续三次盲操作成功率都不稳定，而空中画布根本没办法在真实工作状态下使用。于是“是不是应该砍掉空中画布”这个质疑，由决策层自己提了出来。

这件事让我深刻体会到，跟决策层沟通不需要形容词，也不需要战略愿景，而是把用户任务放到决策者自己手上，让系统暴露真实表现。数据会孤立起来说，但亲身体验不会骗人。

4.4 砍掉之后的设计反而更完整：少就是多的一种正确解释

最终保留并打磨的手势只有六个：单击、双击、长按、双指轻点、翻掌撤销、滑动确认。这个结果在项目早期看会觉得太简陋，但实际测试下来，六个手势在 14 个场景任务中都达到了 94% 的成功率和低于 5% 的误触率。

因为每个手势都经过反复微调，团队有余力去优化触觉反馈的力度曲线、学习引导的第一印象、以及失败时的恢复流程。换句话说，“少”并不是功能数量上的少，而是在一个已明确的高价值路径上，把资源集中到极致。

从我的角度看，这个过程比多做一个功能更能提升产品设计质量。如果你也在做一个探索型产品，请认真考虑从功能清单里删掉那些只有演示价值的东西，你的用户不会因为它酷而留下，却会因为它顺手而留下。

5. 容易被低估的过程管理：指标、汇报和跨职能沟通的实战技巧

5.1 没有北极星指标时，设计师如何自己建立衡量体系

探索型项目往往没有“日活”或“转化率”这样的北极星指标，但设计师不能因此就只说“我觉得好用”。在缪斯项目里，我强行给体验建立了四个指标：任务完成率、每任务平均纠错次数、负荷评分、第二天愿意继续使用的主观意愿。

其中“第二天愿意继续使用”是一个很关键的问题，我们每周都会在测试后问用户，虽然它不是一个严格意义上的定量指标，但能提供非常重要的信号。如果连续两周这个意愿都在低位，即使硬指标再好，我们也会重新审视方向。

建立这些指标的意义在于，它们能把体验问题翻译成管理层能看懂的“报表语言”。一家公司也许不理解“交互隐喻混乱”，但绝对能理解“用户的平均纠错次数从 2.8 降到了 0.9”。设计师不能只守护体验，还要学会给体验建立可被追踪的刻度。

5.2 应对决策层“灵感突发”的Backlog暂存区

每隔几周，决策层总会带着新灵感来开会，比如“能不能加个语音助手”“能不能在设备上显示眼神”“能不能做成宠物互动”。如果每次都正面硬顶，合作会崩掉；如果每次都接，项目会废。

我们的处理方式是在项目管理工具里设了一个“暂存区 Backlog”，所有临时灵感先记录，不上版本计划。每季度重审一次，重审要过三关：是否符合最初定义的高频场景？是否依赖一年内不可用的新技术？是否有用户研究或真实日志支持？三关全过才回到排期。

这个方法看起来很温和，但它保护了团队节奏。很多临时灵感自己会在下一季度冷却，而真正值得做的需求，会在三个月后再次被用户提及，那时候它自然就有了优先级。用流程去接住灵感，比用个人判断去拒绝灵感要稳妥得多。

5.3 我做的“用户体验—系统需求”翻译对照表

跨职能会议里最容易吵起来的是“同一个概念，各自定义不同”。设计师说“反馈要清晰”，工程师问“清晰是指多少毫秒还是多少尼特”；设计师说“操作要自然”，算法问“自然是指哪种加速度分布”。

我后来做了一张翻译对照表，把设计语言转换成系统语言：

• 用户目标：把手机静音；
• 交互动作：双击侧面传感器；
• 系统触发条件：单次双击窗口 500ms，间隔小于 200ms；
• 算法置信度：> 0.7；
• 业务反馈形式：350ms 连续两段震动；
• 错误兜底：0.5s 后无响应自动回退。

每个需要跨团队确认的设计决策都按这套格式写，渐渐地，会议效率变得非常高。这张对照表的核心作用，是让争论从“形容词”变成“填空题”，大家不再争好不好，而是填数字、跑测试、看结果。

5.4 最值得养成的习惯：设计决策日志

我最后想分享一个特别小但长期收益极高的习惯：从缪斯项目开始，我坚持给每个重要设计决策写日志。日志不用很长，但要包含五个要素：决策日期、参与角色、讨论过的至少两个备选方案、最终选择、当时被否决的理由。

三个月后，当你被质疑“为什么当初这样设计”的时候，翻出日志比靠记忆靠谱得多。比如“为什么采用三档震动而不是五档”，我当时记录的原因是“五档虽然表达更丰富，但在盲操作中用户无法分辨相邻档位，测试准确率只有 70%”。

没有这条记录，这个决定可能会在某个会议上被重新翻出来反复讨论；因为有了它，我们只需要五分钟就能结束话题。这种积累也是“做对了什么”里最容易被忽略的部分：项目会结束，但决策方法和记录会沉淀为个人能力。

最让我欣慰的不是某个手势被认可，而是我离开项目时带走的这本决策日志。后来在完全不同的产品里，我依然会问团队三个问题：我们的用户在哪一个具体场景里非用不可？没有这个功能用户会损失什么？如果只剩一半资源，我们还会保留它吗？这三个问题是从缪斯项目里长出来的，比任何项目本身都值钱。