显性与隐性

如图，当我写好评论内容点击发布时，一条提醒信息赫然出现：「请修改您的评论」。

懵逼了，为什么要我修改评论？

赶紧跑去问程序员哥哥，得到的回复是「担心用户发广告，所以加了一条过滤规则：如果评论中包含网址、电子邮箱、手机号码或一些敏感词，发布时就会被提醒修改。」

在理，情不自禁为他考虑之周全点了个赞。但回过神来发现，问题并没有得到很好的解决——提醒文案并没有说明为什么要修改，以及应该如何修改。这当然会让用户（这个时候刚好是我）感到疑惑。他考虑到了产品端的安全性，却忽视了用户体验。

也许你会说，把提醒文案改改就好啦。当然要改。但除此之外，还得了解这种问题为什么会出现。

为什么文案不够友好？因为程序员没有写好文案。

为什么没写好？因为产品经理（这个时候刚好是我）没有提供文案。

为什么没提供？因为我不知道过滤规则这回事儿。

为什么不知道？因为我没有考虑到「可能有用户会在评论里打广告」这个用例。另外，尽管程序员设定了规则却也没有告知。

你看，问题根源很快就找到了。如果我当初考虑周全了，或者程序员告知我了，我自然会准备相应的文案。好像两边都有责任？非也。这种情况下只能怪罪于产品经理，因为这并不是技术上出了问题，而是我确实疏漏了。疏漏，不仅在规则的设定上，还在团队的沟通协作上。

反省，总结。以后该怎么做，才能避免类似问题的出现呢？

• 负责定义功能的人（小团队没有交互设计师，所以得由产品经理也就是我来做），事先考虑好各种用例

• 做好用例清单，跟程序员一条条核对
• 确认没问题的话，准备文案
• 把对应用例和文案给到程序员

• 说清楚俩人如何协作。例如，需要文案时交给我处理（难道程序员不能自己写文案吗？当然可以，但如果他把握不好文案风格的话，还是不写为好）

你看，一个问题的出现，往往有显性和隐性两个原因存在。只解决前者（也就是修改文案），问题必定此消彼长，所以毫无疑问需要挖掘隐性原因。怎么挖掘？「五个为什么」法则可以常常派上用场。但在此之前，遇到问题时你必须多问一句，这是显性还是隐性问题？

面对新需求，也往往要考虑到显性和隐性两方面。显性的是用户想要做什么，而隐性的就是用户为什么要这么做。