背景：自身产品的数据后台，是上一任开发自己做的，没有产品设计，只是在需要更新某些功能的时候加进去，使用体验比较差，搜索交互反应比较慢。在这样的背景下，根据自身产品的业务，进行后台的重构，一方面是技术的重构，一方面是后台呈现框架和使用体验的重构，技术我不懂，所以我只是记录呈现框架和使用体验的重构。
一、思维技术坑
做后台功能列表脑图的时候，一直跟着之前的后台模型去走，思维被限制地死死的；画完一圈后发现，这样做无异于只是做现有后台做一些简化而已。在重新思考了一遍以后，根据“使用场景”进行了功能列表的优化。其实自身产品的后台大多数都是提供查询和设置功能，使用者其实是我们自己。因为之前的开发是站在自己的需要去做的，所以一些没有必要的查询字段，比如userkey，openid等都加入了。在细化功能列表到字段后，我也陷入了思维怪圈，认为他们之前有的就大多数是需要的，因为怕自己不懂技术会导致一些错误。其实不然，首先产品的使用者是我们产品经理本身以及一些同事，做到简单易懂就可以了，技术上的字段只是技术为了方便自己识别加进去而已，完全可以省略掉。也许这会回归到某个伪命题，就是产品经理到底需要懂技术吗？其实我的想法是需要懂一点点，不求能帮开发解决技术上的难点，只求不被开发忽悠。说不需要懂技术，其实大多数都是认为在设计的时候会被局限在能否实现的程度上。我觉得真实的场景可以是这样，设计的时候应该站在用户的角度去设计，比如在什么样的场景用户大致会做什么样的操作，我们需要什么样的交互，要先注重用户体验吧，实在难以实现最多就是退而求次优解。
二、信息分类坑
不记得在哪本书上看到有关信息分类的内容，在简约至上一书有组织策略，我个人理解就是信息分类。比如某个功能是属于查询功能还是设置功能，子功能里面有再包含了哪些子功能，是否每个小的功能之间有重复或者有不同属的关系。我想这应该是产品经理要避免的一个坑，因为一个网站或者一个应用所呈现出来的分类逻辑是否清晰易懂，会直接影响你的产品学习成本有多高等。但是这个目前为止，我也无法很快的掌握，目前我的死方法就是所有分类都列出来，再慢慢进行推敲，虽然这个方式消耗时间会久一点，但是思考的过程能让你看清楚想明白之前一些没有涉及的内容。在这过程中，我有因为某个地方用得多或者少，把其中某些功能单独提取什么的，但这样就完成破话这个框架逻辑，使得结构不够清晰，特别混乱。
三、设计坑
在这个后台的重构中，我这里所说的设计坑，不是指ui设计，指的是文案设计等。首先就是，文案设计必须要让使用产品的人都看得懂，不需要他们来提问等。我一直都认为自己文笔不错的，然而这并没有什么卵用。好用一般都是得在能用的前提下才发挥作用的。我老大说，像我业务参加这文深的人，都需要我去解释文案的意思，那我的文案就真的很失败了。文案必须要求简单简洁，要求别人一看就能懂。还有一个设计坑，就是排版。我曾经认为，只要排得整齐就行了，所以第一次设计的时候，我没有去考虑使用频率等相关因素，我就只是让他整齐就可以了。但是由于人的视觉习惯一般都是从左到右，从上到下，按照这样的习惯，你必须根据使用频率的高低去排序，而不是根据字多字少。根据使用频率大小排序，你可以避免在使用高频功能的时候，还需要接受低频功能的信息干扰。当然，你也必须在保证不对用户产生干扰的前提下，设计得整齐整洁。
四、项目跟进坑
一开始的时候，我在设计的时候加入了很多新功能，导致整个产品的开发周期很长。但是我们只是需要尽快把重构做完。但一开始我没有注意到这点，加入了很多功能，拖慢了开发进度。所以，作为一名产品经理，我觉得需要懂一点项目知识。毕竟你是要确保在什么时间点，完成什么样的开发进度。很多时候，你都需要把控开发进度和评估开发周期
目前来看，坑大概就是这样，可能说起来简单，但一切还是得靠自己慢慢实践去完善。知易行难，好困，之后有想到再补。
