电商后台管理系统模板、跨境电商后台管理系统 收藏 0

电商后台设计：品类管理

商品作为整个电商平台中的核心，系统中所有的业务都需要根据它来展开，所以设计一套易用、可扩展的商品模块是非常重要的。文章从品类管理的基本业务出发，对具体的功能模块展开了梳理说明，希望通过此文能够加深你对电商后台设计的认识。

由于内容较多，我通过三篇文章来讲解一下商品管理中各个功能是如何设计的。商品管理中包含品类管理、品牌管理、属性管理、商品维护四个功能点，通过这四个功能数据的相互配合，才能完整对商品数据的维护。本篇我们先来聊一聊品类管理是如何实现的。

电商平台商品繁多，如果没有一个好的数据归类，无论对于后端维护人员还是前端用户的查找体验可以说是灾难性的，所以在商品维护模块中品类管理算是最基础的功能了。

电商平台中品类管理通常分两种：前端品类管理和后端品类管理，为什么会有两套品类管理呢？

• 当平台发展壮大的时候，平台上的商品非常的多，后端系统需要创建比较细致的品类对商品归类以方便精细化管理和数据统计。
• 前端为了活动促销，运营人员会根据当前热度或根据用户喜好不断的对品类做个性化调整，以满足推广活动，如果直接修改后台的品类，势必导致后端品类混乱，维护人员(通常由采购部的人来维护)无法识别商品品类。

基于上面两点，通常就会开发两套品类分别由运营人员和采购人员各自进行维护，即不会相互影响，又实现了各自的业务功能。

要了解前端品类的功能，JD、TM肯定是我们必然要参考的对象，所以我们还是先看看他们的品类都有哪些功能，下图是JD官网首页的分类展示，我接下来分析一下功能：

电商品类大大小小几百种，一个好的组织方式无疑能够让用户更快速、更直观的了解网站的业务内容，最常规的方式就是层级分明的树形结构。综合考虑到商品的细分程度和用户的体验效果，前端展示的品类一般都是三级结构。

由于页面高度限制和用户视觉效果影响，网站首页默认只显示一级品类，二、三级品类通常被隐藏，需要通过用户移动鼠标来进行触发显示。

由于默认只显示一级品类，但是又需要让用户对网站业务能有一个直观的了解，所以一级品类通常都是根据相似功能聚合多个品类一同进行展示，到二三级则为具体类目信息。

当然不同企业有不同的战略考虑，还是需要根据实际业务考虑，合理组织商品类目信息。

活动运营是电商平台的核心业务，而品类作为电商的一个重要搜索入口，前端品类会加入个性化的链接跳转，通过点击品类跳转到指定的专题页或活动页，以增加活动流量。

大家可以在JD官网上试试，将鼠标放在品类上，屏幕左下方会出现跳转链接地址，大体有两种形式：一种是跳转到相应的专题页中；另一种是跳转到搜索页中。

上面我们讲了系统需要设计两套品类管理，它们又是如何关联在一起的呢？这个问题其实也比较简单，在创建前端品类的时候，会有一个关联设置功能，运营人员可以个性化设置关联多个后台品类。如：办公 -> 笔、本子、册子

• ICON:为了美化品类的展示样式，前端UI通常会设计一些ICON图标进行优化，该功能手机端使用的比较多
• 排序功能：运营会根据活动热度动态来调整个别品类显示的顺序，通过后台排序数字可以自由进行维护
• 状态：控制品类是否展示在前端

功能整理：

列表页原型图：

列表页上的删除功能需要注意，当品类包含子品类时，父级品类不能被删除，必须要先删除完所有的子品类，以防止造成系统内部脏数据。

表单页原型图：

关联品类页原型图：

前端品类关联后端品类时，可以关联到任意一级，无须精确到最后一级。

对于后来系统来说，主要用于数据分类，功能相对较少一些，对于页面优化并没有那么高要求，所以跳转路径、ICON设置就不需要进行维护。

但是它有一个非常重要的关联属性功能，用于维护商品展示属性的基础设置，由于涉及内容比较多，我在下一篇文章中介绍。

功能整理图：

列表页原型图：

表单页原型图：

小提示：在展示树形结构数据时，当数据量比较少的时候(如系统菜单列表)通常会采用带有上下级折叠功能的样式进行展示，但是数据量比较大的时候，通常采用分页展示，不然单页面数据太大，经常出现卡顿现象。

作者：JackLiu；个人微信公众号: 扬帆去远航（ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

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

电商后台设计：审核流

文章结合具体业务场景对电商后台设计中的审核功能的设计逻辑展开了梳理说明，并对相关问题展开了分析，希望通过此文能够加深你对电商后台设计的认识。

在工作中有许多的业务场景都涉及到审核功能，如请假条、加班申请、采购单等。既然有这么多场景都在使用审核，那能不能将审核功能单独设计成公共模块进行复用呢？这个肯定是可以的，下面我就带大家来分析一下审核功能。

下图是一张常见的请假单申请单，如果我们根据操作内容来划分，可以分出两个区域：业务表单区和审核表单区。

• 业务表单区：业务表单区主要填写具体业务所涉及的内容信息。
• 审核表单区：审核表单区主要是审批人填写审核意见的区域，根据我们常见的审核单模板，可以观察到不同的审核单审批区域的可操作性内容基本一样，主要包含审核人、审核意见、审核状态。

审核中主要有两个角色参与其中：发起人和审核人：

• 发起人：业务内容的创建人，整个审核流程的起始，基本操作功能包括提交审核、取消、根据审核意见修改业务表单等。
• 审核人：根据业务内容完成意见评审的人，基本操作功能包含通过、驳回、撤销、填写审核意见等。

单就审核表单来说，它提供的功能相对简单，主要有以下几个：

• 提交审核：发起人针对当前业务发起申请进入审核流程，是整个审核流程的起点，通常由发起人手动提交，也有根据条件自动判断进行提交的。
• 通过：审核人根据业务内容做出的决策，满足条件则【通过】，审核流进入下个审核节点或结束。
• 驳回：与【通过】相对，审核人根据业务做出决策，不满足条件则【驳回】，审核流回到上个审核节点或起始节点。
• 撤销：审核人在完成评审后，在下一个(通过)或上一个(驳回)节点的审核人未作出评审前，可以通过【撤销】撤回评审意见，再次修改评审内容。
• 取消：发起人由于自身原因，在整个审核流程未完全完成时，主动取消了审核申请回到业务表单编辑节点。

串行审批主要是指当一个审核节点通过后，才能进入下一个审核节点。如果驳回，则驳回到上一个节点、或之前任意一个节点或者业务表单编辑节点。

并行审核是指一个审批节点同时存在多个对象可以同时审核的情况。当其中一个、多个或全部审核通过，才能进入下一个审核节点。如果驳回，通常其中一个对象驳回，就认为当前节点被驳回，其它的情况很少使用，如多个对象驳回、全部对象驳回。具体通过或驳回需要根据业务场景而定。

混合审核通常是指包含了串行审批和并行审批的方式。如下图中，整个流程是一个串行审核方式，而其中一个节点则是并行审批方式。

对于上面的几种方式分析后，可以看出，一个审核流通常是由多个审核节点组成， 每个节点内最主要的任务是找到对应的审核人并作出相应的意见反馈。

发起人在发起申请时可以自己指定需要进行审核的人，这种场景比较常见。主要优点是功能简单、灵活性比较高，缺点是无法形成标准审核流程。适用于那些对审核要求不高的业务，如请假单、迟到补卡、加班等。这样的审核流因为是用户自己设置，所以通常不会太复杂。

企业中还有许多审核内容因为其中涉及到了金额、以及保密信息，所以上面这种人为自定义的方式就不太适用，它们的审核流程通常都是固定的标准审核流，如采购单、合同等。针对这种情况需要设计一套标准审核流程，后期由技术人员或者产品经理进行维护。

除了审核人外，还需要根据业务加入更多的匹配规则，如:

1）审核金额：即当满足一定的金额条件后，才会触发对应审核人。如企业的采购单审核，当采购金额小于等于10000时，采购主管审核即可，当大于10000时，同时需要采购经理来审核。

2）动态确认审核人：上面我们总结了，审核其实就是找到对应的审核人，然后完成审核信息。审核人的设置有以下几种方式：

• 指定具体的人：在审核节点上明确指定具体的审核人。
• 指定具体的职位: 将节点设置成对应部门下的职位，当审核流进入节点时，系统动态的根据职位信息获取当前对应的人。这样设计可以保障职员职位变更后，新的职员可以继续审核，而不用重新修改审核设置。

3）消息通知：当审核进入对应节点的时候，给发起人和审核人发送消息通知，及时了解审核状况，通常由代码内部完成这个逻辑，功能不会体现在原型图上。

4）抄送人：消息发送给审核人和发起人的同时，也需要给指定抄送人发送一份。

下面是优化后的固定审核流原型图:

审核流列表页：

审核流设置页：

上面我们将审核设计成独立的功能模块，使用时可以通过下面几步完成调用：

1. 配置好审核流程审核信息
2. 通过标识码和反馈码调用审核模块的接口，获取当前步骤的审核人列表信息
3. 在业务表单页面判断当前登录用户是否在审核人列表中，如果在则显示审核表单，如果不在则不显示

以上就是审核功能所涉及的内容，欢迎小伙伴们在下方留言交流！

作者：JackLiu；个人微信公众号: 扬帆去远航（ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

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

电商后台设计：系统管理、菜单管理

文章对系统管理和菜单管理的设计过程以及其中的业务逻辑展开了讲解，主要适合从事互联网产品设计、技术研发以及产品运营人员学习。

对于绝大数后台管理系统功能管理应该是它的重点，系统中涉及大量的功能模块，能够有一个清晰的结构划分，无疑会提升员工的使用效率。如下图：

设计一个功能前，最重要的还是需求，了解清楚想要的功能，设计起来就会容易很多。导航的常见功能如下：

• 页面导航: 菜单最基本的功能就是导航作用，可以在系统内部或系统外部自由切换。
• 功能划分: 一个系统通常包含大量功能点，通过模块划分、层级结构可以更清晰的展示出系统架构
• 权限管理: 对于常见的门户网站来说，菜单最主要的功能就是起到快捷导航作用，而对于后来系统来说，除了导航功能，它还涉及到权限功能。因为后台中涉及到大量的业务工作，所以在不同中页面可能有多个操作按钮，而操作按钮无法单独存在，需要依附在对应菜单上的。

通过上面的对菜单功能的分析，可以整理出如下所需字段：

• 菜单名称：功能作用的直接体现方式
• 父级菜单：展示父子级菜单的层级关系
• 跳转方式：系统内部跳转还是外部跳转，参数值有：
• 站内跳转：系统内部的跳转，将URL设置为不带域名的相对路径(如:/user/index)
• 站外跳转：系统外部的跳转，将URL设置为带有域名的绝对路径(如：http://www.exp.com)
• 跳转路径：设置具体的跳转地址
• 新页面：跳转后的页面是在原始页面还是打开新的页面
• 页面操作：列举出所跳转页面内所有的操作功能，为后面的权限设置提供选项
• ICON: 页面美化效果(不同系统略有差异，有些使用的是图片，根据自己需求而定)
• 状态：导航功能是否正常使用，参数值有：
• 开启：正常使用中的菜单
• 关闭：已停用的菜单
• 标识码: 系统内部识别的唯一标识信息，主要用在页面权限判断上

列表页原型：

表单页原型：

上面对[页面操作]的设计做几点说明：

1. 上面我们分析了页面操作也会参与权限的判断,代码里面不会写汉字进行逻辑判断，所以功能按钮也需要设计对应的标识码
2. 一个页面中有多个操作按钮，只有具体到功能页面才会知道，如大部分页面都会有查看、详情、添加、编辑、删除功能，商品管理页可能还会有上架、下架功能，财务相关页面还会有审核功能，所以这个功能需要动态管理。

1. 跳转：页面跳转是通过<a href=”/>标签实现的，如果a标签中路径设置为相对路径，点击跳转时系统会在相对路径前自动添加当前系统的域名,如果路径设置为带有域名的绝对路径，点击跳转时则会直接跳转到对应地址，当后台有多个业务系统时或者跳转到

2. 标识码：当后台程序将数据入库后，数据库会自动分配一个唯一的ID，后期一些特定的判断我们会通过在代码中写死ID值来获取指定的数据。但是这会产生一个问题，开发时的测试数据库经常会进行人为数据删减，而生成环境的数据库是规整的，所以会产生看似相同的数据但是数据库ID值不一样的情况，而写死在代码里面的ID值是参考测试库的ID，最终导致功能上线后不可用。所以通常的解决方案就是加一个可维护的标识码，代码中通过写死标识码来获得具体的数据信息。这种方式在我们后期很多设计中都会使用。

3. 标识码编码:对于系统各个功能编码，不同人有不用的习惯或者要求，我个人对菜单的编码是给每个层级菜单一个两位数字，如果层级不够三级用零补齐；而页面功能按钮，根据字面意思翻译成英语, 如：

系统管理 [100000]

| – 菜单管理 [100100] 查看[get] 添加[add] 编辑[edit] 详情[detail] 删除[drop]

| – 组织架构 [100200]

消息管理 [110000]

|- 订单消息 [110100]

|- ….

4. 页面权限判断：当用户进入到对应页面，会先通过菜单标识码(标识码被写死在代码里)请求后台数据获取到页面功能权限列表，再在页面中根据匹配的功能标识码显示对应的操作按钮。如：用户进入【系统管理->菜单管理[100100]】, 接口则通过100100请求权限接口返回页面功能权限列表,如：[get,detail], 页面显示 查看、详情功能按钮。

作者：JackLiu；个人微信公众号: 扬帆去远航（ID:Jackai_liu)

本文由 @Jack 原创发布于人人都是产品经理，未经作者许可，禁止转载。

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

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com