IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

N叉树和人性光辉

劣松.良品 2012-11-05 22:12:43 累计浏览 3,642 次
本机暂存

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同分类推荐文章

  1. 对基本有序的序列排序算法 (2026-06-11 17:46:49)
  2. Four Levels Of Customer Understanding (2026-05-22 21:00:00)
  3. 除法的意义 (2026-04-12 20:52:17)

查看更多 算法 文章 →

建议继续学习

  1. 红黑树并没有我们想象的那么难(上) (累计阅读 21,494)
  2. 为什么算法这么难? (累计阅读 12,397)
  3. 浅谈MySQL索引背后的数据结构及算法 (累计阅读 11,904)
  4. 加州求职记 (累计阅读 11,562)
  5. 海量数据面试题举例 (累计阅读 11,114)
  6. 基于Redis构建系统的经验和教训 (累计阅读 10,522)
  7. 谷歌(Google)2011年校园招聘笔试题 (累计阅读 9,574)
  8. 浅谈redis数据库的键值设计 (累计阅读 9,354)
  9. 关于使用STL的红黑树map还是hashmap的问题 (累计阅读 8,875)
  10. 再谈“我是怎么招聘程序员的” (累计阅读 8,792)