产品设计是一个比较大的概念，方方面面都需要考虑到，简单一句话可以概括---心中有格局，眼里有像素。管中窥豹，可见一斑，产品既要对市场有用，又要事无巨细，让开发设计人员清晰逻辑、功能、甚至要面对一个像素的改变带来的影响。可以说，产品经理先是面对的是一个系统的设计，然后是协调资源实现设计的大设计过程（暂不议开发上线后的一些运营干预手段）。
心中有格局的事以后慢慢说，今天总结一下“眼里有像素”的坑。PRD文档越清晰、细致越好的问题就暂不表了，除理应完善好的文档之外，以下错误排名不分先后发生过，错误也只是在某个场景下时错误，转个身大概就是进步，记录引以为戒：
流程不清晰或过于繁琐。产品设计中一个重要的转换，就是把需求转化为功能的过程，然后把这个过程流程优化好，所谓优化，最直观有效的方法之一就是简化流程，按照奥卡姆剃刀定律，如无必要，勿增实体，某些情况下想当然的为获得用户的使用频次，不加节制的增加功能入口之类的行为。
使用场景过于偏僻。犯了过度拟合的错误，为某一个特定场景下的操作投入了大量的时间精力，最后没有人用，带来挫败感。一定是前期缺乏用研，或者是自欺欺人想当然也可能是看到竞品做了，没有考虑到自己的实际状况，就拿来做了。累死三军啊...
不重视文案，前后不一致。这个虽然不是大的错误，但的确是工作不严谨的表现，记得一开始测试同学屡次提出为还不以为然，实在惭愧。原因大概是在快速原型完成后没有复盘检查，比如同一个文案pc端叫做分类，移动端叫做类别。以后一定要复盘检查文档中加一文案内容对应表之类的附件。
同理心不够。由于前后文案不对应，测试同学不爽，自己不以为然，表明自己同理心敏感度不够，不能设身处地的站在开发人员的角度看待问题。开发人员所遭遇到所有的非技术型开发中断问题，都是我的问题。
需求前后不搭，造成无法落地或者改动过大。没有什么需求是空降兵，空降带来的后果是两个独立的需求，根本无法融合，驴唇不对马嘴，尤其是改良性需求一定要与现有的产品相契合，以现有的产品为基础，确保落地。
设计功能外，业务不明确。评审的时候需要把功能和业务联系起来，可以允许一是的不熟悉，但一定要及时补上。比如，做一个分类的功呢，本身功能很简单，下拉选择返回，但是这个时候你要不要把业务梳理清楚呢？分类一，分类二明显显得你的没文化，也许你觉得这不是你该做的，觉得分析业务问题是别人的事情，但是没有人做的话，只有你来做。
妄想用户体验一次做到位。没有什么事情是一撮而就的，尤其是提升用户体验这一块，大多在成熟产品线上，MVP产品更需要拿捏好“做对”和“做好”之间的分寸，在争取时间和人力资源这一块很考验情商。如何做好用户体验？我们说这是一个好问题，但我没有一个好答案，你所看到的都是一个平衡取舍的结果，或者说各方妥协的结果。
关键数据的来源卡位不准或不严格。尽管有一万个不想得罪用户的理由，作为规则制定者，不得不说有的时候一定一定要卡住位。比如作为一个平台，标准商家的入驻，哪些数据需要严格把控，才能确保另一方给你玩，玩得转。往往有的时候，为了先进来，就放低了标准，也就成为了无效数据，前面的努力与付之东流，可惜。
为个例做需求或需求改动。就像设计，是对大众的设计，艺术是小众，个人的情感表达，同样的，产品是满足一群人的设计，为个体做改变，不能说不对，总之还是要商榷的。如果非要一个标准的话，那就是：看情况。
与团队成员当面沟通少。当面沟通是效率最高的，信息损耗最低，一开始的时候比较看重文档，评审一次改一次，文档修改好了，开发人员在评审过程中也是了然于胸了，文档的可用性大大降低。