昨天晚上，本胖子做了一个奇怪的梦，我梦见自己，和自己组里的另外两位射手座同事，一起被老板笑嘻嘻的成功开除。我想了一下，决定听着罗大佑的歌，总结一下近期产品心得，以表示对自己业务能力的鞭策，和对其他人业务能力的态度。

   职位细分是必然趋势，也是入行门槛降低的直接原因。

   刚开始，大家做网站的时候不太讲究视觉和排版，写代码的人搞个差不多，可视化就得了。那时候的工程师都是适合那个时代的小全才，自己写代码自己做交互自己做视觉。后来发现网站太大了，做不过来，得有专门的人帮忙做做前端，所以有了美工。再后来，人机交互更加复杂，面对的用户更加慵懒和白痴，不得不让可用性更加简单易用，就有了专门做交互设计的人。再再后来，发现一个事情被拆分成了设计、前端、编码、测试、运营、维护很多阶段，臃肿的环节导致效率和质量的下降，人员增多导致话语权的分散，产品方向乱七八糟，所以就有了项目管理和产品经理，甚至有了傻傻的用户研究专员这种职位。

   现在，盯着36KR看一个月的人，就敢说自己是做产品经理的。盯着socialbeta看一个月的人就敢说自己是做运营的。盯着UCDC看一个月的人就敢说自己是做交互设计的。大家因为可以仅仅在自己这块领域瞎忽悠，而不必去担心其他环节的事情，所以也就对自己的专业技能和眼界降低了要求。一个做交互的不懂视觉和产品，一个做运营的不懂视觉和技术实现，一个做技术的不懂需求和视觉，结果大家配合起来，就是一群乱踢皮球的傻逼。一个问题，被踢过来踢过去，谁都自以为然，乱七八糟，累死了项目经理。

   前段时间面试应届生，发现满嘴专业术语的学生比比皆是，真落实到逻辑、需求、设计上，整个人就很容易犯二。这很正常。大家认准一个职位，就在这个职位里混一混，进一个好公司容易，混出好产品，就看后期的潜力和造化了。

   总—-分—-总，这也是必然趋势。

   真正牛逼的产品，最终还是需要各个环节融会贯通的人参与其中。不要奢望仅仅技术牛逼，或者设计牛逼，或者运营牛逼，就能做成或升华一个产品。虽然一个产品被划分为很多环节，各个环节按照呆板的流程也可以配合起来，但其实任何靠谱的团队，关键环节的关键角色，必然是对其前/后相邻环节非常熟悉的人才。我对这类人才怀有敬畏之心，常年采取跪式服务，仅仅传达需求，绝不敢讲解需求。仅仅商议方案，绝不敢说明方案。但交给这类角色，从初稿到终稿，也就一两回合就搞定。

   也就是说，一个越是流程细分、环节明确的项目，就越需要对各个环节了如指掌的通才，这类人是润滑整个项目前进的关键角色。对于这类角色的人选，产品经理自然首当其冲。

   在做单纯的交互设计时，别只盯着当前界面的可用性。真正好的框架设计，可以通过框架的整体逻辑，让用户有效的降低学习成本。我最近在看一个兄弟团队的产品，一个触屏界面上的同一个位置的按钮，竟然会变化三次，而且三次的功能完全不同。单个界面来说，这个设计的可用性无与伦比，整体框架上却完全无逻辑可言，完全凌乱。如果你在动手设计之前，有能力把一个需求翻译成一个轻松而单纯的二叉树，然后再从简入繁，那你就算在单界面的易用性上没有建树，至少也是一个架构师。如果你做不到这一点，那就把姿态放低，听别人为你诉说一个更加全面的产品故事，而不是抓住自己那点可怜的逻辑不放。

   在CODING的之前，如果你能扔掉自己在编码方面的多年所学，像一个傻用户一样，将一张张界面在脑海里串成一个完整的使用流程，那将会大量减少与PM之间的软磨硬泡，大量减少因为需求不明而导致的无谓的BUG。我对任何身怀编码技术的工程师都怀有敬畏之心，但如果面对的又是产品感强烈的工程师，总感觉他们总会是下一个mark，而不是坐在旁边听我指挥的同事。

   无论如何，对前后环节要心怀敬畏的情况下多想一些。如果做不到，还不如转行。

   谈一点实际的，做设计的时候，看的远一点。

   面对产品上的问题，最可怕的回答莫过于“这是老板让我这么做的”。这是圣旨，我面对这种事情也不知怎么办，只懂得诚惶诚恐的侍奉主子。我肯定还不如别人，甚至可能直接拜拜。

   除了以上这一点，其他时候，在动手设计前，应该看的远一些。我欣赏逻辑，这并不代表任何事情都需要带上逻辑的脚镣才执行。逻辑是一种内化的能力，如果你可以，不谈逻辑也罢。如果你不行，就套上逻辑的方法论再动手。

   逻辑的手段，不仅仅是把一个事情搞清楚，更重要的是把一个事情搞简单，并且后者更加重要。二叉树是技术上简单但很少用到的逻辑结构，但在产品上，如果能让一个人机交互过程，通过单线无交叉的逻辑顺序组织起来，单纯从框架设计的角度，这一定是成功的。在这个基础上再去考虑单个界面的用户体验，才是一个做事情的顺序。

   我最讨厌别人拿着一个狭窄的理由来驳斥一个全局的概念，而如果执拗不松手的抓住这种站不住脚的理论，才更加让人无奈。前段时间，吐槽其他大公司的环节明确、流程清楚，各个角色特别的各司其职，也正是因为这个原因。这种体制是用来混日子的，但却很难在产品方面胜出。

   框架设计方面，目前阶段，我大概可以为自己总结这样几个原则：

   1、拥有清晰的单线逻辑，即N叉树结构。

   2、N叉树结构的任何单个叶子节点，与其他所有叶子节点，在需求和功能上不能有明显交叉，否则就需要合并或重新架构

   3、在1和2的基础上，仅在必要的叶子节点之间做索引的交叉，以满足单界面的用户体验

   4、每一个叶子节点所代表的功能，尽量用同一套视觉和交互表现。

   如果以上几个原则做不到，这个产品需求再靠谱，设计上也是一个失败品。

   有层次，并且每一个层次具备唯一性的交互流程，以及一致性的视觉传达，能够让使用者快速的完成学习过程，并形成记忆，这才是一个优秀的设计，通过整体的设计提升用户体验、降低学习成本。

建议继续学习：

1. 基于人性的七种网络商业逻辑    (阅读：1707)