在所有的工作中，并没有什么捷径可走，我们所能做的就是老老实实了解业务，摸透业务的本质。

• 愿景： 作为刚转行成为产品经理1年的产品新人，在产品设计中踩过的那些坑，希望分享出来，给新入门的新人一些提醒。
• 目标人群：产品人&年龄<1岁
• idea：分享一些实际的产品设计案例
• 竞争对手：个人兴趣、时间、惰性
• 预计耗时：阅读本文预计耗时10分钟
• 不放原型图的原因：因为是政府涉密项目，不敢放出原型图，请见谅

笔者刚转入产品这个坑的时候，就是B端产品的坑，然而B端产品没有太多的经验可以借鉴，只能在行业内摸爬滚打。所以在此劝谏所有的新入行的B端产品新人们，不要想着有什么捷径可以走，老老实实的了解业务，厚着脸皮请教，摸透业务的本质，跟客户打成一片，有可能的话跟随客户进行业务办理一段时间，才有可能做出一款满足B端用户需求的产品。

一、 一款B端产品的实际业务需求

笔者所在的行业是某政府行业，该行业的业务相当复杂，据说某套系统就是几千万。客户的某部门，响应xx号召，需要建立一套大数据监督平台，对所有工作人员的业务办理进行监督，规范业务动作。

因此客户提出的总体需求如下：

1. 这套监督系统，不能增加工作人员的工作负担和心理负担，要做到让他们忽略了这套系统的存在。
2. 监督的粒度不要太细，也不要太死，只要做到对部门而非个人的监督即可；做到不用实时监督改善，只要可以起到督促作用，每月有改善即可；也不用监督到规定时间完成规范动作的100%，只要超过90%即可。
3. 监督的风险点，按照业务办理流程中的问题发生比较严重的8个领域展开，给了我们一个风险描述文档。
4. 关注的点是在未来的一段时间内，该部门的该风险情况，是否改善。
5. 要紧贴实际的业务办理需求，不要采用监督的方式，去约束工作人员的业务办理方式。

二、产品设计的前期阶段，业务调研与需求核实

如上的5点需求，其实是可以形成需求文档，进行产品设计，进行开发。

如果我们真这么干了，这里就会有3个大坑等着埋我们：

1. 客户提供的业务风险点，和实际业务风险大相径庭。
2. 与客户交流过程得知的业务流程，与实际的业务流程存在差异，因此造成了对业务数据的理解出现了严重的错误。
3. 在与实际业务办理部门交流过程中，新增一些业务部门具体的需求，提起来貌似有道理，然而会打乱执法监督系统的定位。

因此，如果我们在不填埋如上三个坑的基础上，设计出来的大数据监督系统，必然华而不实，甚至很有可能在一开始需要的业务数据都无法获取，也就根本无法做出一个大数据监督系统。

所以在这里，我们面对B端客户的时候，也需要“三省需求”：

1. 产品需求的定位是否紧绕boss给的期望？
2. 需求是否真实有效？
3. 需求是否具有可行性？

产品的需求是无穷无尽的，怎么为产品的需求划下分界线，笔者看到了一句话，甚好——“必不可少和锦上添花”。

因此笔者秉持着这两个方向，深入基层，跟随业务部门进行一段时间的业务处理，深度体验业务流程，了解了基层业务办理的真实状况，以及业务数据流的流向，并逐一核对前期客户提出的风险监督点，评估风险监督点是否真实有效监督到了业务办理过程中最容易出问题的节点。

最终，笔者凭借对业务的理解、业务部门的多次交流沟通以及客户boss的沟通（在这里沟通没有任何技巧遵循：首先反复沟通；其次是有冲突的一定要多次两边核对协商寻找共赢方法；最后是一定要把自己理解的内容复述给客户从而保证理解的准确性 ），重新修改了风险监督点，并为每一个风险点画出业务流程图和数据流程图（画重点：数据流程图包括数据对象和数据属性），从而确定了最终的1.0版本需要开发的需求。

三、产品设计阶段——1.0版本

进入产品设计阶段了，终于可以踏着欢快的步伐，正常走入产品经理该干的阶段了。然而，产品经理，哪有这么好干的啊，处处有坑，你以为是康庄大道，实际上是，emmmm，暗箭不少。

首先，在产品设计的时候，要确定产品设计的基调。

什么叫基调？

举个例子：比如国家的财政基调是维稳，那么无论是银行也好，财政政策也好都是以维稳为核心，进行货币政策调整以及财政政策调整。

又是如何定基调呢？

产品定基调的方法，首先是要基于boss给的预期，明确核心点是什么；其次是根据boss给的时间点，对每个核心需求进行价值评估（价值评估的方法，参考《B端产品经理的成长之路》），对需求进行排序；最后就是根据开发人员的技术难度对需求进行可行性评估，对排序的需求进行取舍，保证在时间节点前，做出的1.0版本是尽最大可能性满足boss需求的。

笔者结合客户的时间点要求、业务需求、目标需求以及产品的MVP（问度娘）理念，确定了一版产品设计的基调：以异常数量展示为主，辅以趋势分析，结合数据分析的可视化展示方式，进行1.0版本的产品设计；考虑时间成本，页面设计上尽量复用；整个页面布局设计上，简单、大气。

确定了产品的设计基调，笔者就开始了原型图的设计。因为是大数据分析监督平台，因此不涉及业务流程的设计。但是有一点很核心的，就是一定要清楚业务数据流，以及数据内容和来源。这在设计数据分析类的产品，有着至关重要的地位。

在进行可视化设计的时候，是有坑的。

（1）从页面颜色搭配上，最好3类颜色即可，颜色太少，页面显得单一，颜色太多，页面显得花哨，反而夺去了数据的焦点

（2）在可视化的数据展示上，千万不要为了追求图表展示而展示（类似：堆积柱状图、面积图、热力图、雷达图、形状图、云词条、气泡图），不同类型的图属性不同，比如仅仅是二维数据的展示，就简单的柱状图就很好。在图表展示上，若数据维度不超过3，最好一种颜色描述，会使得图表的数据化展示上简单、大气。

（3）如果页面上的图标可视化展示较多，建议背景用浅灰色，如果页面上的列表展示较多，建议背景采用渐变，这样会使得产品设计出来层次感很强，而且很容易获取到关键数据信息。

（4）由于主要涉及的是数据化的分线展示，因此一定要把页面的逻辑规划好，比如单位排名列表，可以跳转到某个单位的多维度分析页面；比如某类风险xx条，可以跳转到对应的列表详情；如果逻辑不清楚，开发完成之后，产品都不清楚产品的逻辑。

（5）可视化产品的主体设计逻辑上，一般分为两类：以数据可视化展示为主和以数据结论展示为主。

数据可视化展示为主是从数据推到结论，需要客户自己得出结论。而数据结论展示为主，是从结论推到数据，需要客户根据结论，主动去获取原因（即进入到数据多维度分析展示的页面）。

不过当前的第1.0版本，我采用的是第一类做法，然而在试运行阶段，才突发灵感想到了第二类（第二类，非常清楚了解客户关注的风险的权重，并对风险结论进行归类，计算出不同结论的风险指标，通过指标分析，转化成文字的方式直接展示结论，而不要用数字了）。

四、 产品原型评审阶段

因为是B端产品，因此，产品的原型评审需要两类人：公司内部的人员和客户。

（1）公司内部的人员进行第一版评审，然后进行原型调整迭代，并再次评审，直到通过评审。

公司内部的人员评审，这里就会遇到很多问题：

1. 他们的业务可能没有你精通；
2. 每个人的角度不同（开发、设计、测试、技术总监等），看问题也不一致。

仅仅是这两点，就会导致他们对你设计的产品提出很多问题。比如：技术总监就会提出，页面设计有点简单了，功能点不够；开发人员会提出，这个功能点可能过于复杂，无法开发等等问题。

这个时候，我们就需要发挥自己产品经理的本领了，其实客户不仅仅是外部的客户，内部也有客户，所以也需要对他们进行安抚和讲解。

通过几个维度：客户的实际关注点、需求开发的成本周期、技术实现方式、业务实际情况这四个方面进行思考回答即可。如果被内部人员左右设计，很可能最后交出去的产品也不会得到客户的认可。

（2）内部通过评审之后，给客户进行演示产品设计效果，再次根据客户提出的真伪需求以及真伪意见，进行调整，这里需要学会去伪存真，方法参考苏杰的《人人都是产品经理2.0》。

在客户进行评审的过程中，客户毕竟不是专业的，因此会提出许多主观的想法，和要实现的功能。但是这个时候，需要产品不断的引导客户，从功能的实现的现实价值需要、功能实现的业务数据上的可行性、换一种替代功能引导、以及功能实现上的技术问题和时间成本四个维度进行引导，再次判断客户的需求是否是真实需求还是突发奇想。

总之，我们产品一定要有自己的产品原则。

五、产品开发阶段

产品原型定稿之后，就可以进入产品开发了。在这个阶段，一定要跟好前端开发人员的开发效果，越早体验交互效果，越好。

在笔者设计的监督分析系统开发出来之后，笔者才介入测试交互效果。只能说，很反人类。

交互效果总结问题点如下：

1. 页面交互逻辑混乱；
2. 页面操作混乱，特别是，同一条数据，点击不同的单元格，跳转的页面不同；
3. 页面的交互效果模糊，当鼠标移到某个区域的时候，不知道该区域是否是可以点击，还是可以做其他操作；
4. 页面数据重叠，在不同的页面上存在着类似的数据统计；
5. 页面数据展示散乱，具体的说就是，一个页面上展示的数据，不在一个层面上

由于这些问题，直接导致了页面展示效果差，交互混乱，无法准确明白每个页面展示的关键数据，做大数据分析平台最重要的点就是：抓核心关键数据做重点突出展示，可视化设计一定要贴合人类视觉的直观。

六、产品测试阶段

在此类阶段，测试的时候，一定要特别关注数据展示的内容上，笔者在测试的时候，发现开发人员经常把页面展示内容的字段弄错。

总结

好的大数据分析产品，首要就是抓住核心数据进行分析展示，并且一定是符合人的第一视觉直观感受，且贴合业务的需求。

本文由 @萧羽 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议