B端产品设计指南04系统建设与设计.pdfVIP

B 端产品设计指南 4.系统建设与设计 我们现在进入到系统建设环节，真正开始设计一款产品的形状了。在这之前， 我们先探讨一个问题：B 端产品和 C 端产品在产品设计上有什么差异性？ 绝大多数 C 端产品的设计逻辑会把用户体验与效率放在首位。追求极致的 简单好用与高效。在整个产品设计上比较侧重用户的感受，精心打磨页面与交互， 尽量少让用户做选择，保持产品的易用性与流畅性，都是做 C 端产品设计的不 二法门。 但是做 B 端产品时，所有的产品设计都是为“流程”服务的。体验和效率未必 是设计的重心。很简单的一个例子就能明白，企业买一款中介 CRM 产品，不是 为了让业务员更轻松，做业务的时候更“省事”，而是为了将整个卖房的流程管理 起来，做标准化的经营，为经营决策提供更准确科学的决策。B 端产品更多是通 过计算机技术实现企业的信息化管理，对企业流程进行优化升级，从而达到降本 增效的目的。 由此可以看出来，做 C 端产品更注重对“人”的理解，要求产品经理具备同理 心，感知用户的能力。而做 B 端产品更注重对“业务”的理解，要求产品经理具有 系统性的逻辑思维，富有理性地对企业业务进行全面梳理与诊断，给出合理有效 的解决方案。 在规划产品原型的过程中，产品的信息架构设计是重要一环，其中菜单结构 设计、CRUD 原则与 RBAC 模型的应用，可以帮助我们设计出更合理、高效的产 品形态。 菜单结构设计 常见的菜单结构设计有两种，以“人/物 ”为主线 ，或 以“事”为主线 。 大部分 的通用型 B 端产品由于各行各业的垂直差异性，无法做到统一的流 程管理，而产品需要满足尽可能多的行业，因此只能以“物 ”为主线划分菜单结构。 例如将 CRM 系统划分为线索 、客户、联 系人、公海 、商机、合同等等 ，都是以 “人/物 ”作为划分 的标准。 这种划分方式在一定程度上来说是有缺陷 的，因为在实际的业务流程中，物 与物之间的传递有可能交错 ，例如在房产交易、确权 、归档 的几个环节中都涉及 到合同的流转 ，而这种菜单结构没有充分体现这种流转 的特点 ，同时不同岗位的 职责权限也有可能交错在一起。 而专注于垂直行业的 B 端产品则往往 以业务流程的职责划分为菜单划分 的 标准，也就是以“事”为主线 的设计方式 。这种设计方式 的好处是可以有效的避免 重复和混乱 的现象 ，对整个系统的架构都是非常清晰 明了的。 CRUD 原则 在互联网 ，各类互联网书籍都提到过 CRUD 原则，也就是将新增、删除 、查 询 与修改等操作合并成一个管理页面。例如一个订单管理页，包含 了新增订单、 删除订单、查询 以及修改订单信息等不同的操作 。 但是在很多情况下 ，一个 ERP 系统中，录入订单是由业务员录入的，后续 由销售人员更新订单的信息。当发现退款时，由财务或售后人员撤销订单。由此 可见这些所谓 的“管理”操作往往 不是由同一个角色完成 的，如果合并在同一个管 理页面会产生很多职责权限混乱 的问题。好在现在越来越 多的产品也意识到这个 问题，在菜单设计上尽量避免使 用“某某 管理”这样 的字眼 ，而是根据业务场景 ， 更灵活地划分菜单的范围 。 上面这段话 的意思，难道说 CRUD 原则是错 的？其实并非如此，只是 CRUD 原则对于系统创造 的东西才适用，例如管理系统用户、管理数据字典 、管理权限 这类 的东西就适用该原则。对系统用户的增删改查 ，通常都是由管理员操作 的， 这个时候我们把这些操作都放在同一个界面就是合理的场景 。 RBAC 权限模型 B 端产品的权限 设计通常都是适用 RBAC 模型，也就是每个用户都要被赋 予一个或 多个系统角色 ，每个系统角色都对应一个明确的权限集合，包括对菜单、 页面元素等资源 的访 问与操作权限 。建立 一个“用户——角色 ——权限 ”之间的对 应关系。 此时，用户与角色 ，角色与权限 都是多对多关系，即一个用户可以对应多个 角色 ，一个角色可以分配给多个用户，一个角色具有多个权限 。当用户比较多时， 可引入用户组 ，既对用户分组 ，将角色与用户组进行关联 。