add new post

Author: liuning0820

_posts/2026-01-25-功能存在到用户知道.md

@@ -0,0 +1,66 @@
+---
+layout: post
+author: liuning0820
+tags: [product design]
+comments: true
+---
+
+# 功能存在 ≠ 用户知道
+
+作为一位开了24,000公里的特斯拉车主，我对这辆车非常满意——操控精准如臂使指，安全性能令人安心，每一次出行都充满信心与愉悦。
+
+但有一个细节，我一直耿耿于怀：在使用导航时，只要打转向灯，屏幕上就会弹出摄像头监控画面。偏偏这个画面会遮挡关键的导航地图信息，尤其在复杂路口，常常让我措手不及，差点错过转弯。
+
+![]({{ site.url }}{{site.baseurl}}/images/2026-01-25-功能存在到用户知道01.png)
+
+我一度以为这是无法更改的设计缺陷，直到昨天坐朋友的车，才恍然大悟——原来这个监控窗口是可以移动的！
+朋友轻描淡写地说：“你只要长按那个画面，就能拖到左边。”
+果然，一试就成。窗口移到左侧后，我用余光就能看清盲区，再也不用扭头或担心挡住导航路线。
+就这么一个小小的交互操作，竟能让驾驶体验提升一大截。可笑的是，我开了两万多公里，竟从未发现。
+
+
+![]({{ site.url }}{{site.baseurl}}/images/2026-01-25-功能存在到用户知道02.png)
+
+这让我想起早年用微信的经历：想在一段文字中间插入几个字，总是习惯性一路回删重打。直到有朋友告诉我，“长按空格键，光标就能自由移动”——那一刻，我才意识到自己错过了多少效率。
+这类“长按拖动”“长按移动光标”的操作，本质上属于隐式交互（Implicit Interaction），也常被称作“专家模式”：功能确实存在，但没有明确引导，普通用户很难主动发现。
+
+## 功能存在 ≠ 用户知道
+
+在产品工作中，我们常常陷入一种“知识的诅咒”：
+我们知道功能在哪、怎么用、为什么重要、能解决什么问题。
+但——用户不知道。
+这不是一句调侃，而是产品设计中最容易被忽视、却最值得警惕的真相。
+很多团队都经历过这样的场景：用户提出一个需求，你心里立刻冒出一句：“这功能我们早就做了啊！” 你甚至能立刻指出入口、按钮样式和操作路径。
+可用户依然一脸茫然。
+这不是用户的问题，而是产品的问题。
+
+## 当用户“重复提需求”，其实是可用性在报警
+
+经常和用户交流的好处，不只是获取新点子，更在于你会听到他们反复提出一些“早已存在”的功能需求。
+这时，请别急着纠正：“这个我们早就有了！”
+相反，这恰恰是一个暴露可用性问题的信号。
+为什么用户找不到已有功能？常见原因包括：
+- **入口不明显**：藏得太深，或缺乏视觉提示；
+- **命名不直观**：术语专业，但不符合用户语言；
+- **路径不符合自然操作流**：用户想A，你却让他先做B再做C；
+- **功能与用户的心智模型错位**：你以为他需要"监控画面"，他只关心"别挡住导航"。
+
+## 真正有价值的反馈，往往藏在“已实现的需求”里
+
+很多团队热衷于听“新需求”——因为那意味着可以开发新功能、增加亮点、拓展边界。
+但真正高价值的反馈，往往是那些“你已经做过，但用户没发现”的需求。
+为什么？因为它们揭示的是更深层的问题：
+
+- 可用性缺陷
+- 信息架构混乱
+- 命名与认知偏差
+- 用户行为路径与设计预期脱节
+
+这些问题比“缺功能”更隐蔽，却对体验影响更大。一个没人能找到的功能，本质上等于没有上线。
+
+## 结语：功能上线 ≠ 价值实现
+
+只有当用户理解、发现并顺利使用时，功能才算真正“上线”。
+产品设计的终极目标，不是堆砌功能，而是让价值被看见、被感知、被轻松获取。
+下次再听到用户提出“已有功能”的需求时，请别急着解释——
+不妨问问自己：我们的设计，是否真的站在了用户的视角？