N叉树和人性光辉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以上几点能够做到的前提下,还需要好的单界面设计,才能让产品有性格,或极客,或简单,或华丽,这些不是逻辑原则能达到的,而是执行人本身的人性光辉的体现,而人性光辉,就只能靠斯巴达了。

 

到底是博客,还是社区?

一次针对轻博客发展方向的探讨,仅作记录。

到底是博客,还是社区?

其实,这个产品没有一个本质或者唯一的答案,不能将其百分之百栓死在一个定位上,所以,绝对是博客,或者绝对是社区,或者绝对是媒体,都不正确。同问,豆瓣是书影音工具还是社区?微博是媒体还是社区?大众点评是查询美食的工具,还是挖掘草根力量点评美食的社区?无论说是前者,还是后者,都不能绝对。

轻博客朝着社区做?还是照着博客做?其实可以换一个问法。

有些人,把它当纯粹的记录工具来用。有些人,把它当做官方信息发布,对外宣传这个链接。有些人,不仅当做博客,而且展示作品给其他人,与其他人互动交流。那么,我们考虑一下,以上几种用法,哪一种对我们更有价值?或者说,对产品更有贡献?

  1. 发布内容,自说自话,内容没有消费价值
  2. 发布符合产品气质的值得消费的内容
  3. 热衷于消费别人的优质内容,随着各种互动,建立站内关系

对这几种用法逐一分析:

  • 只有1,对产品仅限数据价值,可替代性强。
  • 只有2,对产品有数据价值及内容价值,可替代性强。
  • 1/2/3,对产品有数据价值、内容价值、关系价值,轻博客对其不仅是工具,而且是带有关系群体的社区。

当做社区用的人,是产品的early adopter,产品早期来说,这类人对我们更有价值。他们为产品创造内容,将产品中的用户连接起来,建立关系,并吸引周围更多人成为用户,帮助他们建立关系。

所以,我们不妨换一个问题,现阶段,我们为哪一类用户做产品?答案必然优先是1/2/3,为early adopter做产品,从而辐射到更大的人群。

哪一些人,对于当前的产品来说,是真正的early adopter?

机构或媒体是吗?不是,他们的功利性和距离感,让普通用户没有理由,因为他们的存在,而长期留在该产品。短期留在产品当然有可能,但短期,没有意义。

只顾自己宣传,没有社区关系和互动的牛博是吗?不是,他们虽然是个人,但其仍然带有功利性和距离感,将他们的阅读者或粉丝哄到自己的博客当中,短期可以,长期则无效。

只有那些真正在博客中建立关系、记录东西的内容产出者,才具备成为early adopter的必要条件,即1/2/3并存。

补充解释:

  1. 功利心重,不玩儿社区只发内容的牛人来到这里,吸引了10个人到来并关注他。
  2. 社区太小,仅仅10个人,不能满足这个高不成低不就的牛人,所以牛人离开,停止发布。
  3. 关注他的10个人,有5个是没有需求的脑残粉,果断离开。另外5个,虽然没了牛人,但依然有点儿需要这个产品,所以留下。
  4. 那么这个牛人发挥了5分的作用。

问题是,有多少牛人吸引的用户里,有高达50%的目标用户?

为什么,产品当前阶段,带有功利性,或者带有距离感,就不能成为early adopter?

功利性,在产品用户量不多的早期阶段是满足不了的,一方面功利性使得博主的经营方式不够贴近其他用户,另一方面社区内人太少,满足不了功利的目的。

距离感,是功利性催生出来的现象。距离感决定了此人在社区中无法建立双向关系,无法建立双向关系,就完全没有意义。

总结一下上面的结论:

  1. 将某个发展初期的轻博客产品绝对定位在某一个单一的方向上,都是不够严谨的。
  2. 现阶段,应该为“像社区一样使用轻博客的用户”做这个产品,即为early adopter做。
  3. 当前阶段,功利心重、无互动、仅发布的机构或个人,都不是我们的early adopter。
  4. 既然是用关系来吸引用户群,那么,这个产品必须优先为用户关系服务。危害用户关系的事情,暂时做不得。