我们一直强调，设计是要服务于业务目标的。但在实际工作中，这句话往往会变了味。
大多数时候，业务目标是由一系列数字呈现的。数字看起来明确、量化、可追踪，所以也就理所当然地变成了决策依据、优先级判定标准。但问题也就出在这里，我们每天面对的是 KPI，而不是目标本身，这就让设计工作很容易变得看起来合理，实际上却偏离了核心。
KPI 是起点，但并不是答案
KPI 本意是为了帮助我们从目标回推行动，但在实际工作中，它往往变成了另一种“任务指令”。指标一旦被拆解到每个人头上，就很容易变成一个明确的执行目标，而不再是一个值得分析的问题。
我们会习惯性地围着 KPI 做设计：DAU 要上涨，那就提升 Push 的频次；GMV 要提升，就改按钮、调样式；点击率要提升，那就多加俩弹层。
这些操作不一定错，但很多时候，它们只是“指标驱动”下的机械响应，而并未真正回到目标本身的去理解它的目的，从而反过来思考我们究竟应该选择什么样的路径和方法来达成？
事实上，很多的需求在流转过程中逐步失焦，并不是因为老板瞎定目标，也不一定是 KPI 本身出了问题，而是大家在拆解 KPI 时，把它当成了终点，而不是线索、问题。这也是最常见、也最隐蔽的认知错位。
KPI 是我们实现业务目标推理链路上的线索节点。你需要做的，是搞清楚它和目标之间的逻辑关系，以及它和当前设计工作之间的传导逻辑。
如果你发现这之间没有可验证的连接，那你就要停下来问一句：我现在做的，是为了实现目标，还是只是为了完成一个动作？
用户反馈不等于业务问题
如果说 KPI 让我们在执行上会失焦，那用户反馈的问题则往往会让我们在方向上跑偏。
很多设计师在面对用户的声音时，会本能地站在「同理心」的一边。我们习惯说，“要为用户而设计”，于是只要用户说“这个地方不好用”或者说“我希望能有某个功能”，我们就会将它们一通整理，然后写一个 PPT 告诉需求方，产品需要改进、体验需要优化。
这看起来很负责任，也很为用户着想，但同时也可能会出现跑偏的问题。
用户说的，真的是他的本质问题吗？他描述的是需求，还是他自己想象出来的解决方案？
大多数情况下，用户反馈的是某个体验层的卡顿感。比如“流程不合理”“步骤太多”“结构不清晰”。但这些感受并不等于问题本身，它们往往还存在着更深层次的问题。
你得顺着这些反馈往下挖。你要问的不是“他说了什么”，而是“为什么他说这个”。更重要的，是判断这个问题是否真的和我们的目标相关，是否值得投入资源去解决。
而判断的标准，不是谁的声音大、谁抱怨多谁就对（对于产品经理的沟通同理）。而是这个问题，是否来自我们真正要服务的那一类人、那一类场景？
不是所有用户的问题都需要被解决。一个产品的核心竞争力，恰恰来自于它知道该为谁解决问题，也知道不为谁解决问题。
所以下当一次我们面对用户的问题，不妨思考一下：这是症状，还是根源？是个体，还是代表？是“我们要服务的用户”，还是“我们暂时不解决的场景”？
看到这里，相信你对「设计师如何理解业务目标、判断需求价值」已经有了一些新的思考。
那么，后面的内容将更值得你深入了解。
在这篇文章剩下的付费部分，我将继续展开三个关键问题：
01. 如何判断一个需求值不值得做？
拆解业务目标，建立需求与转化路径之间的连接逻辑。
02. 如何构建自己的业务本体结构？
用一个案例，展示如何将获取到的信息转化为思考、决策的支撑。
03. 有了判断，如何把握时机？
不是表达得快就有效，而是要谋定而后动，选对节奏精准出手。
欢迎订阅我的小报童专栏，解锁本期文章全文内容。
