从 2KB 到 20KB：一个 Unicode 小游戏让我重新想起目标

前几天翻 Unicode 字符表，发现里面居然有整套麻将、扑克牌，还有各种奇奇怪怪的符号。

于是有了个想法：能不能只靠这些字符，做一个体积只有 2KB 的网页小游戏？不用准备图片素材，光是想想就觉得挺有意思。

最初得到的东西看起来像游戏，但根本不能交互。

这就有点尴尬了。明明画面已经有了，却不能算真正做出了游戏。字符摆在页面上，离让人玩起来，还隔着规则和操作。

后来我把限制放宽到了 20KB。

但仔细想想，问题其实不在于多出来的 18KB，而在于我们到底想做什么。

一个游戏至少得能操作、有规则、有反馈。否则即使压缩到了几百字节，又有什么意义呢？体积当然有价值，限制也能逼着我们取舍。但如果为了守住数字，连最基本的交互都舍掉了，就已经偏离了最初的想法。

Unicode 确实可以省掉不少图片素材，但也不是没有代价。不同设备上的字符可能长得不一样，还要考虑字体是否支持这些字符。省下素材的体积，并不意味着这些体验问题也一起消失了。

这件小事让我重新想到一个挺常见的问题：我们总是很容易把某个可量化的指标当成目标。

比如更小的体积、更少的代码、更快的开发速度。数字很好比较，也很容易让人觉得自己在进步。但这些指标只是约束或者手段，不能替我们回答：这个东西到底做成了什么？

对这个小游戏来说，体积应该服务于可玩。先确认它能让人玩起来，再讨论还能压缩多少，才有意义。

真正重要的，还是那个东西到底有没有解决最初的问题。

服务设计是什么意思：体验不是一个界面，而是一整段旅程

摘要

服务设计关注的不是单个页面、按钮或流程，而是用户从产生需求到完成任务的整段体验。一次服务可能包含线上界面、线下接触、客服沟通、等待、通知、付款、售后和失败处理。理解服务设计，能帮助我们从“把功能做出来”转向“让人在真实情境中顺利完成事情”。

为什么体验不只是界面

很多人谈体验，首先想到界面是否好看、按钮是否清楚、动效是否顺滑。这些当然重要，但它们只是体验的一部分。

如果用户在下单后不知道什么时候送达，遇到问题找不到客服，退款规则不清楚，再漂亮的界面也很难弥补整体体验。

服务设计提醒我们：用户经历的是一整段旅程，不是某个截图。

从用户旅程看问题

用户旅程，是把用户完成一件事的过程按时间展开。

比如办理一个业务，用户可能先搜索信息，再比较方案，再提交材料，再等待审核，再接收结果，再处理异常。每一步都有问题、情绪和接触点。

如果只优化其中一个页面，就可能错过真正的痛点。服务设计要看完整路径。

接触点之间要一致

服务体验常常坏在接触点断裂。

网页上承诺一种规则，客服说法又不一样；短信通知写得含糊，应用里也找不到状态；线下人员不知道线上发生过什么，用户只能反复解释。

接触点之间不一致，会让用户觉得系统不可信。

好的服务设计，不是每个点各自漂亮，而是让它们共同说同一种话。

等待也是体验

很多服务都需要等待。等待不可怕，可怕的是不知道为什么等、还要等多久、是否出了问题。

一个清楚的进度提示、一条及时通知、一个可查询状态，都会显著改善等待体验。

服务设计关注这些“中间时刻”。因为用户的不安，往往发生在服务没有回应的时候。

失败路径同样重要

很多设计只认真处理成功路径。用户顺利下单、成功支付、按时完成，一切都很好。

但真实服务一定会失败：材料不合格、支付失败、物流延迟、系统异常、需求变更。失败路径设计得不好，用户会感到被抛弃。

好的服务设计，要让失败也有清楚说明、可恢复路径和责任归属。

后台流程影响前台体验

服务体验不是前台团队单独决定的。后台流程、权限、工具、培训、数据同步，都会影响用户感受。

如果客服没有权限处理问题，前台话术再温柔也没用。如果系统之间数据不同步，用户就会反复提交材料。

服务设计必须看见后台，因为用户体验常常是组织能力的外显。

服务设计也适用于内容和产品

一个内容站也有服务设计：新读者如何进入，如何理解栏目，如何找到相关文章，如何从一篇文章走向下一篇。

一个工具产品更是如此：用户不是来欣赏功能，而是来完成任务。任务之前、任务之中、任务之后，都需要被照顾。

服务设计的思维，是把体验放回时间里。

结论

服务设计的核心，是把体验看成一段连续旅程。界面只是接触点之一，真正决定体验的，是信息、流程、等待、异常处理和后台协作如何共同工作。一个好的服务，不只是看起来顺，而是用户在真实情境中走得通。

延伸阅读

• 用户研究怎么入门：不是问用户想要什么
• 好工具为什么让人省心：从功能清单到使用场景
• 产品思维为什么重要：不是转产品，而是理解用户价值

产品指标怎么设计：不是数字越多越好，而是回答关键问题

摘要

产品指标不是报表装饰，也不是越多越专业。好的指标应该回答关键问题：用户是否真正完成任务，产品是否创造价值，系统是否健康，增长是否可持续。指标设计的难点，不在于找一个好看的数字，而在于明确目标、定义口径、避免被单一数字误导，并让指标能指导行动。

为什么指标会变成噪声

很多产品都有大量指标：访问量、点击率、停留时长、转化率、留存、活跃、分享、收入。问题是，指标多不代表理解深。

如果每个数字都被放到同等位置，团队反而不知道该看什么。更糟的是，某个数字上涨可能被误读成产品变好，而背后只是渠道变化、活动刺激或异常数据。

指标的价值不在数量，而在问题意识。

先问产品目标

设计指标前，要先问产品目标是什么。

一个学习产品，核心可能是用户持续完成学习任务；一个工具产品，核心可能是降低完成任务的时间；一个社区产品，核心可能是高质量互动。

目标不同，指标不同。不能因为某个指标流行，就把它当成所有产品的核心指标。

指标应该服务目标，而不是替代目标。

区分结果指标和过程指标

结果指标告诉我们最终结果，比如收入、留存、转化。过程指标告诉我们结果如何发生，比如关键步骤完成率、首次成功时间、重复使用频率。

只看结果指标，问题出现时很难定位。只看过程指标，又可能忽视最终价值。

好的指标体系，需要两者配合：结果看方向，过程找原因。

口径必须清楚

一个指标如果没有清楚口径，就很容易引发误解。

“活跃用户”到底是打开过应用，还是完成过关键行为？“转化率”分母是谁？“留存”按自然日、滚动周期还是行为周期计算？

口径不清，指标就不是证据，而是争论素材。

警惕指标被优化坏

指标一旦成为目标，就会影响行为。

如果只看点击率，标题可能越来越夸张。如果只看时长，产品可能故意制造低效停留。如果只看发布速度，团队可能牺牲质量。

设计指标时要问：如果大家拼命优化这个数字，会不会伤害真正目标？

指标要能指导行动

一个指标如果变差，团队应该知道下一步可能查什么。

比如“整体留存下降”太大，可以继续拆成新用户留存、老用户留存、不同渠道留存、关键功能使用后的留存。拆开之后，行动才有方向。

好指标不是让人焦虑，而是让人知道从哪里开始看。

不要忘记定性信息

指标能告诉你发生了什么，但未必告诉你为什么发生。

用户访谈、客服记录、行为观察、评论反馈，能补足数字看不见的部分。产品判断最好结合定量和定性。

没有定性，指标容易空转；没有指标，故事又容易失真。

结论

产品指标设计的核心，是用数字回答真实问题。不要为了看起来专业堆报表，也不要迷信单一核心数字。好的指标体系能连接目标、过程、结果和行动，让团队更清楚地判断产品是否真的变好。

延伸阅读

• 数据质量为什么重要：坏数据会让好分析得出坏结论
• 产品需求优先级怎么排：不是谁声音大谁先做
• 用户研究怎么入门：不是问用户想要什么

意义建构是什么：人在混乱信息中如何形成理解

摘要

意义建构，是人在信息杂乱、事件不断变化、解释尚未稳定时，主动整理线索、形成理解框架的过程。它不是简单接收事实，而是把事实放进关系、背景和故事中。理解意义建构，可以帮助我们看见：人不是先拥有完整真相再行动，很多时候是在行动、交流和复盘中逐步明白自己面对的是什么。

信息多不等于理解多

我们常以为信息越多，理解越清楚。但现实常常相反。

消息越多，细节越多，观点越多，人越可能不知道该相信什么。因为理解不只是堆材料，而是建立关系：哪些信息重要，哪些只是噪声，哪些事实彼此矛盾，哪些变化说明问题正在转向。

意义建构要做的，就是把散乱信息变成可理解的结构。

人会用故事理解变化

面对混乱，人很自然会讲故事。故事能回答：发生了什么，为什么发生，接下来可能怎样。

这有好处，也有风险。好处是故事让行动成为可能；风险是故事可能太快成形，把复杂现实压成一个简单解释。

因此意义建构不是拒绝故事，而是不断检查故事是否还能容纳新信息。

意义建构发生在交流中

很多理解不是一个人在脑子里独自完成的，而是在对话里慢慢成形。

你说出一个判断，对方追问一个细节，你发现自己的解释有缺口；团队复盘一次事故，大家拼出不同视角，才知道真正的问题在哪里。

交流不是理解之后的表达，很多时候就是理解发生的地方。

先给混乱一个临时框架

意义建构需要框架，但框架不必一开始就完美。

可以先问：这是一个目标不清的问题，还是约束变化的问题？是信息不足，还是价值冲突？是局部异常，还是系统反馈？

临时框架让人开始整理，但它应该可以被修正。框架是脚手架，不是牢房。

不要把第一版理解当最终答案

意义建构是动态过程。第一版理解通常只是起点。

随着新信息出现，原来的解释可能要扩展、收缩或完全改变。一个成熟的理解，不是从第一天就正确，而是能持续吸收证据。

这也是为什么复盘、记录和反方观点重要。它们让理解有机会更新。

意义建构和自我理解

意义建构不仅用于外部事件，也用于理解自己。

人会给经历命名：失败、转折、成长、损失、选择。不同命名会改变我们如何看待过去，也会影响下一步行动。

但自我叙事也需要谨慎。不要把一次经历过早写成一生结论。

结论

意义建构，是人在混乱中逐步形成理解的过程。它需要事实，也需要框架；需要故事，也需要修正。一个人越能意识到自己如何建构意义，就越不容易被第一版解释带走，也越能在复杂变化中保持清醒。

延伸阅读

• 叙事思维是什么：为什么人会用故事理解自己
• 解释框架是什么意思：为什么同一件事会被讲成不同故事
• 写作为什么能帮助思考：把脑中的混乱变成可修改的结构

产品品味是什么：不是个人偏好，而是取舍能力

摘要

产品品味不是“我喜欢什么”的个人偏好，也不是只看界面漂不漂亮。它更像一种取舍能力：能判断什么对用户重要，什么只是噪音；什么复杂度值得引入，什么应该留在系统外；什么细节会改变体验，什么细节只是自我感动。产品品味可以训练，但前提是把它从玄学拉回场景、标准和反馈。

品味不是偏好

很多人谈产品品味时，容易把它说成一种天赋：某些人就是有感觉，某些人就是没有。

这种说法听起来高级，但对做产品没有帮助。偏好可以很私人，品味却必须能解释。你可以不喜欢某种视觉风格，但如果要说它产品上不好，就需要说明它影响了什么：理解成本、操作效率、信任感、信息层级，还是长期维护。

品味不是一句“我觉得”，而是能把感受翻译成判断。

好品味先看场景

同一个设计，在不同场景里可能完全不同。

一个记账工具需要的是清楚、稳定、低干扰；一个创意编辑器可能需要更强的探索感；一个后台系统则更看重密度、可扫描和容错。离开场景谈品味，就容易把所有产品都做成同一种漂亮。

产品品味的第一层，是知道这个东西服务谁、在什么压力下被使用、用户真正要完成什么。

取舍比堆功能更难

产品里最体现品味的地方，往往不是加了什么，而是没有加什么。

功能多不等于能力强。每个入口、字段、设置项和提示，都会占用用户注意力，也会增加系统维护成本。好的取舍，是知道某个能力虽然有用，但它会不会破坏主流程；某个需求虽然真实，但是否属于这个产品当前应该承担的范围。

品味不是拒绝复杂，而是知道复杂应该出现在哪里。

细节不是装饰

有些细节看似小，却会改变用户对产品的信任。

错误提示是否说人话，空状态是否告诉用户下一步，加载中是否避免重复提交，删除前是否给出清楚后果。这些都不是装饰，而是产品对用户处境的理解。

真正好的细节，不是为了让人注意到设计师，而是让用户少一点犹豫和误解。

品味需要反复校准

产品品味如果只来自个人经验，很容易变成偏见。

训练品味，需要把自己的判断放到反馈里校准：看真实用户怎么用，看数据哪里掉，看客服问题怎么重复出现，看团队维护哪里痛苦。用户不一定总能说出好方案，但他们的行为会暴露产品判断是否成立。

好的产品人不是永远相信直觉，而是让直觉不断被现实修正。

团队里的品味要能讨论

如果一个团队只能靠某个人拍板说“这个感觉不对”，品味就会变成权力。

更健康的方式，是建立可讨论的标准：这个改动是否降低理解成本？是否让主任务更快完成？是否引入了未来维护负担？是否和产品定位一致？

当品味能被讨论，它就不再只是个人风格，而会成为团队共同的判断能力。

结论

产品品味不是玄学，它是一种长期训练出来的判断：看场景、看用户、看约束、看取舍，也看细节背后的成本。

它不等于追求漂亮，也不等于固守个人偏好。好的品味能让产品更清楚、更克制、更可信。它最后落到一句朴素的问题上：在这个场景里，什么东西真的值得被保留？

决策质量怎么判断：不要只用结果评价一次选择

摘要

决策质量不能只靠结果判断。一个好决策可能遇到坏结果，一个坏决策也可能碰巧成功。真正值得复盘的，是当时的信息是否充分、假设是否清楚、风险是否被看见、选择是否符合目标。把决策和结果分开，才能减少事后诸葛亮，也能让下一次选择更稳。

结果不是唯一证据

人很容易用结果倒推过程。

项目成功了，我们说当初的判断英明；项目失败了，我们说当初怎么那么草率。可现实并不这么简单。很多选择是在信息不完整、时间有限、风险无法完全消除的情况下做出的。结果会受运气、环境、他人行动和偶发事件影响。

如果只用结果评价决策，我们就会奖励侥幸，惩罚合理冒险。

区分决策过程和结果反馈

决策质量看的是过程，结果反馈看的是现实给出的回应。两者都重要，但不能混在一起。

一个高质量决策，至少应该回答这些问题：目标是什么？可选方案有哪些？关键假设是什么？最坏情况是什么？如果事实和预期不同，什么时候调整？

结果反馈则回答另一类问题：哪些假设被验证了？哪些风险真的发生了？有没有新信息出现？下一次是否需要改变判断模型？

过程决定当时是否合理，反馈帮助未来变得更合理。

坏结果不等于坏决策

有些选择虽然失败，但在当时条件下仍然值得做。

例如一个产品实验经过用户访谈、数据估算和技术评估后上线，结果转化率没有提升。这不一定说明决策差。它可能说明某个假设不成立，也可能说明样本、时机或执行细节有问题。

如果团队把所有失败都归为“当初不该做”，以后就只会选择最保守的路。

好结果也不等于好决策

相反，有些成功只是碰巧。

没有验证需求就上线功能，刚好踩中热点；没有风险评估就投入资源，刚好没有出事。这类结果会制造危险的信心，因为它让人误以为自己的方法有效。

真正的复盘要敢于问：如果重新来一次，在不知道结果的情况下，我们还会用同样方式做决定吗？

建立决策记录

最简单的办法，是在重要选择前写一份短决策记录。

不需要很复杂，只要记录五项：背景、目标、备选方案、关键假设、触发调整的信号。这样做的好处是，复盘时不会完全被事后情绪控制。

决策记录不是为了证明自己正确，而是为了保留当时的思考现场。

复盘时问更好的问题

复盘不要只问“为什么失败”，也要问“当时哪些信息我们没有看见”“哪些假设太自信”“哪些风险被低估”“有没有更便宜的验证方式”。

同样，成功后也不要只庆祝。可以问：哪些成功来自方法，哪些来自时机？这套判断能不能迁移到下一次？有没有被结果掩盖的问题？

好的复盘不是审判过去，而是训练判断。

结论

决策质量的核心，是把选择从结果崇拜里解放出来。

我们当然要尊重结果，但不能被结果完全支配。更成熟的判断，是同时看过程和反馈：当时是否有清楚目标、合理证据和风险意识；之后是否能根据结果更新模型。这样，成功不会让人盲目，失败也不会让人只剩懊悔。

问题框架怎么搭：先把问题问对，再谈解决方案

摘要

问题框架，是我们决定“这到底是什么问题”的方式。很多解决方案失败，不是因为执行不够努力，而是因为一开始就把症状当成问题，把立场当成问题，或者把太大的困境压缩成一个看似简单的选择。搭好问题框架，意味着先看清对象、边界、原因、约束和判断标准，再谈方案。

为什么问题框架比答案更早

一个问题被说出口时，往往已经带着方向。

“怎样让用户多点按钮”和“为什么用户没有继续完成任务”，听起来都在讨论转化率，但前者默认按钮是关键，后者还保留了重新理解场景的空间。问题框架不同，后面会收集不同信息，也会排除不同可能性。

所以，解决问题前最该警惕的不是“我有没有答案”，而是“这个问题是不是已经把答案偷偷塞进去了”。

不要把症状当成问题

症状是表面可见的异常，问题是导致异常反复出现的结构。

团队会议很低效，这是症状。真正的问题可能是议题没有负责人，决策权不清，信息提前准备不足，或者大家把同步会当成汇报会。只盯着症状，就会得到“缩短会议”“少开会”这样的表层方案；它们有时有用，但不一定触及原因。

判断一个描述是不是问题，可以问一句：如果这个现象消失了，背后的冲突还会不会以别的形式出现？如果会，它可能只是症状。

不要把立场当成问题

很多争论卡住，是因为双方讨论的不是同一个问题，而是在维护各自立场。

比如“要不要做这个功能”，表面是功能取舍，实际可能包含三层问题：这个用户需求是否真实？这个需求和产品定位是否一致？当前团队有没有能力维护后续复杂度？

如果只停留在“做”或“不做”，争论会变成输赢。把立场拆回问题，才可能讨论证据、成本和判断标准。

给问题加边界

太大的问题会让人无从下手。比如“怎样提升产品体验”，这个问题几乎没有边界。更好的问法是：在哪个用户阶段、哪类任务、哪种失败体验、什么时间范围内提升？

边界不是缩小野心，而是让行动变得可检验。

一个可工作的框架至少包含四件事：

• 对象：我们讨论的是谁、什么场景、哪个环节。
• 现象：现在发生了什么，和期望有什么差距。
• 原因假设：可能是什么机制导致了差距。
• 判断标准：怎样算这个问题被改善了。

把问题从“谁错了”改成“什么机制在起作用”

糟糕的问题框架很容易把复杂情况变成人的道德判断。

“为什么大家不主动”往往比“什么机制让主动变得没有收益”更难推进。前者把问题压到个人身上，后者会逼我们看激励、反馈、权限、风险和协作方式。

这不是替人找借口，而是让问题进入可改变的层面。

好问题会改变可见范围

真正好的问题框架，往往让原本看不见的东西浮现出来。

当你问“为什么用户不喜欢这个功能”，你看到的是态度；当你问“用户在什么任务里会觉得这个功能值得学习”，你看到的是场景；当你问“这个功能增加的复杂度由谁承担”，你看到的是长期成本。

问题不是越抽象越高级，也不是越具体越好。好的问题能把注意力放在最能解释现实的位置。

结论

问题框架的价值，不是让我们显得更会分析，而是减少错误努力。

很多时候，我们不是缺少答案，而是太快接受了第一个问题。先把问题问对，意味着愿意慢一点：区分症状和原因，拆开立场和事实，给对象加边界，明确判断标准。这样得到的方案未必完美，但更可能对准真正需要改变的地方。