产品系统设计案例（关于B端系统的产品设计）

本文目录

• 关于B端系统的产品设计
• B端系统用户体系的架构
• 企业管理系统交互设计的突破点
• 电商系统｜如何根据系统模块来设计产品

关于B端系统的产品设计

过去的一年，负责的业务主要聚焦于平台运营，随着业务模式的成熟，也负责建设了许多营销系统。

本文将以此前实际设计的案例与大家分享 关于B端 系统的产品设计。

关于系统，个人认为是将 无序、散乱的业务抽象成中心化、标准化的有序服务。 而中台则在系统之上再上升一层，将 系统的共性抽象成通用服务。

而中心化和标准化的动机又是什么呢？较高频的动机有三条：

1）  业务模式足够成熟

2）  高频需求重复占用资源，且不具备复用性。

3）  旧有系统耦合性强，延展性弱。

在企业的早期阶段，一些非高频的共性需求并没有可依赖的中台系统。为了迅速上线及满足业务的需求，大多会将其耦合于该系统之中。

但当其他系统有相同需求时无法复用，需要额外开发相同的逻辑。不仅重复消耗资源，后续的迭代难度也会不断提升。

通过需求分析所确定的产品定位，能够明确系统要解决的 核心问题 是什么。而梳理业务流程，则作用在 问题解决的深度。

理解业务流程目的是梳理系统架构，从而划分系统的边界。边界清晰能够让系统各司其职，专注于自身的功能，并尽量提供可复用的能力。

以抽奖系统为例，输出其系统架构：

对于抽奖系统而言，它应该专注于抽奖的规则，如：抽奖次数来源、中奖概率、限中次数等等。

对于抽出的奖品是什么，奖品怎么发放，应该由奖品管理、奖品发放系统去消化；而奖品发放所触发的触达则应该交由触达系统。

什么时候应该将非核心需求抽象成中台系统，什么时候又应该耦合呢？个人认为应从其需求频次、强度以及投入产出比考虑。

在梳理了新系统与现有系统的耦合关系后，下一步则是确认中心化的对象，中心化的方式不同，其核心逻辑、功能框架也会不同。

以奖品管理系统为例，其中心化的方案可以有两种，如下图所示：

方案1以奖品作为中心，一个奖品将能够被多个业务方所使用。因其层级较少，产品、技术设计会更为简单，后续业务方的操作也更为轻便；

而方案2以奖品池作为中心，每个奖池的奖品相互独立，虽然方案更为复杂，但优势是其数据相互独立，更有利于成本核算以及风控。

当中心化的方案确定，系统的的核心逻辑及数据模型也就初见雏形了。

梳理功能框架相信大家都非常熟悉，本小节主要描述最小单元。 最小单元，指无法继续拆解的功能，其通用性的强弱也决定着系统的延展性 。

以下将以前端配置化系统为例和朋友们分享，以下的示例分别是最基础设计方式，以及有赞和笔者的设计方式：

1）固定组件、固定配置

第一种做法，是最基础的做法。它的思路是对固定的组件进行固定的配置。

以抽奖活动为例：

上图的两种抽奖玩法对应着两种前端样式，左侧是九宫格，右侧是老虎机。这两种样式对应着头图、抽奖模块、我的奖品及活动规则四个组件。

根据它们组件的共性，我们能抽象的最小单元是页面头图、页面底色、活动规则、抽奖按钮的颜色、文字等内容。

由于共性不足，它们的最小单元已经无法延伸。当后续增加新的模板“大转盘”时，我们就需要再次抽象并迭代，这种设计方案是非常不灵活的，而且最小单元很可能会再次减少。

最小单元共性越少，延展性越差，后续开发的工作量越多。

从九宫格的“我的奖品”、老虎机的“活动规则”来看，它们属于各自的私有属性，原则上而言我们也能够设计成配置项，但从投入产出比、延展性来看显得不太划算。

2）有赞：多种组件、独立配置

有赞的设计思路也是比较常见的设计思路，它的每个组件拥有独立的配置项。

上图分别是有赞中拼团、砍价组件对应的配置项，在图片的红框部分是商品模块的配置，同样是自动获取商品类型，拼团组件的配置项比砍价多了一个排序规则。

这种设计方式的优点是该组件能够很轻易的适配业务方的需求，灵活性能够达到最高。缺点则是组件的特性没有办法复用，某个商品模块或按钮的特性是无法复用到其他组件的商品模块或组件之中。

结合了上述的两种设计思路，根据实际业务方的诉求，笔者设计的思路为：多种组件、共用配置。

3）多种组件、共用配置

这种方式的设计思路是： 组件由模板与元素组成，模板决定元素的位置，元素负责视觉及交互的配置。

元素指的是： 文字、图片、线条 ，它们是本系统的最小单元。

其拆解示例如下图：

商品组件由图片、文字元素及按钮组件组成，而按钮组件由线条元素及文字元素组成。

关于元素的拆解思路如下图：

通过这样的解构，元素的交叉组合能够形成不同样式的组件。

当业务方有新的特性需求，只需要迭代元素的属性， 一次迭代所有的组件都能够使用这个特性， 即避免重复开发也保证了其复用性。产品、研发及测试的工作量的也大大减少。

除了视觉配置，另一部分则是交互的配置，其拆解如下： 

最小单元在实际的设计过程中，还应权衡投入产出比， 不应为了解构而解构。

数据统计，有两点建议：定义清晰、数据独立。后者与系统架构有关，由于系统之间的相互依赖，会有关联的数据需要查询。

个人的经验是让系统尽量只消化系统本身的数据，对于关联的数据可以查询数据源让核心系统做整合，最粗糙的设计方式则是直接跳转至关联的系统查询。

1）角色与权限设计

根据组织架构以及权责范围，系统的使用角色所对应的权限也不同，常见的权限有增、删、改、查以及审批流。

2）版本计划

版本的计划。可以是对完整系统的分版本上线，也可以是对业务的预估推测系统后续需要延展的功能，这会非常影响系统的技术设计方案。

3）交互设计及文档撰写

随着业务认知的提升、技能的熟练，产品设计的能力可能会达到瓶颈 。 近期的想法是，面向价值设置需求优先级，不仅是企业、业务，还有支撑部门和自己。

以前喜欢做有难度的需求，但难度却不代表价值，我想好的产品设计一定能 帮助业务方带来可视、可观的数据成果。

给多方创造价值，才能够自上而下的推动跨部门协作，持续获得资源以及成长。

B端系统用户体系的架构

      在大部分业务产品、应用系统、后台系统的设计开发过程中，用户体系的规划与设计都是所有产品设计的第一步，一个良好的用户体系设计将会给系统用户体验提升带来极大的帮助。

      一般来说，用户体系是一套关于系统用户分类、成长、关系、社交等概念的融合体系，通过良好的用户体系设计，可以精准匹配用户需求，提供更好的用户体验。根据产品形态的不同，用户体系也大致可以分为C端产品用户体系和B端产品用户体系。

       C端产品是我们日常生活中使用最频繁的产品，通常的，它的用户体系一般包括个人成就、财富激励、社交关系等方面。比如360安全的积分兑换，微博的会员成长体系，QQ的勋章，小红书的等级体系；分别代表了用户成长体系、用户激励体系、用户增长体系、用户运营体系等常见的C端用户体系。

       C端用户体系的最终目的都是为了提升用户体验、增加用户黏性、激励用户行为，并服务于实现产品的终极商业目的。

       B端产品主要用于满足用户日常的工作、管理需求，所以常见的业务场景包括日常办公、资源管理、业务流转等；从使用范围及使用频次来看，OA（办公自动化，面向组织的日常运作和管理）产品应该是最常见且使用最频繁的产品。所以下面以OA为例来讲述B端产品的用户体系。

       每个人在OA系统中都有自己的账号，所有人的账号整合在一起就形成了整体的用户群，也就是用户管理模块；而每个人又属于自己对应的部门，这个时候就形成了部门群体，这是部门管理模块；每个部门中不同的人又有不一样的职位，每种职位就形成了不同的角色，这是角色管理模块；每种角色又有其不同的工作权限，如业务审批、工作协同等，这就形成了权限管理模块。所以，用户、部门、角色、权限等模块就构成了相对完整的OA产品用户体系。

       B端产品的最终目的是满足用户的日常工作管理需要；一款好的B端产品首先肯定是一款简单易用的管理工具，其最终目的是为了提高工作效率、降低管理成本、维护数据安全。在这里，用户体系扮演着极其重要的角色，正是用户体系中的组织结构、权限管理的实现才是应用系统的人员管理、业务流程、数据安全得以保障。在B端用户体系大框架之下，针对不同的产品，我们也会设计不同的用户体系，以反映每种产品面向的用户群不同。

       C端用户体系一般采用会员等级，账户升级等方式来构建用户体系，业务场景较少、逻辑简单、流程相对标准化；而B端会使用“系统管理员”、“普通用户”等角色方式来构建用户体系，因为其业务场景复杂，多角色对应多种业务场景，流程差异大；不同的行业不同的客户，需要不同的专业解决方案。

        B端产品的用户体系主要包括用户、部门、角色、权限等主要组成部分，它们之间相辅相成、相互作用，共同构成了一个完整的B端产品用户体系。比如我们可以创建不同角色，而每个角色又可赋予不同的权限，然后将每个具体的用户关联不同的角色，使得用户获得所关联角色的权限。
下面还是以OA系统为案例：

B端产品：OA系统

场景：市场部员工A需要请假，填写请假单申请至上级审批人员处，每级审批通过后完成整个请假审批的流程。

涉及角色：部门员工——发起请假申请

                  部门领导——初步审批请假单

                  行政——终审请假单，记录该员工请假情况

       在上述场景中，涵盖了用户体系的四个部分，用户、部门、角色、权限；从员工填写请假单到一级一级审批的过程可以看出不同角色的工作内容不同，这也就形成了对应角色的权限。OA的用户群体是公司所有员工，根据员工在公司内的部门职位不同，需要通过权限结构区分出可进行操作的公司事项有哪些，不可操作的事项有哪些。

       清晰的职级工作权限区分，也就是让权限与每个职位的职责关联，可以避免办事无法找到相关处理人员，工作事项审批混乱的情况，使得公司可以井然有序的进行日常工作。

       由于一个公司不可能只由一个部门组成，所以在角色与用户之间还需要加入部门。部门将公司事务根据不同部门实际情况划分每个部门的事务及形成对应工作流，对于同属于多个部门的用户可以灵活的处理相关部门的事务，可以让用户无缝处理各项事务，不用时刻记住自己在处理哪个部门的哪件事务。

       用户在一个部门中，有对应的角色，在不同的部门中可以拥有不同的角色，同时用户所拥有的这个角色的权限会限制在当前部门的操作权限内。在进行某项事务时会进入对应的工作流。

用户：是最小粒度的系统使用对象，每个用户在系统中都有唯一的账号。

部门：公司每个部门都是独立的，根据组织架构进行构建部门结构；上述场景涉及市场部和行政部。

角色：根据公司事务的划分与参与事项人员的职责区分，设定不同的角色，上述场景中为普通用户、部门领导、行政人员。

权限：将每个事项可操作的功能作为一个权限，都个可操作功能组合可形成权限集，也就形成了角色的权限。
       在了解了B端产品用户体系的每个组成部分后，再来看一下B端产品用户体系的关键点有哪些

       要设计适合一款B端产品的用户体系，关键是需要弄清楚这款产品的主要需求和面向用户群。通过权限控制可以对这些需求与用户进行关联，权限控制贯穿整个产品。通过对角色和权限的设计，可以达到或灵活或简化的用户体系。

       在产品创建的初期，一般不会直接对产品的权限设计的非常清晰，在设计开发到一定程度后再来考虑权限部分，但是会在一开始决定产品用户体系是灵活可配置还是简单易用，在角色与权限的使用上做出选择。一种简单的用户体系，可以将角色和权限直接进行管理，每个角色对应的功能权限与数据权限在系统创建之初进行设定，且后期不能直接调整权限范围，但是可以通过一个用户关联多个角色的方式实现权限调配。另外一种更复杂而灵活的用户体系，是将每个权限独立开，区分数据权限和功能权限，实现角色对应权限的配置，这样就可以把用户、角色、权限分离开，使管理更加的方便和灵活。随着后期业务的扩大，职能权限进一步细化，灵活配置方式能够带来更多的益处。这两种用户体系都有其优点与不足之处，主要看对整个产品的展望以及未来走向的把控。

      总而言之，我们该如何根据不同的产品设计用户体系呢？首先我们需要了解产品的商业目的，商业目的决定了用户体系的结构。然后是明确用户需求，用户是要达到操作功能的明确区分还是数据权限的使用限制。最后要根据产品的工期等情况，在用户体系的灵活与简版上做出取舍。

企业管理系统交互设计的突破点

关于这个交互设计的方法，我来谈谈的见解。其实打造企业管理系统并不难，难的是如何让它拥有长久生存的能力，所以优秀的企业管理系统交互设计就成为了一个突破点。
:busts_in_silhouette:用户维系问题
一个问题是与用户的维系问题。随着时间的流逝，用户也会逐渐流失，流失的原因主要有两种，一种是三分钟效应的用户，用户无法找到产品的亮点，或产品无法解决用户的问题，这是产品自身的问题。另一种是用户在某个特定时段没有需求而被搁置，这种情况需要不断运营让用户在需要的时候想起产品。
:man_technologist:用户体验入手
在维系用户问题上，除了从产品入手就是从用户体验入手，在合理限度内为用户提供尽可能好的使用体验，这是打造良好用户体验的重要方面。
:bar_chart:数据结构复杂
数据结构复杂，流程长、节点多就是企业级系统的特点。这些系统都出生的比较早，而由于早期的技术条件的限制，界面设计、交互设计的框架都比较老旧。
:eyes:界面设计和交互设计
以今天互联网的审美来看，像SAP、用友金蝶这些产品的界面和交互简直都不足为提。如果大家有机会去看看国内医疗行业HIS系统的界面，保证你会好几天都不想吃饭了。
:straight_ruler:整体局势排版整洁明了
总之我认为在这个问题上主要还是要注意，整体局势排版整洁明了，一定要简洁！简单！切忌复杂！如果简洁和明了都不能兼顾话，放弃了简洁，因为人员流动性可能较大，简洁不明了就意味着更高的培训使用成本。
:link:B/S链接目标页
还有B/S链接目标页也就是点击进入页面的次数不能大于三次！
:chart_increasing:速度和高效率
其次一定要注重速度和高效率！切忌拖延症！
:bar_chart:数据高度集成
最后便是我们的数据一定要高度集成！注意这里！一定要高度集成啊！

电商系统｜如何根据系统模块来设计产品

系统化的产品经理逐渐在变得越来越重要，并不是以前单纯的页面和交互来做产品，而是通过功能一步步延伸到模块，再从模块趋变于系统的架构。

当系统化变得越来越重要时，我们就应该思考怎么从大方向来思考产品，如何搭建产品架构？

我们可以回想：整体系统的搭建尤其是以电商系统为蓝本，产品肯定是要商业化，商业化就离不开电商变现，也就会涉及到电商管理系统。而现在电商后台的体系成熟化、完整化，对我们去理解系统本身都有很强的参考意义。

然而，每次逛电商网站，总有一大堆促销活动。加上现在移动端社交电商的崛起，拉新和促活就是变得尤为重要。可以说促销活动的多样化是日常运营的重要部分。

那么，其实我们在思考一下：为什么大家如此热衷于促销活动？

促销的形态是基于已有商品管理的角度上针对于商品进行有关联的促销形态展示。商品中心的展示就变得尤为重要，对应的商品SKU、商品类目和商品价格（原价、促销价）等有关商品的数据都需要有基础展示。

促销的方式有很多种，刚开始是把线下的促销形式搬到了线上，比如：满减促销、赠品促销、单品促销、多买优惠促销和定金促销等。

而现在的促销方式包含1元夺宝、秒杀活动、团购活动、拍卖活动、拼团等形态。接下来，就一一聊下这些形态的配置和展示形态。
B端商品经常会有批发模式，前端的展示：

通过模型描述：（针对单一的SKU形成组合，单一商品SKU和批发商品形成的“多对多”关系）

则后台怎么配置呢？

(1)批发商品列表（包含商品名称、商家名称、起订量、是否启用、产品审核状态和操作“查看、和删除”）

(2)和新增批发商品展示界面

字段1：批发商品名称是从商品列表中去选择。

字段2：批发商品分类是从商品分类中选择。

后续的字段：显示采购、价格模式（阶梯价格）、最小起订量、库存和商品属性都是和批发活动对应的字段。

由此，可以看出：“商品样式——促销类型——用户关系信息”三者形成了促销体系对应的内容。当然这个只是针对于单一的批发促销方案，若为o2o商城，可以分为自营和商家对应促销管理。
优惠券是电商产品中最常见的促销方式，无论是产品在哪个阶段都是最有效的促销手段。优惠券的整体模型为：

优惠券的基本展示样式：（当然这只是一种展示样式）

则后台的配置和设置：

（1）通用券（主要针对于商品面值和使用门槛，以及每人限领张数），若商家发放的 同样可以添加指定商家等

（2）同样购物券（场景主要是针对用户购买商品后，给用户返的优惠券）

主要增加了用户获取优惠券的门槛（购物满XX元和允许参加的会员，允许参加的会员就需要和会员体系打通）
拼多多是拼团活动的集大成者，规则是指定数量的人一起购买某商品，可以通过比较低廉的价格获得此商品。

拼团的逻辑为：

前端的基本展示样式为：

那后端的开团列表为：

和新增拼单开团：
拍卖方式一直都有，只不过应用在商品中的样式还是比较少的，这里稍微的介绍下：

前端展示样式：

后台需要创建拍卖列表：

对应的拍卖商品的和新增：

当然这儿只列举了这几种优惠促销的方案。还有很多种优惠促销的方案，后面可以一起聊聊。

总结一下：

作者：John，一个不知名的产品狗，公众号：产品狗聚集地。

题图来自Unsplash, 基于CC0协议。