B端后台产品设计复盘

当时的设计流程

我们如何整理的需求？

上级与中博沟通，我们也去中博展厅参观，了解中博的现状以及需求。然后整理了一份带有优先级次序的需求列表Excel。

用户需求转化成产品需求

使用Xmind，整理了我的产品结构。整了还挺久的，这里花的时间过多了，完全可以使用更少的时间去做。从8月7日到8月16日，才整理出个产品结构，tm逗我呢。我觉得这个一天就够了。此外在此Xmind上没有标明优先级，这里也是不到位。 要注意的是整理的粒度。我觉得结构图就和权限配置表保持一致就行了，具体到页面与操作就行。 到这里为止，我都是在闭门造车，因为我还有和另外两人耦合的部分，我的部分数据来源来自运营后台；我需要支持云眼和小程序的功能；当然，这部分不需要但是后面具体落实的时候，还要考虑数据的流通，要兼容现有小程序产品，要打通。

产品需求落实到原型

我整理了后台原型元件库，所谓必先利其器。 我对一些基本功能没有在意，比如注册登录，直接拖了组件，没有思考其中逻辑。这导致我要回头重新思考，后续的所有流程均有此问题。 先构建整个页面目录，所谓先整体后局部。案例库优先级比价高。因此从此动工，但感觉不从账号角色这部分入手始终觉得切入的点不对。下手之前先整理了案例库的结构，不同案例的属性等，然后与领导确认，方便下手。然后就是落实，画完之后发现大红子那边也同样有这块内容，并且我们俩不统一，给到开发测试预览的时候他们反馈非常激烈。问题出在我们，队内没有沟通好，为了解决这个问题，领导组织会议，将任务按模块划分，将案例库划给大红子，但是各产品负责人要保证交互统一，依旧对各端负责。另外，案例库这块，对空间这个概念，我不是很赞同，这个功能想要达到的目的非常棒，我们也很需要，但我实在是认为我们没有实现这个的能力，因为做产品不是做功能，是做系统，做完后还需要丰富内容，还需要考虑用户会不会这样做。虽然不认同，但少很难说服多，就先妥协了，反正多包括少，不碍事，降低优先级，做不完就砍就行。但其实我应该坚持一下。 整个过程中，了解了相关sku、spu的知识，另外很意外的收获，一个就是我们常说的底层、上层的概念，我终于理解了。第二个和底层相关的，一个库的概念，案例库里面包括最底层的户型图库，上一层是效果图库，再上一层是云眼和小程序上调用这些库。举一反三，还有店铺库、分部库等等。

然后是开始规划账号，最底层的东西。账号和权限这块完全是初次接触，所以先查阅了一些资料，了解了RBAC（Role-based access control），以角色为基础的权限控制。对此有了一些浅薄的理解，然后就开干。理论归理论，实干时还是很难理出其中关系。光角色这个概念，系统账号的设计将非常混乱，我陷入了迷茫，后来在角色之上又想出了角色类别这个概念，可以用这个先对角色类别进行区分，角色类别就划定了权限范围，这里了感谢同事，她有提到过这个，帮助很大。据此，将角色分为两种类型，平台角色和店铺角色。平台角色不经营店铺，管理店铺；店铺角色是店铺中的角色，经营店铺。 null 在账号这块还遇到另外的几个问题。

账号删除问题。删除后如何处置，这个版本我没有处理，先不做删除功能。
角色删除问题。这里我调研了有赞，他们账号基于角色，但只是把角色赋予账号，角色删除后不影响账号使用。我又问了仓哥，他们的设计是角色下的账号删除完才允许删除账号，我觉得这更加符合账号时角色下的账号这种设定，所以就采用了这种做法。
账号管理。平台除了要管理自己组织要用的账号，比如总部客服、总部技术这些，还要管理下属分部、下属店铺的账号。这里必须区分开来，不然账号将非常混乱，所以我引入了账号类型这个字段。有此字段做区分，可以用不同tab显示账号，自己用的和下属的就会很清晰。
同样的，在做账号体系时，没和公司运营后台的一起交流，所幸没出大问题。

然后做分部管理和店铺管理的设计。这部分主要负责店铺与分部的生成与管理。理清楚该有的字段，就差不多了。其中有些地方不是太满意，一个是添加店铺的地址的交互，那个地图的交互觉得不是很友好。另一个生成店铺或者分部都需要填写负责人的信息，然后会自动生成负责人的登录账号。我这边没有考虑太多，在编辑分部的时候，店铺负责人编辑店铺的时候，直接把字段复制过来了，导致店铺编辑店铺信息，还可以直接编辑账号，后台我就在编辑中删除了这个字段，只允许编辑基本的店铺信息。账号在账号设置中修改。还有一些遗留问题，比如现在分部所属上级不可以修改，因为还没考虑清楚修改后他的下属如何处理的问题。比如店铺和分部都不可以删除，因为没考虑清楚删除分部后下属如何处理的问题。

预约订单基本没问题。

设备管理问题很多。这一块由运营后台产品负责，她会考虑得很全，将功能做的很强大，但是我觉得是高射炮打蚊子。做的过分完整了。所以我优先级标低了，先不在B端后台中做。

PRD产出

第一次写后台产品PRD，觉得和移动端差异非常大，移动端我会写大量交互部分的东西。后台我会觉得没必要写这些，但是我当时又没时间理出一个很好的格式，所以这个在后面使用一个统一的格式吧。以用例方式组织就行，交互以注释方式写在旁边。我设计的数据字典表很管用，一份表格，一份在原型页。这里在考虑是否直接去掉表格版的。多地方同步是一个大问题。还是都保留吧，只要留下更新时间，对比就能确认是否为最新。表格毕竟好分享能集中查看。操作权限表、数据权限表都非常有必要，我觉得做的不错。有些地方做的不好，流程图画的太少了，在做哆来米项目时，每个用例，我都会画流程图，那样会让业务、产品都非常清晰，这个在后续要注意，好习惯要保持。

产品交付给开发

里面涉及评审和把原型交给开发。评审我觉得将的不是很容易懂。这里只能说自己需要再理清楚，逻辑链条更加强一点。

开发中

开发中开发会有很多问题，比如这个地方不好实现；这个地方不合理；这个地方你们产品之间没沟通过吧，不一样啊；我通常非常妥协，因为本来时间就要求紧，不敢做过多要求，终究还是不够自信，没有魄力觉得这样做才是正确的。产品力上来了，也就可以解决这个问题了，每个问题考虑清楚，可以说服他们。

有变动的地方要做变更明细，放在原型最上一页。此外对应的Xmind、数据字典、原型都要及时更新。