关于B端系统的产品设计
过去的一年，负责的业务主要聚焦于平台运营，随着业务模式的成熟，也负责建设了许多营销系统。
本文将以此前实际设计的案例与大家分享 关于B端 系统的产品设计。
关于系统，个人认为是将 无序、散乱的业务抽象成中心化、标准化的有序服务。 而中台则在系统之上再上升一层，将 系统的共性抽象成通用服务。
而中心化和标准化的动机又是什么呢？较高频的动机有三条：
1） 业务模式足够成熟
2） 高频需求重复占用资源，且不具备复用性。
3） 旧有系统耦合性强，延展性弱。
在企业的早期阶段，一些非高频的共性需求并没有可依赖的中台系统。为了迅速上线及满足业务的需求，大多会将其耦合于该系统之中。
但当其他系统有相同需求时无法复用，需要额外开发相同的逻辑。不仅重复消耗资源，后续的迭代难度也会不断提升。
通过需求分析所确定的产品定位，能够明确系统要解决的 核心问题 是什么。而梳理业务流程，则作用在 问题解决的深度。
理解业务流程目的是梳理系统架构，从而划分系统的边界。边界清晰能够让系统各司其职，专注于自身的功能，并尽量提供可复用的能力。
以抽奖系统为例，输出其系统架构：
对于抽奖系统而言，它应该专注于抽奖的规则，如：抽奖次数来源、中奖概率、限中次数等等。
对于抽出的奖品是什么，奖品怎么发放，应该由奖品管理、奖品发放系统去消化；而奖品发放所触发的触达则应该交由触达系统。
什么时候应该将非核心需求抽象成中台系统，什么时候又应该耦合呢？个人认为应从其需求频次、强度以及投入产出比考虑。
在梳理了新系统与现有系统的耦合关系后，下一步则是确认中心化的对象，中心化的方式不同，其核心逻辑、功能框架也会不同。
以奖品管理系统为例，其中心化的方案可以有两种，如下图所示：
方案1以奖品作为中心，一个奖品将能够被多个业务方所使用。因其层级较少，产品、技术设计会更为简单，后续业务方的操作也更为轻便；
而方案2以奖品池作为中心，每个奖池的奖品相互独立，虽然方案更为复杂，但优势是其数据相互独立，更有利于成本核算以及风控。
当中心化的方案确定，系统的的核心逻辑及数据模型也就初见雏形了。
梳理功能框架相信大家都非常熟悉，本小节主要描述最小单元。 最小单元，指无法继续拆解的功能，其通用性的强弱也决定着系统的延展性 。
以下将以前端配置化系统为例和朋友们分享，以下的示例分别是最基础设计方式，以及有赞和笔者的设计方式：
1）固定组件、固定配置
第一种做法，是最基础的做法。它的思路是对固定的组件进行固定的配置。
以抽奖活动为例：
上图的两种抽奖玩法对应着两种前端样式，左侧是九宫格，右侧是老虎机。这两种样式对应着头图、抽奖模块、我的奖品及活动规则四个组件。
根据它们组件的共性，我们能抽象的最小单元是页面头图、页面底色、活动规则、抽奖按钮的颜色、文字等内容。
由于共性不足，它们的最小单元已经无法延伸。当后续增加新的模板“大转盘”时，我们就需要再次抽象并迭代，这种设计方案是非常不灵活的，而且最小单元很可能会再次减少。
最小单元共性越少，延展性越差，后续开发的工作量越多。
从九宫格的“我的奖品”、老虎机的“活动规则”来看，它们属于各自的私有属性，原则上而言我们也能够设计成配置项，但从投入产出比、延展性来看显得不太划算。
2）有赞：多种组件、独立配置
有赞的设计思路也是比较常见的设计思路，它的每个组件拥有独立的配置项。
上图分别是有赞中拼团、砍价组件对应的配置项，在图片的红框部分是商品模块的配置，同样是自动获取商品类型，拼团组件的配置项比砍价多了一个排序规则。
这种设计方式的优点是该组件能够很轻易的适配业务方的需求，灵活性能够达到最高。缺点则是组件的特性没有办法复用，某个商品模块或按钮的特性是无法复用到其他组件的商品模块或组件之中。
结合了上述的两种设计思路，根据实际业务方的诉求，笔者设计的思路为：多种组件、共用配置。
3）多种组件、共用配置
这种方式的设计思路是： 组件由模板与元素组成，模板决定元素的位置，元素负责视觉及交互的配置。
元素指的是： 文字、图片、线条 ，它们是本系统的最小单元。
其拆解示例如下图：
商品组件由图片、文字元素及按钮组件组成，而按钮组件由线条元素及文字元素组成。
关于元素的拆解思路如下图：
通过这样的解构，元素的交叉组合能够形成不同样式的组件。
当业务方有新的特性需求，只需要迭代元素的属性， 一次迭代所有的组件都能够使用这个特性， 即避免重复开发也保证了其复用性。产品、研发及测试的工作量的也大大减少。
除了视觉配置，另一部分则是交互的配置，其拆解如下：
最小单元在实际的设计过程中，还应权衡投入产出比， 不应为了解构而解构。
数据统计，有两点建议：定义清晰、数据独立。后者与系统架构有关，由于系统之间的相互依赖，会有关联的数据需要查询。
个人的经验是让系统尽量只消化系统本身的数据，对于关联的数据可以查询数据源让核心系统做整合，最粗糙的设计方式则是直接跳转至关联的系统查询。
1）角色与权限设计
根据组织架构以及权责范围，系统的使用角色所对应的权限也不同，常见的权限有增、删、改、查以及审批流。
2）版本计划
版本的计划。可以是对完整系统的分版本上线，也可以是对业务的预估推测系统后续需要延展的功能，这会非常影响系统的技术设计方案。
3）交互设计及文档撰写
随着业务认知的提升、技能的熟练，产品设计的能力可能会达到瓶颈 。 近期的想法是，面向价值设置需求优先级，不仅是企业、业务，还有支撑部门和自己。
以前喜欢做有难度的需求，但难度却不代表价值，我想好的产品设计一定能 帮助业务方带来可视、可观的数据成果。
给多方创造价值，才能够自上而下的推动跨部门协作，持续获得资源以及成长。
这是《后台产品设计指南》系列文章的 第5篇 内容，更多精彩可以点击下方链接查看。
后台产品设计指南
弹窗是后台产品中比较常见的组件，本文会和大家一起了解下弹窗的定义，使用场景及相关规范。
弹窗是一种中断用户当前操作的组件，引导用户进行下一步操作。
弹窗包括模态弹窗和非模态弹窗，前者是指会中断用户操作，需要用户进行交互的弹窗；后者则是指不影响用户当前操作的弹窗。
弹窗组件可以看做由主体区域、关闭入口、遮罩层三部分组成。主体区域包括相关文案，操作按钮；关闭按钮一般在右上方；遮罩层是半透明的黑色，有些弹窗支持点击遮罩层关闭，和关闭按钮效果是一致的。
主体区域
主题区域的内容往往千差万别，但可以总结为提示信息类和引导操作类。
提示信息类主要是显示关键信息，用户只需要确认即可。比如toast提示，tips提示就是这个类型。
而引导操作类则一般需要填写内容，保存确认，会与其他数据产生交互。
关闭入口
弹窗中的关闭入口主要包括以下几种：
1.弹窗右上角，用户关闭弹窗一般都会点击右上角关闭按钮，所以要设计的尽可能的明显。
2.弹窗主体区域内，经常会和确认按钮一起出现，但并是绝对的。比如上面的弹窗截图就只有一个确认按钮，这里点击确认也会关闭弹窗。
3.遮罩层，在一些系统中支持点击遮罩层关闭弹窗，这个操作确实比较方便，但有时候也会因为误操作导致带来麻烦。可以通过存储草稿或者弹窗确认的形式来降低误操作风险。
4.ESC键，虽然很多人不知道或者不使用ESC键，但这个快捷键对于部分人来说确实是一个很舒服的体验，我们在设计弹窗时也可以考虑进去
遮罩层
遮罩层是半透明的黑色，具体的色值和透明度需要单独设计，过深和过浅的设计都会影响用户使用。
在后台产品多层弹窗是经常出现的，在设计中应该尽可能控制在2层以内。过多的层级会让用户困惑，不知道自己当前所处的步骤；同时过多的层级在程序处理上也会相对麻烦一点。
下面会列举一下常见的弹窗类型，基本上覆盖了后台产品中的各种使用场景。需要说明的是弹窗的内容没有固定的限制，是根据产品的功能来自行设计的，千万不能生搬硬套。
1.新页面一般用于比较复杂的表单操作，而弹窗适用于轻量的操作。如果内容较多，仍使用弹窗时可以考虑通过合理的分组，分步、排列来降序用户学习的复杂度。
2.弹窗的宽度是遵循一定的规范的，过大的弹窗在笔记本及低分辨率显示器上体验很不友好
3.弹窗内的文案内容也是有规范，这里推荐大家学习一下有赞设计语言系统，里面的很多规范都可以直接借鉴。
我们在设计产品时需要根据使用场景来选择合适的弹窗，同时要尽可能地满足交互规范和用户体验，保证用户操作体验的连贯性和数据的安全性。
在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。
1.利用poser进行角色创作的过程较简单，主要为选择模型、姿态、体态设计三个步骤，内置了丰富的模型, 这些模型以库形式存放在资料板中。
人物模型包括裸体的男性、女性和小孩，穿衣的男性、女性和小孩，无性的人体模型、骷髅、木头人。动物模型包括狗、猫、马、海豚、蛙、蛇、扁鱿、狮子、
狼和猛禽，在绝大多数情况下，我们都可以从内置的模型中选出创作某角库色所需的模型。
2.一个特定的角色造型都有特定的姿态和体态，poser的模型及构成模型的各组成部分，如人的手、脚、头等，都带有控制参数盘，通过对参数盘的设置，我们可以
随意调整模型的姿态、体态，从而创作出所需的角色造型。姿态一般是指人物或动物在现实生活中的移动方式以及位置移动的过程，而体态则是指人物或动物身、
体及其各部位的比例、大小等，对模型进行弯曲、旋转、扭曲。
3.必要时还可以输入其它工具设计的模型从模型库中移掉。对模型进行姿态调整时, 一方面可以结合编辑工具设置参数盘以获得某种姿态，另一方面可以将现有的姿
态赋予模型或再作相应调整。
