B端产品不止是业务结构庞大，信息复杂，同时其业务的精确性也有很高的要求，服务于B端的业务，不能够出信息错误，填错一个信息，就会引发巨大的问题。本文为你讲解，大型B端业务中的设计方法。
一 、业务细节
1. 业务配置细节
任何一个行业都有他的业务单元，每一项服务是不一样的。
比如一艘船要换船员，要换现金，那么这就是服务单元；比如你在阿里云买服务器是不是要选CPU、内存等配置？
也就是说，将现有业务进行整理，将具体的业务细节配置梳理清楚——每一个指标是怎么填的？填什么单位？什么时候填？有什么限制？什么时候又不能填了？
比如船都出海了，你还能要求换船员吗？就不能了，这就是有这个船是否在港的限制。
具体的配置内容会很多，这时候就需要你的信息结构能力。
如果业务很大很复杂，那就进行拆分，将大业务，拆分成一个一个小业务。然后再把每一个小业务，花时间理解透彻，确定好业务流程和内容。其他的小业务也是这样梳理，拆分到你可以控制的范围，最后再把业务组装起来。
如果你能处理好每一个小业务，那么组装起来之后，你就会理解整个业务。
2. 关键节点
每一项业务都有他从开始到结束的流程，期间一个节点到下一个节点是如何操作的，就是关键节点。比如：船要卸货，那么就要有卸货许可，你得拿到这个许可，有效，才会让你卸货。
根据关键节点，你肯定要对不同的业务设计功能，这也是做这个大型B端业务的重点。同时，你在设计界面的时候，一定要标识清楚业务的状态，当前用户需要做什么？你不能等着用户去做，你得提示他进行下一步。
关键节点就是业务过程中的判断节点，会根据这个判断得到下一步的结果，这个部分在业务梳理过程中会发现，同时在与业务进行沟通的时候，也会得到这部分信息，记得记录下来。
3. 业务状态
这就说到业务状态了，业务是完成还是没完成？中途遇到什么问题了？要预付款吗？有意外情况吗？你想呀，在实际航海过程中，这样的问题数不胜数，你得有很好的状态呈现，即时反馈对不对？
用户使用产品的时候，一定会关心当前的状态，就像是你在淘宝买了商品，你会关心是否付款，物流情况，退款、退货情况等等。
同样的道理，做B端业务的时候，产品设计到一定程度的时候，很多小的业务提示，需要很好的呈现，其中包含：
业务状态（类比电商预定状态、有哪些商品）
当前服务状态（类比当前订单状态）
服务配置状态（类比商品大小、颜色、款式、数量等状态）
服务中途的状态变化（类比物流状态）
订单支付状态（类比电商支付状态，但是周期不一样）
4. 用户掌控感
用户原本都是在线下完成业务的，你突然要用线上的，掌控感肯定没那么强，所以必须要让用户感到有掌控感。
比如：编辑是不是可以撤销？订单什么时候可以取消？我什么时候要付钱？用户如果中途取消订单或者取消订单里面的一个服务，怎么办？
尽可能的考虑实际情况，从实际情况出发，不要把互联网这一套搬过去，这样会让用户觉得很难用。
B端业务实际中会遇到很多情况，在进行产品设计过程中，天然的和线下操作是不同的，不同点在于：
很多以前线下通过邮件、电话、口头、文件、签字等传达的信息，线上必须进行全覆盖。
因为线上话之后，一切信息都需要通过软件呈现，所以，以前线下没有的，为了业务完好的在软件中完成，还需要根据实际情况配备。
基本原则：凡事有回音，事事有反馈。
二、产品效率
1. 如何设计高效率的B端产品？
我们都知道，B端业务复杂，功能多、流程多，但是用户还是很重视效率，这个时候怎么办？你就得把用户高频和低频的需求分开，主线流程要清晰，常看的状态一定要摆出来，有些功能藏起来了，用户需要的时候，就要放出来。
比如：订单的金额，就必须呈现出来，但是具体细节要藏起来，用户可以随时进去看，有变动的时候要提示出来。
这是什么设计思路？也就是，用户需要的时候才出现。
用最简单的表达做B端产品：
能不说的废话，就不要说（比如：明明不需要提示文案，非要写一句文案，反而让用户迷惑）
能减少的操作，一定要减少（比如：为了创建一个内容，非要用户先去命名，但是完全可以不用的）
主题流程一定要明确（比如：整体流程设计成类似电商的购物流程，而不是自己重新设计一套流程）
能隐藏的信息，就隐藏（比如：用户当前完全用不到的配置信息，呈现出来，反而迷惑）
2. 如何评估产品效率？
从流程上看，用户的操作步数是不是最简单的步数？
从界面呈现上看，有些业务表单特别多，这个时候表单设计是否科学就很重要。
从时间上看，进行可用性测试，看用户的操作时长，看用户操作完一个订单需要多久？
用户操作错误情况，看用户误操作的次数，用户误操作一定是产品设计问题。
让一个完全外行的人，使用你的产品，看学习成本有多高？
如果以上5点，都达到一个良好的情况，那么恭喜你，你的产品经理为你节省了大笔资金和时间，至少是百万级别的。
交叉分析法
我在当时整理业务时用到的方法，因为最开始并不了解这个业务，一直弄不明白怎么才算一个Case，不像电商，加入购物车、结算、填地址信息就好了。
所以，我想办法做了一个分析：
这是一个元数据的运用，这个概念是出现在《web信息架构》这本书里面的核心概念，就是：你这个关键信息是如何构成的？构成方式有哪些？
当时就搞不懂，到底是以港口为主线，还是以船为主线，最后我们看图中绿色的点就可以看出，以船为中心是一条直线，也更吻合船东的操作。
所以，最终得出了这个公式，并设计成了这样的信息结构，以航程为核心，每一个航程附带上订单的结构。
最后的话
我始终认为产品经理的能力是通用的，不管业务怎么变，仍然是这套方法论，只是优秀的产品经理更加灵活，更加能够看到事物的本质。
更多相关阅读
如何设计大型B端产品？前人的经验，帮你少走弯路（上）
