后台产品设计踩坑指南（一）

敲下键盘回想入行以来的经历，为啥我入职的公司，后台都是我负责？

以前还好，强行接活，还能主导前端产品设计。现在的工作厉害了，没有前端需求！！！

先让我静静...

设计过的后端产品

接触过设计过的后端产品包括：内部协作工具，电商中后台，教学管理系统。

内部协作工具：是为了解决前端销售人员和后端开发、设计人员的资源分配而产生的。

注：公司内销售和后端对接的业务流程单一，但是项目数量较大，经常出现资源分配撞车，优先级不分等等情况。

电商中后台：中台提供帮助商家查阅订单、上新、发货等；后台是运营人员管理资源位、配置活动（秒杀）等业务的工具。

教学管理系统：因市场需求而生，纯B端需求。

产品设计流程

上面三类刚好都不太一样，就分开讲一下：

内部协作工具

涉及人员：

销售、开发、设计（产品经理 = 我）

背景：

该产品是我真正设计的第一个产品，也是一个因为设计失败而失败的产品。刚入行的我，冠以UI设计师的Title，光荣的接下了人生第一个产品任务。

工作流程如下：

流程补充说明：

1、虽然我是业务流程中的一员，但是也只是其中一员之一，沟通的意义在于了解整个业务以前是怎么流转的。

2、上系统肯定是有目标的，这个目标是使用系统操作人的，也是老板的。

3、用的人只关注自己，设计师不行。

4、评审的一部分作用是甩锅。

坑来了

原则上，产品经过确认及开发和测试的话，上线应该是没有问题的。也确实，产品上线没有遇到太多功能性BUG，但是最后产品还是无法推行使用。

因为这里犯了一个业务之外的错误：角色权限设计错误

常规的后台产品会通过配置：页面、功能确认来管理用户可在后台操作的范围。

而我第一次设计系统，虽然有角色的概念，但是我的设计逻辑是：给账号绑定固定的业务权限。当业务流转到某个节点后只能让系统配置在这个节点的人进行操作。

也就是说，我将页面、功能权限完全交给了代码，而无法通过后台界面快速配置。

造成的结果：

1、有的成员其实拥有多个角色身份时，无法灵活变更，实际使用过程中需要重复换账号。

2、新需求来了之后，由于业务的耦合度太高，提升了设计和开发成本，且新增的需求所涉及的权限也是一个坑。

一号坑：产品设计

这坑算是经验的坑吧，因为缺乏对后台产品的认知，导致设计过程做了许多错误决策。

系统设计时，除了考虑业务流程以外，系统本身也需要做一些功能来进行配合，所以多看看其他系统如何设计的，减少踩坑几率。

如果你对我踩过的坑有兴趣，关注一波吧~