B端系统设计是个“体系活”，侧重体系化建设。本文结合作者多年B端系统设计经验，从理流程，建模型，捋状态，画交互这12个字谈谈B端系统设计该怎么做，希望对你有所帮助。
B端系统设计是个“体系活”，相较于C端产品强调价值直给，在单点体验做到最优就可能做出一款好产品，B端产品则侧重体系化建设，健壮的流程和严谨的逻辑规则是系统运转的基石，产品外观及体验次之。
但是，一些刚入行的产品经理，或者C转B的产品经理，处理需求时习惯性的会先画原型图，所见即所想，但这么做往往会导致流程短缺、逻辑不闭环等问题，尤其是对于复杂的业务模块，更加需要成体系化的系统设计思路。
这里，结合个人多年的B端系统设计经验，我认为再复杂的B端系统设计，都离不开这12个字：理流程，建模型，捋状态，画交互。
B端系统的设计起点，是从梳理业务流程开始。坐下来，和业务方一起，在具体的业务场景下将一条条业务流程挑明理顺。
具体执行思路上，可以从角色、动作、约束、效果四方面去梳理业务流程：
（1）角色：人的角色或者系统角色。都有哪些人（系统）参与到流程中来，参与了哪些环节，角色是流程中最基本的元素，有了角色才有分工明确，才能有机协作。
（2）动作：流程中需要角色完成的业务动作。如销售人员完成一次leads录入、快递小哥去配送一个包裹，即角色按照业务要求完成具体的业务指令。
（3）约束：在具体的业务场景和状态下，产生的规则限制。如获取到销售线索后需在当天完成系统录入，如快速小哥需在3小时内完成包裹派送。同一个角色完成同一个动作，在不同的约束下可能产生不同的效果，如快递员在规定时间内妥投和超时妥投，超时妥投会额外触发扣款等惩罚措施。
（4）效果：角色完成动作后的效果。代表着下一步的动作，是流转到下一环节还是流程结束。这里注意一点是，产品经理要顺藤摸瓜似的多问业务方几个“然后呢”，防止业务流程有短缺，一步步追问将流程节点串起来直至达到End状态。
系统流程是业务流程中需要系统支持的部分，是代码实现的主要参考物。系统流程屏蔽了业务流程中纯线下操作的部分，保留了业务流程中人机交互、系统与系统间交互、系统与IOT设备间交互的部分。
划分主流程及其他流程的目的，是为了设定事情的主次。最先敲定的一定是业务的核心主流程，往往是业务心中所想的那条完美路径。
有时业务方会仅考虑了主流程就会来提需求，那么作为产品经理需要协助将业务方尚未考虑清楚的留白区填满，这里面就包括了异常流程、逆向流程和分支流程。
当操作者或系统未按原定要求执行时，系统或业务所采取的应对措施。如快递配送快递员始终无法联系上收件人怎么办，是原路退回还是原地保留，如果原路退回所产生的运费是否应由发件人承担等等，一系列异常场景和解决方案。
正向流程因故无法继续执行，而产生的反向流程，事件回滚/实物原路退回/资源释放等等。例如快递配送场景下收件人拒收包裹，从而快递公司将包裹逆向退回给发件人，属于实物流的逆向流程，可能会有一次逆向流程、二次逆向流程甚至更多等等。
在某些特定条件下触发的子场景流程。如用户在电商平台买手机，且选择了以旧换新服务，那么该快递在配送流程中，会触发第三方手机回收商上门回收手机，产生回收手机的分支流程，该分支流程属于主流程的一部分且在订单满足以旧换新条件下特定触发。
B端系统的业务建模，好比建造一所房子，在开始动工之前，必须将地基打好，包括确定房屋的主体结构（主数据）和关键材料（业务单据）等。上层稳不稳，全看地基牢不牢靠，所以，业务建模是B端系统设计中非常重要的环节。
主数据是能够满足跨部门业务协同需要，且能够反映核心业务实体状态属性的基础信息。在业务流程中，主数据属于底层的基础信息要素，是构建上层业务活动的根基。主数据相对于业务活动产生的业务单据而言，属性更加稳定，准确度要求更高，唯一识别。如CRM中客户信息、电商中的商品信息、协同办公中的员工信息、组织信息等。
对主数据的建模，是对组织中“人财物事”的抽象化设计。在对主数据进行系统设计时，应考虑父子对象关联关系、访问权限设计、数仓的同步方式等问题。
业务单据是业务活动中的过程产物和结果产物，存储和记录着业务的持久化信息和状态信息。如用户在电商平台购买商品，会产生商品订单，用户付款后会产生仓储用的出库单，出库完成后会生成各个环节的运输单等等。
业务视角中，业务单据是业务流程中的核心产物，是推动和管理业务正确执行的关键凭证，深入业务场景，提炼业务单据，驱动业务流程。
技术视角中，业务单据是库表设计的关键参考对象，梳理清晰单据的关键属性和单据间的关联关系，使系统方案在技术实现落地过程中更加顺滑。
B端产品好不好用不体现在华丽的产品外表，重要的是业务逻辑的完美实现，而业务逻辑最重要的组成部分则是业务对象的状态流转，业务状态流转驱动业务行为发生，业务行为发生又推进业务对象状态流转。
可以说业务规则最终实现准确与否，与状态机的设计好坏密切相关。
在B端系统设计中，一个业务对象实例是有生命周期的。设计一个业务对象的状态机，就好比去规划TA的一生。业务对象在其生命周期内，由人或系统来使其激活（起始态），随着用户的行为操作和系统的规则，推动其经历若干个状态节点（中间态），业务对象也会一次次被调用、被修改、被更新，直至其履行完一次业务流程的职责后，或主动或被动的下线（终结态）。
现态：是指当前所处的状态。
条件：又称为“事件”，当一个条件被满足，将会触发一个动作，或者执行一次状态的迁移。
次态：条件满足后要迁往的新状态。“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。
起始态：指最开始的状态，如「待付款」，一般只有一个起始态。
终结态：指状态机结束的状态，如「已取消」「已完成」，有可能有多个终结态。
我们以业务对象视角，构建状态流转的全生命周期，这么做的初衷是防止状态遗漏，而导致业务不闭环。所谓MECE，“相互独立，完全穷尽”，对于状态机设计来说，在枚举状态时，能够做到不重叠、不遗漏。这么做的目的是程序实现没有二义性，且能够覆盖全部业务场景，使系统准确无误的运行。
对于B端系统来说，在业务流程、业务对象建模和状态流转都确定好之后，方案就已经成功80%了，剩余的我们把产品的交互功能补充完整，方案就大功告成啦。
执行上，根据业务需求和产品调性，输出产品需求文档和原型图。
交互设计主要包括人机交互和系统间交互，并且B端系统设计实用大于一切。
B端系统的人机交互，讲究信息明确、页面简约、操作便捷、即用即走。
（1）便捷化：便捷化的操作体验可以让用户身心愉悦，便捷化的最理想情况是业务人员即用即走，用最短的时间完成规定的业务动作，便捷化的产品设计如各种一键操作（合并多个操作步骤）、智能记忆、表单自动填充等。
（2）简单化：简单化分为交互的简化和流程的简化。交互的简化是指替用户排除不必要的信息干扰，使信息要素以直白无争议的方式呈现给用户，可以参考John Maeda的《简约至上》，书中有介绍一些实用的设计方法和工具；流程的简化指的是去掉重复的流程，合并相似的流程，避免在业务流程和产品操作层面产生浪费，如审批流下放等，需结合实际业务场景进行流程梳理，请注意先穷举再删减，避免遗漏。
（3）傻瓜化：想用户之所想，通过数据采集、分类、标注等，提前预测用户下一步行为，并提供参考信息辅助决策，代替用户去做信息收集、整理、判断的事情，如智能调度、智能客服等；
系统间交互包括系统间的接口调用、执行顺序等，这部分设计方案往往以时序图表达更为清楚，强调接口的调用关系和依赖关系，研发也更易理解。
需要注意的是除主流程外，在前期将一些异常情况和极限值处理逻辑梳理清楚，将大大降低接口联调的时间，否则可能会出现「写代码」→「联调」→「发现不对」→「改代码」→「再联调」→「再改代码」的窘境，严重影响工期。
我们做任何事情，都应该挖掘本质，抽离规律，以不变应万变。
在面对业务的变化、职场的变化、人生的变化，仍能从容应对。
一技傍身，不惧人生风雨！
专栏作家
打伞遛狗，公众号：打伞遛狗，人人都是产品经理专栏作家。B端产品专家，沉淀产品知识，输出实践经验。
本文原创发布于人人都是产品经理，未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。