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 位参与者不让他们进入实验室只是在自己手机里记录“一整天中被手机打扰的次数、场景和当时的情绪”。回收日志后高频场景和我们最初预想的完全不同。我们原以为最需要的是“开车时快速回复消息”“办公时快捷切换应用”但日志显示这些场景发生频率并不高而且用户更倾向于直接用手机解决。真正的痛点是三个看起来很小的事情场景发生频率用户痛点缪斯设计回应被闹钟吵醒时摸索手机每天 1-2 次半睡半醒找不到手机抬腕单击静音触觉反馈确认做饭或走路时切歌每天多次手湿、手脏、不方便碰手机双指轻点切换不需要看设备会议或图书馆中来消息每天数次低头看手机不礼貌且打断思路盲操作确认或忽略呼吸灯轻提示办公室 AR 展示演示时看起来很酷日常想不到使用场景直接砍掉不进入排期这个排序后来直接决定了手势原型的优先级。真正的价值不是“让你更高效地操作手机”而是“让你在不离开当前活动的情况下处理打扰”。那些看起来很宏大但其实低频的“办公室 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 用价值成本评估表给功能排优先级而不是靠嗓门为了在评审会上有据可依我们建立了一张“价值-成本”评估表所有候选功能都用四个维度打分维度说明评分范围用户价值是否解决真实且重要的痛点1-5 分使用频率典型用户每周可能使用几次1-5 分技术成本算法、硬件、功耗的综合难度1-5 分越低越好维护成本上线后持续优化和故障处理成本1-5 分越低越好最后计算“用户价值 × 使用频率 − 技术成本 − 维护成本”按得分排序决定保留、观望、砍掉。空中画布的用户价值很高有 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%”。没有这条记录这个决定可能会在某个会议上被重新翻出来反复讨论因为有了它我们只需要五分钟就能结束话题。这种积累也是“做对了什么”里最容易被忽略的部分项目会结束但决策方法和记录会沉淀为个人能力。最让我欣慰的不是某个手势被认可而是我离开项目时带走的这本决策日志。后来在完全不同的产品里我依然会问团队三个问题我们的用户在哪一个具体场景里非用不可没有这个功能用户会损失什么如果只剩一半资源我们还会保留它吗这三个问题是从缪斯项目里长出来的比任何项目本身都值钱。
