移动IM中消息已读的情感拿捏

微信根本没做消息已读

易信做了已读,自动开启,可以手动关闭

来往框定一种消息类型,叫重要消息,接受者必须点击阅读,发送者可以获知对方已读与否

当前短信“信息已经到达对方手机”的信息回执,是否有必要?

如果移动IM产品的定位中,包含了“取代短信”的朋友沟通的定位,甚至把其视为一种基础定位的话,由此推理,让用户成为信息发送的首选渠道,将是最重要的产品诉求之一。为什么用户将某信当成首选渠道?这其中最基础的心理需求,一定是:通过某信发送的信息,对方能够最大概率的收到、阅读并回复。整个产品都应该为用户塑造这种“信息首选发送渠道、发送后最大概率被阅读并回复”的产品预期。假设技术上,只要网络通畅必然可达,那么产品上应该如何塑造?

最直观的的手段,似乎是当年短信的做法,告知我“信息已经成功到达对方手机”,这种做法是在帮倒忙。首先,APP的环境下,由于APP通知设置、APP是否安装等因素,这个信息到达对方手机的通知,其安全感本身已经打了折扣。更关键的问题在于,是否需要让用户为“信息是否已经成功到达对方手机”的问题而揪心?不需要,甚至不需要主动提起此事,应该让用户形成“发送成功,就必然包含了信息抵达的结果”的安全感;如果多此一举的告知用户信息已经抵达,那么用户长期的心理诉求,就会逐渐引导至“收到信息抵达对方手机的通知”才算发送信息成功的暗示,这种暗示对于产品本身,是多余的,且无法被利用的。

如何最有效的为用户塑造“通过X信发送信息则必答,必最大概率被阅读”的心理预期?

只有一条路,扩张用户直至全民标配的感觉。用产品功能的手段去解决,只会让用户对预期不断加长、加深,既形成了功能依赖,非看到对方已读才放心;又产生功能反感,不想回复的信息,让对方知道自己已读而不回复是很抵触的。而这种依赖和方案产生之后,产品将不再有更好的解决手段。

微信不做是对的,只要无限扩张下去,变成短信替代品,自然会完成信息发送首选渠道的任务。

易信不该做,做了还默认开启,是给自己挖了个坑。

来往的做法,成本略大,但是规则上比较巧妙。我用的还不多,目前感受下来,也有一种重要消息被对方绑架的感觉,用起来多余且别扭。

【短】美其名曰:给设计空间

入行以来,见过最傻逼的职位,莫过于少数入行两三年却仍然没有提升的交互设计师。这些人做问卷、市场调研、建模、数据分析…………一堆的技巧,结果做出的判断和思维方式,从头到尾透出一种入错行的感觉。

交互设计中的各种工具只是手段,交互设计师不是用手段工作的人,是要尽可能的忘掉这些手段,而去专注在思考上面的人。如果连一个界面的信息传达主次都分不清楚,就让这种交互设计去指挥视觉,显然这位交互和被牵连的视觉,都应该理所当然的成为炮灰。可惜的是,大部分傻逼给出来的辩词,依然是“PM这个臭傻逼,应该给予设计足够的空间”。而且还理直气壮。

在错误的方向上给设计发挥的空间?呵呵呵呵呵呵呵

配合过的交互七八个了,靠谱的就俩,但不知道自己不靠谱的,全都是。跟PM,一个德行。

N叉树和人性光辉

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

总结一下近期的产品心得

好久没有认真总结最近的产品心得了。积累了很多主题,都在高强度的工作节奏中磨没了。连书都不看的懒人,如果再不养成总结的习惯,就TMD的完蛋了,就变成垃圾产品的产品经理了。

完蛋问题1:慎用设计手段解决需求问题。

发现产品中出现的问题之后,产品经理的作用,最起码应该是把这些问题背后的需求发掘清楚,翻译给大家和自己。交互设计师的作用,则应该是根据需求层面对该问题的解释和衡量,提出对应的解决方案。但真实情况是什么样?有时候,项目紧张,没有条件和时间做完整的用户调研或测试,几个人一起拍脑袋决定,几个拍脑袋的人却都不靠谱。有时候,需求模棱两可,竞品分析一下其他几个产品的做法,然后东施效颦,几个被拿来分析的产品却都不靠谱。

这些都不可取。可取的是,要么,最终以百分之百的理由说服自己;要么以低成本、低耦合的方式进行快速试错。要清楚的跟进,不能糊里糊涂的上线。

这里有一种误区,千万别被看上去还行的设计方案蒙蔽了自己。若需求都没想清楚,再贴切的设计方案,也是一种陷阱,造成功能越做越做的陷阱之一。

完蛋问题2:别为少数用户浪费太多精力。

听到的用户声音,基本都是那部分很喜欢主动反馈问题的少数派。大致听一听就行了。让不可替代的技术资源,去解决大部分用户需要的功能。至于如何判断某些反馈是否是大需求,产品经理的能力问题。

完蛋问题3:别因为华而不实的功能而忘记核心体验

如果是一个邮箱,再NB的容量和网盘功能,也比不上邮箱收发速度。如果是一个相册,再NB的相册模板,也比不上图片上传速度。先把核心体验做到极致再说,别被竞品花里胡哨的辅助功能吓到。

完蛋问题4:数据有时候不是那么重要。

如果不是电商或千万级用户量的产品,就不能拿数据来左右自己和团队的产品动作。一个深谙需求的合格的产品经理,对一个发展初期、相对简单的产品,应该拥有基本的判断力,来自产品经验和对该领域的直观感觉。数据应该发挥应有的合适的作用。

完蛋问题5:别忽视技术骨干的产品建议。

虽然技术男看上去基本上都窝在自己的电脑前,浑浑噩噩的拍着代码。但靠谱的技术,最解产品背后的数据结构和实现逻辑。产品经理将需求翻译成功能、提交给开发之后,最有可能节省时间成本、降低实现风险的环节,是跟技术之间的讨论。讨论新功能如何融入现有逻辑、以后是否拓展新需求进去。经常有眼前一亮的技术建议,让功能更加富有逻辑美感、更加节省实现成本。

换句话说,懂更多的技术、培养技术思维,产品经理就更容易NB和靠谱。我特别享受这一过程,跟工程师讨论技术实现方式的过程。

完蛋问题6:运营驱动产品的本质

真正靠谱的产品动作,来自于最前线的用户需求。用户需求不是靠用户自己喊出来的,是要有人泡在用户里面去发现才行。产品经理就得干这活儿,去运营。一个脱离运营,只做功能的人,基本是还只是交互设计师。

恬不知耻的说,这活儿也只能由产品经理来干,纯粹的编辑、运营,也没办法从运营中抽取和翻译出靠谱的需求,乱七八糟的1.0媒体、门户类产品就是典型反例。

总的来说,产品经理又不是超人,不可能躲过这么多陷阱、克服这么多问题。所以一个产品组,几个默契的产品人一起把关,比较稳妥。

避免过度设计:有所为有所不为

最近在产品的设计流程当中,融入了正儿八经的专职交互设计,反复体验着这种完整团队所带来的优缺点,虽流程完整,但细节困扰。其困扰之一,我感觉应该叫过度设计。
(呃,文章像大长今一样长~~看前做好心理准备吧。)

过度设计,一般是说技术开发中,对于逻辑复杂、技术先进的过度追求,导致了技术框架虽看似华丽却复杂难用。若说到产品功能及交互的过度设计,应该是“过度追求体验完美、需求满足”而导致的“实际体验下降 or 长期产品定位偏离 or 功能没人用”的悲惨结果。

为什么会导致过度设计?

原因1:一味追求体验

所谓大团队、多部门的互联网公司,在开发产品时,设计资源往往是产品部门无法把控的,一枚宝贵的设计师,往往曾经跟过很多产品,总是被派来派去,而不是长期跟进某一个产品。因此,再如何苦口婆心的为团队成员灌输市场情况、产品定位、项目目标,也不可能形成合作过程中的默契感。没有默契,就没有产品归属感,只有流程管控和死板的执行。

如此工作框架下的设计师,其首要目标很难与产品发展保持一致,而是要为自己的设计作品照想,要让这个产品中自己负责的设计部分,被他的主管认可、被主管的主管认可。这合情合理,天经地义。但是,他的主管,却与我们的产品很少有交集。这就是苦逼的开始。

在这个时候,设计师必然希望每一个设计细节都能考虑周全、设计完美,几乎希望摒除一切不好的设计,以在其老大面前证明自己的能力。但是,假如眼前这位设计师,没有眼观六路、耳听八方的强大能力和视野,则极有可能会被这种追求完美的设计思想所拖累,让一些设计细节走了样。

设计师挖空心思,拿出一份自认为近乎完美的作品,并苦口婆心说服所有人相信并执行,即使隐约感觉到不对,但乍看似乎完美无缺。推进到开发或上线测试阶段,真正的问题从走样的“完美设计”当中渗透出来,淋伤的则是产品计划,傻眼了。重新改、重新写代码、推迟发布。

这种过度设计,不止伤害团队和产品,还会浪费时间:

• 挖空心思的追求完美,比常规思路的设计,多耗时3天。
• 产品与设计师一起确认设计细节,在“非预想的设计细节”方面博弈一番,产品说“我没见到过这种设计”“开发和维护成本大,浪费时间啊”,设计说“这种体验确实是更好的”“那个竞品的模式真的很恶心”,多耗时1天,并且徒增设计师、产品的挫折感。
• 开发非系统默认的精致设计细节,多耗时3天。
1周,就这么浪费了。就是这样。

原因2:一味的满足需求

研究用户需求时很容易陷进去,然后被非理性所控制,假如自己没有足够的经验,而身边又没有靠谱的人提醒,就会有一堆本来不是需求的需求,成为开发任务,所以才有了后来滥大街的一句口号“产品减法”。最苦逼的是技术:“辛苦写好的代码,说减就减,TMD的当初都干嘛去了,一群SB!”我往往都随声附和,暗骂一声自己。。

以下两种常见的情况,会导致“过度满足用户需求”的问题:

一是对用户声音缺乏筛选。用户不是产品人员,其在使用产品时,提出的问题、表现出的困惑,一定是偏自我的感性意见。“我不认识这个按钮啥意思!”“我感觉全部展示出来才好看!”“这个功能特别不方便!”

二是对需求研究无法保持理性。“假如自己给自己评论会怎么样”“要告诉用户不能这样做啊,直接砍断不好吧”“用户想这样,然后在那样,然后在这样,就会出现困惑了呢!”“直接把入口铺出来,这样才最方便!”

总之,当在理解用户需求时,如果不能以一种正常、理性的心态推演使用场景,很容易被上面这种问题带到沟里,最终导致过度设计。(身边靠谱的产品人,多是理性起来不是人的射手座~~~呃)

功能以及交互上的过度设计,最终可以导致一系列后果:

1、浪费时间,延误甚至失去市场机会!
2、在过度设计的博弈中自我耗损,伤害士气!
3、过度设计的功能,看似华丽,却无人问津,白搞了!
4、最可怕的问题:过度设计的细节,导致错误引导,培养了错误的用户习惯,并且这一过程,不可逆!

第4个问题,有必要详细描述一下:

• 假如只是一个功能入口,入口A比入口B更加便捷,用户只会记住A,而忘记B。假如产品设计之初,希望用户在途径B时,享受更多的推荐或引导,那么B的这种作用就发挥不出来。而这个时候,再想删掉A,用户会骂死产品。若想修改A,则是动框架,耗费成本。

• 假如是一套用户使用流程,流程A比流程B更加舒适自然,但是如果没有考虑到A和B对于整个用户引导的差异,而草率的选择了A,那么这种用户引导的差异,或许会导致产品定位的偏离。(近期某款雷声很大的新产品,正是犯了此忌。)

如何减少过度设计的发生?只能对症下药。

不要一味的追求体验:

•  一是,让产品设计师更多的向产品靠拢,增加默契感,形成产品归属感,在做事情的时候便可以有效的规避不信任的细节争吵。

•  二是,改变不合理的“产品负责制和确认层级”机制,产品负责的归产品。这样才能在通篇考虑“市场、定位、时机、成本”的时候,做到相互信任和理解。只有让产品横空出世,整个产品组才能真正有所收获,而不只是通过一个设计作品来增强自己的满足感。实实在在的成功最重要。

面对需求,保持理性:

至于产品人,只能多犯错多磨练,让自己靠谱多一些。总之,在产品创意时不失感性,但在面对需求时应该保持理性。幸运的话,进入一个整体靠谱、左右权衡的经验团队,会让自己的成长方向更正确。


最后,奉上一张小图,偶见于某产品的动态首页~参不透。
总之,希望自己做到有所为,有所不为。
@劣松 文章地址:http://www.liesong.me/?p=344

乱谈手机客户端的设计

谈手机客户端的设计。接触才1周,我就敢谈~~整理一下思路,为以后鄙视现在的初级阶段做个铺垫。

抛开产品本身不谈,手机客户端要从几个方面综合考究,才能做出精彩的东西。手机端和WEB端,在很多方面是一致的,都要尽可能的把用户当成懒汉和笨蛋。在以懒汉和笨蛋的态度对待受众的基础上,再考虑不同手机平台用户的使用场景,让这种懒和笨发挥的更加贴切,就可以了。

如果在WEB端已经有了一个成型且比较稳定的产品,比如某电商平台、某社区,在此基础上做手机端产品,大致有章可循:

理顺功能框架——设计交互——确定UI——上手把玩儿

1、决定功能及框架

首先需要思考一个问题,应该如何决定一个手机客户端中实现哪些功能?两个维度:

维度一:产品的核心功能和用户对各功能的使用频度。

维度二:手机用户的使用场景

通过流程说事:

根据前提,既然已经有了成熟的PC端产品,和稳定的用户群,那么必然可以在当前的PC端使用场景下,淋漓尽致的勾绘出整个产品的功能框架、各个功能末梢的使用频度。

再完美一些,所谓成熟的稳定的PC端产品必然是有其核心价值,满足了用户们的核心需求。那么勾绘出的功能框架和各个功能末梢的使用频度大小,必然应该与用户们的需求一一对应,越是靠近核心需求,越是有更高的使用频度。

其实有经验的产品人应该对自己所做的产品了然于胸,不必勾绘什么框架,浪费时间。

好了,根据眼前的功能框架和使用频度,决定手机端必须要承载的若干功能,然后依次评价一下,这些功能是否是一个用户躺在床上、坐在车上、走在路上的时候,非常适合拿着手机完成的功能之一,即套用手机用户的使用场景。

没有必要必须在这个阶段就决定整个手机客户端的功能框架,前面说的只是一种态度,一种思维模式。按照这种模式走,然后拿出第一期功能方案即可。另外,手机客户端功能并不是越全面越好。功能全面与界面清楚、功能易用相比,后者优先级更高一些,即,宁愿少放一些功能,让用户用着爽是第一位的。

2、设计交互场景

交互设计这个方面,其实没有什么好说的。不同平台,有不同的交互习惯和规范,这是必须要遵守的。两个原则:一是,遵守不同平台的交互习惯和规范,甚至与同类产品的交互设计保持一致;二是,在一的基础上,与PC端在某些通用页面保持一致,减少用户思考成本;三是,,,,没有三,让有经验的交互设计师把关吧。

3UI设计

千万别让UI的设计盖过了功能本身,在PC端也是这个原则。UI是为功能服务的,是间接的为用户体验服务的。举一个简单的例子,新浪微博的WEICO版本和官方版本相比,其UI当然是高出几筹,但我用了几分钟就够了,因为我真的不想猜底部MENU中每个图标代表什么意思。问了身边的几个人,都感觉WEICO不如官方版本好用。再看官方版本的UI,基本上可以说是没有UI的。这就是功能易用性相比于UI的重要性,尤其在手机端。

当然,对于不同的手机端产品,UI的重要性也是不同的。但原则是,UI永远是为功能服务的。看看例子吧:

左边的新浪微博WEICO版本 VS 右边的官方版本:

1、官方版本右上角放置了与大部分客户端一致的刷新按钮。WEICO放了一个拍照~~~

2、底部MENU,新浪微博的图标设计也够清晰,并且还有文字说明。看WEICO版本的最后一个MENU项,我还以为是核反应堆的水温呢。

3、官方客户端对图片做了圆角处理,不知道WEICO为什么不做,难看。

该模仿的要模仿、该啰嗦的要啰嗦,手机屏幕就这么大点儿的地方,不要兼顾太多东西,也承载不了太多东西,优先照顾易用性。

左边的网易新闻客户端 右边的周末画报

两者都属于有一定内容组织的长篇阅读类客户端,所以阅读体验,是这个客户端的核心价值之一。看他们的UI吧,确实异常优秀。尤其右边这货,使用起来的感觉简直甚爽。从五个方面考究这两款货的视觉设计:

1、图片处理。如图~阴影、半透明文字

2、区块渲染。右边这货,有些渐变的矩形作为底色。手机客户端的区块要异常分明,因为用户跟产品之间的交流,区块是最合适的桥梁。让一个胖子用户的粗手指去点击一个文字连接,肯定让胖子出一身汗,老是点错。所以交互设计过程中,能用区块完成的,就用区块完成。

3、图标及细节。其实MENU中的英文注释根本没必要,只是为了装一些。右边这货的MENU和顶部TAB标签,做的非常细致、非常好看。那边角、那阴影、那进度条,很考究。

4、主题色。手机客户端的UI,如果没有太多能力和精力来做,其实是承载不了一个产品品牌的识别作用。主题色可用的地方不多,也就是顶部标题栏、用户名颜色、标题等重要文字颜色,所以首先还是照顾用户视觉上的一致性和区分度吧。

5、排版设计。尤其是注重阅读体验的客户端,好看的排版是亮点。

在一个小屏幕上做文章,空间有限,所以细节更重要,但其实经验更重要,体验一堆各种各样的客户端,慢慢的也就知道哪些地方用的不舒服、哪些地方做的很贴心。

最后,上手把玩儿,然后再反复迭代。

需求分析:解剖产品想法

产品人总会产生各种各样的新想法,这其中极少数“应景且靠谱”的想法会成为产品、惠及网民,而更多产品想法只会成为谈资、或博文素材,比如下文中的这片想法。那么,产生不应景、不靠谱的想法是不是错误呢?我认为不是,这种“产生想法——想法博弈——想法毁灭”的过程,对于一个产品新人来说,至少算是一种对互联网市场的猜想、对用户需求的分析、对产品策划模型的创造。关键在于,自己是否可以通过简单的市场调研、理性的需求分析,对一个自己中意的想法做一次解剖,洞悉其价值。这种解剖分析的过程,就是锻炼和成长的过程。

所以,我把以下这个想法拖上解剖台,按照“产生——分解——分析——实现——再回顾——评估问题”的过程,简单评估一下其应景与否、靠谱与否。

需求产生我在PC上阅读的时候,总会在某篇文章中发现一些“或拍案叫绝、或醍醐灌顶、或发人深省”的片段内容。每当此时,总希望轻松存储这些片段,以便收藏并回顾,又不会干扰阅读进程。提升一点儿档次的说法,即所谓的“知识管理”行为之一。

需求分解1、在PC上阅读,所以场景有可能是浏览器、阅读器、WORD等;2、阅读过程中存储片段;3、存储快速,以后可以阅读曾经存储的内容。

需求分析
层一:有用
●实施文字存储行为,并方便以后的回顾阅读;存储行为在阅读过程中完成,要求快速且便捷。

层二:易用
●网络存储:最好玩点儿云存储的概念,我走到哪里都可以把片段往云彩里塞、或从云彩里看。
●分类索引:分类、标签不能少,甚至注释、来源也可以有。一是方便我对内容的管理;二是说不定以后有大用处~~
●如何快速:“浏览新浪博客时,选中片段即可发布一条微博”——这种方式值得借鉴。在此过程中加入分类、标签、注释的交互过程,并淡化存储行为。造就一种“一片好知识,不知不觉已上云端”的完美感觉
●方便阅读:以某种方式让我舒服的阅读这些片段即可,比如网页方式。

层三:爱用
背景:满足了“不打扰阅读行为的快速存储、有效索引、便捷阅读”这一基本需求之后,我所积累的知识就会不断的往云端里塞啊塞。如果这个产品被我的100个其他同行使用,我们101为同好者就会不知不觉建立起一朵肥硕的云彩,关于某一类主题知识的云。
基于以上两行之背景,则会出现如下之场景:
●第一:所有知识均为用户筛选,基本全属于优质内容。
●第二:分类索引,让同主题的内容可以有效聚合,并含有注释、来源。
●第三:有了优质内容、主题聚合,分享欲望油然而生。我当然希望浏览同行们认可并收藏的知识片段。

需求实现:
现有工具:
●onenote、EverNote、wiz。试用了WIZ,索引及分类不清楚、存储有些迟钝。另外两个没用过,EVERNOET本身50M+,软件本身就够重的,有些麻烦。客户端嘛,最大的麻烦就是要安装和管理,一台PC一种情况,带不走。
●阅读器,比如谷歌。可以在有限内容源内收藏、分享内容,但其与需求本身还有着本质差异:阅读器,并非知识管理工具,不能对片段精华的知识进行有效的存储、管理、索引。

实现方式:
●客户端——沦为现有工具之列,加入竞争。另外,客户端+网页的方式,也加大了用户的理解和管理成本。内容源:可以照顾各种内容来源,包括网页、WORD等。
●浏览器插件——比客户端轻、比“下面的方式”重。内容源:比客户端缩小一圈,可以照顾所有网页内容。
●某阅读器文摘功能——最轻,内容源也最小,限于阅读器订阅的内容。有可能背离最初需求,沦为第二种“现有工具”。

最终方式:浏览器插件+云端存储+网页展示。

靠谱吗?回顾需求
 即,回顾最初的需求是否得到了很好的满足,应该从虚拟场景中判断,功能是否抓住了用户的痛点(分析用户需求:在场景中寻找痛点):
●场景一:我安装了浏览器插件,以后无论在网络中阅读到任何对于自己有价值的内容,均可“选中内容——选填标签、分类、注释,并自动记录来源——完成云端存储”。
●场景二:我若需回顾自己积累的网络文摘,便可以“点击浏览器上的插件按钮——打开网页——按照预设分类及标签阅读浏览”。
●场景三:承接场景二,我还可以在网页中“点击公共标签、公共主题分类——浏览他人产生的优质文摘内容——关注某用户及其文摘知识 or 点击文摘来源,直接到来源网页浏览 or ……”,社区形成。

问题:1 用户对于“阅读过程中记录精华、笔记类内容,并作为知识管理、回顾阅读”的需求有多强?2 由用户产生的“片段化的文摘、笔记类内容”,其可读性、可分享性有多强?
●第一个问题,决定了这个产品本身的“产生意义”。
●第二个问题,决定了这个产品“到底是做一个纯粹的知识管理工具,还是借用户产生优质内容之东风,做一个知识分享社区。”
 
解剖完毕。我对于这个想法的评估,最后简单归结为以上两个问题。当然,由于个人能力和阅历所限,我这种自娱自乐式的解剖,会在过程中产生各种偏差或偏执。所以,最好的方式,是邀请其他同事、同行一起围观解剖台,对自己的想法评头论足,以保证下刀精准、方向正确,从而让自己这次需求分析的锻炼过程,更具备群众智慧和参考价值。

总之我认为,产品人就是要不断产生想法,然后毁灭想法,再产生,再毁灭…………直到这种反复自我毁灭的过程中,拼杀存活下来一些惠及网民的好产品,自己也就可以欣然的修成正果、立地成佛了~
 
欢迎转载:http://www.lyingsong.com/?p=241  作者:劣松

如何看待新产品的“目标群体”

目标群体,相信每一个从业者对这四个字都非常熟悉,就像射手眼前的标靶,恨不得一击命中。对于一个还在构思中的新网络产品,目标群体意味着什么?
“意味着未来一切产品需求的归属:靶心;也意味着一切营销手段的能量:射程。”

那些靶心(一些网站的目标群体):豆瓣——热爱读书、热爱电影的网虫;图虫——专业摄影爱好者;网易尚品——买奢侈品的有钱人;51社区——真人社交……

目前,豆瓣依然是国内优秀的WEB2.0网站,其凭借源源不断的电影/音乐/图书资源,牢牢把控了以“书影音”为媒介建立起来的用户关系网络;图虫一直集中精力的为专业摄影网民优化功能,网站人气稳步上升;网易尚品则是门户试水电子商务的差异化途径,上线不久,但对手不多,应该会有不错的发展空间。而51社区的生存空间,则已经逐渐被人人网、QQ空间所挤压。为什么?

QQ空间有用户体量巨大的即时通讯做靠山,基本可以衣食无忧;而人人网,在其发展初期圈定的目标群体非常靠谱,即在校大学生。直到如今,人人网依然可以集中精力面向在校学生锁定需求、升级功能。直到这个时候,51社区的用户体量虽然巨大、特征已不鲜明,因此前途坎坷。除了51社区,新浪朋友、搜狐白社会、网易梦幻人生……类似的产品比比皆是,并不因为背靠门户就有流量优势,更需要锁定靶心,才能占得先机。

因此,面对目标群体,首先要考虑的问题则是:已圈定的目标是否足够聚焦,圈定群体是否能够持续产出并具备拓展潜力?
目标足够聚焦,决定了产品核心价值可以足够明确,用户的需求痛点可以足够鲜明;用户群体具备充分的持续产出内容的能力,则保证了产品内容更新频率,让初期运营专注于互动关系的挖掘和内容策划;呈现出专注而饱满的产品形态,便是新用户被吸引驻足的良好基础。

那些射程(一些网站的运营策略):美空——丰富的传媒、模特、广告公司资源,让网站的目标群体有效聚集;新浪微博——名人资源,新浪博客打下的名流用户基础;即使是人人网,当年也是一个校园一个校园的拿下,营销过程并不轻松。

所以,当信心满满的锁定了目标群体,还需要扪心自问: 是否有足够的资源或力量,可以在后期的推广营销中将目标群体逐步纳入产品用户范围?
有时候,即使产品价值足够鲜明、功能足够完美简洁,目标用户也不会主动找上门来。当你确定了以名人策略作为盘活目标用户的切入点,是否意识到,名人买账吗?所以,初期确定目标群体时,最好盘点一下手中的资源和运营的能量,即使营销策略再给力,也要有能够达成所愿的人脉等资源才行。必经,网络产品等不得,不温不火的内测下去,是一种可怕的浪费。

有哪些方法可以帮助我们解答以上两个问题?
1、数据。如果拥有足够的数据挖掘能力,当然以数据做参考是最靠谱的。(目标群体指数,Target Group Index,可反映目标群体在特定研究范围内的强势或弱势;有助于明确目标市场,是设定目标时经常使用的主要工具。)
2、用户访谈。通过访谈,深入了解据别特性需求的用户群的具体情况:需求分析、上网习惯如何、同类需求的真人关系等等。
3、考察同类产品。寻找同类产品,或者能够满足同类需求的其他产品,看看这些产品的生存状态如何。
4、请教高手。站在一定高度的业内人士,可以给出靠谱的建议,当然,可遇不可求。

总之,圈定目标群体的过程,即反复求解两个问题答案的过程。毕竟,目标群体决定了产品价值,而靠谱的产品价值则决定了产品未来的发展路径,是否经得起需求的考验。(具体见文章:产从产品价值的角度体会“需求的减法”

欢迎转载:http://www.liesong.me/?p=205 作者:劣松

分析用户需求:在场景中寻找“痛点”

面对用户提出的需求,有时候经常感觉到千头万绪、无从下手,有时候又感觉需求本身就是答案、没有必要下手。面对需求分析这种事儿,就没有一个模式化的解决方案吗?没有答案,但却可以模拟场景:

场景一:一个朋友面临春运回家订票的强烈需求,准备通过电话订票,在千军万马中抢得一张回家的希望。为了尽可能放大订票成功的几率,朋友找我帮忙,让我帮他打电话一起订票。

方式一:抢电话线路~跟朋友一起打电话订票;

分析:海量用户同时拨打订票电话,电话堵塞。假设一万人在某车次放票时一同订票。朋友一个人电话订票,成功可能性为万分之一。有我帮忙,提升为万分之二,杯水车薪,哎….

方式二:抢通话时间~尽可能缩短电话订票的标准时间长度。

为此,认真研究了95105105电话订票的程序,在预先确定“车次、发到站、出发时间”的情况下,完全可以大幅缩短通话时间,从而抢得先机!于是,让朋友按照理想车次、理想席别做出排序,然后套用电话订票流程,最终为朋友提供了一套给力的订票攻略,如下图!

(IDEA分享:可以针对火车电话订票流程做一个网站,用户输入车次编号等内容,自动按照上图流程生成订票攻略,火车订票前后高峰期,或许会有不错的用户量)

假设一万人当中,成功订票者的电话订票平均时间长度为60秒,这种攻略的最大意义,就是让自己的订票时间以最大的概率冲刺到60秒以内,比方式一靠谱!

最终结果按照这个攻略成功订到了最理想的车票!

针对场景一的思考过程,其实就是在围绕朋友的目标,分解需求实现的整个过程,然后在这个固定过程中找到痛点。其实,在很多实际需求转化的例子中,痛点往往隐藏的很深,难以发现;或分布的很广,难以集中。这个时候,就需要围绕产品阶段性运营的目的,抓住当前最有利于产品发展的至高目标,从而缩小范围,聚焦痛点。比如下例

场景二:某网站发展一年有余,不断快速改版上线新功能。近期对某子产品进行了一次改版,然后对用户给出了新、旧两版的选择。此后一段时间,该子产品形成了稳定的用户分流局面,99%的用户使用新版,而1%的用户则孜孜不倦的主动找到旧版入口使用旧版,并且该部分用户对该子产品使用情况异常稳定。当前对于旧版的运维面临成本,而对于1%的旧版稳定用户又无法割舍,因此需要根据当前产品发展的需要作出准确的判断:

判断一:

大部分成熟产品的用户分布,都存在二八定律:仅二成用户属于产品核心用户,表现活跃、使用情况稳定;大部分用户则属于长尾部分,不温不火,但构成了产品的主力军。

任何产品的发展目标,都是希望占八成的普通用户不断的向占二成的活跃核心用户转化。

对于传播特征明显的社区类产品(微博等),活跃核心用户的信息原创及信息传播范围比重却占到绝大部分,一定程度的影响和引导着其他八成普通用户,因此核心用户的口碑作用不容小视。

结论一:根据①/②/③的分析,该部分核心用户虽然不足二成,但稳定且成群,伤害不得,因此不能舍弃旧版的运维,应该予以保留。

判断二:

目前该产品,处于快速上升期,新用户增量明显,稳定用户群也在不断扩大,并且用户在产品中的行为习惯正在逐渐形成、悄然固化。

新/旧版本的子产品对于新用户来说,就是面对着同一个产品的两种形态,这意味着用户面临一次选择成本的付出,更面临着两种不同行为习惯的形成。

产品对于用户的行为习惯的培养至关重要,并且是一个艰巨的长线任务,也是一个较难逆转的风险任务。

结论二:根据①/②/③的分析,应该旗帜鲜明的让新用户使用新版;同样地,尊重旧版用户的行为习惯。因此,应该让旧版用户默认进入旧版,然后撤掉新版产品的旧版入口。

判断三:

产品新功能不断上线,用户量快速上升,因此这一阶段的产品目标,应该是集中精力照顾新用户,其他一切皆浮云。

如果按照结论二操作,这1%的用户将再无增减,并且未来基于新版子产品的功能升级等变化,也无法惠及这部分旧版用户。 因此仍然有可能伤害到这部分用户,造成麻烦。

让这部分用户从此告别新版,默认进入旧版,本身就是代用户作出了选择,并埋下了麻烦的种子。

结论三:既然本着尊重用户的原则,为该部分用户保留了旧版,那么也应该尊重到底,一是让用户在新旧之间作出选择,而非默认进入旧版;二是让用户知晓选择旧版后存在的不可预知的麻烦,让用户自己掂量。

理想结果:为1%的旧版用户提供一次选择,选择中说明使用旧版后可能存在的问题,然后提供两个选项:“默认进入旧版”、“选择新版”。此外,在新版中关闭所有旧版入口,并在旧版中提供升级新版的永久入口。此后,便集中精力做好其他事情,再也不用考虑这1%用户的苦疾了。

总结一下:

场景一告诉我们,在处理用户需求的时候,要仅仅围绕当前需求的实现过程解决问题,用户口渴即为找水的过程、用户回家即为解决交通的过程,话虽简单,但要认真分解简单过程中的痛点,才是满足用户的最佳途径。但是,如果你所面对的需求存在N种实现过程,岂不是手忙脚乱?

场景二告诉我们,要从大到小、从通性到个性的分析N种方法的优劣,圈定最靠谱的解决方式,然后才能锁定用户的痛点。做到这种境界何其难,但只要在实践过程中不断积累用户需求,了解用户的苦疾、吃透用户的心思,便能培养自己的用户同理心,在需求分析这条复杂的路上占得先机。

欢迎转载:http://www.liesong.me/?p=162 作者:劣松

从产品价值的角度体会“需求的减法”

要学会做减法,少做就是多做”————很多很多业内人如是说。慢慢的,所有产品人员都将这句话当做至理,时时提醒自己。如何体会到这句话的精髓?如何让自己在做产品的时候,对这句话感同身受?急不得。要逐层修炼,方可修成正果:

第一层:学会需求博弈

有时候,经常面对某一类需求或某一个功能,要决定做与不做。其实,是在对比和权衡这个需求本身的价值,是在做一次博弈。博弈的过程或快或慢,但答案却没有对与错,因为一时无法衡量,只能体会,或者猜。

看一个关于需求博弈的例子:豆瓣网一直没有为用户提供一个等级积分体系,CEO杨勃说,“积分问题提过很多次,讨论了很多次,至今还是没有放上去。主要觉得这并不是核心的东西,我们不希望用户是为了积分而来豆瓣,更不希望他们为了积分而灌水,我们需要高质量的帖子和高素质的用户。”博弈的结果,就是放弃这个想法。

将这个例子抽象一下:

(假设:团队对某个产品的需求定位已经初步确定,并明确了以后的产品价值,在于ABCDLM六个方面,即通过这六个方面迎合用户的主要需求,体现产品的核心价值。当然,随着产品的开发和运营,会不断的出现NEF……等等一系列附加的产品价值。就像人人网,初期通过人际关系网络这个核心价值吸引和满足用户,后来也可以通过WEB游戏占据用户的碎片时间)

面对一个需求,首先大致锁定两个方向,1和2,两个方向水火不容。如果按照方向1操作产品,结果只能达到BCD三个效果,如果按照方向2操作,结果只能达到LMN三个效果。回过头来,考虑一下我们理想中的产品状态,应该是ABCDLM,理所当然的选择方向1。博弈完成。

单纯看例子本身,确实完成了一次初步成功的减法,但远远没有触及问题本身。学会博弈,是体会精髓的第一层。第二层是什么呢?

第二层:产品开发的节奏感

没有节奏感,再好的产品也出不来。就像“学会做减法”一样,节奏感也是一个高端的东西,不是产品新人所能触及的。

看几个关于节奏感的例子:豆瓣网在05年5月首先上线读书功能,一个月之后上线电影功能,再过一个月上线音乐功能。这是一种节奏,虽然我们听不到它的韵律。杨勃说,“Web2.0网站是快速变化的,并不是把所有的功能都在开始阶段完全实现。”  Tumblr(国外某轻博客网站,已被墙)07年上线,然后一直在孜孜不倦的吸收用户。直到09年,重要功能Directory上线(前期文章中提到过这个精彩的功能),开始吸引新用户、聚合高端用户。这也是一种节奏,同样听不到韵律。泛泛的说,产品的节奏,就是把握产品运营的火候、顺应用户需求的变化。

将这种节奏感抽象一下:前面说到,理想中的产品状态是ABCDLM,当我们面对两个需求3和4,3可以实现ABCD,而4可以实现DLM,怎么办?集中精力做好3,视情况调整4的进度。

面对一个产品的一系列需求,其实只有少部分水火不容的发展方向需要作出决断的博弈,大部分需求需要控制节奏,分出轻重缓急。所以,“学会做减法”,还要“学会加括号”,小括号先算,中括号次之,大括号最后算。

有时候,对于控制节奏这种事情,要多做才能有感觉。控制节奏,是体会精髓的第二层。第三层是什么呢?

第三层:就是产品的ABCDLM”

没错。就是你对产品的期望,是产品要达到的理想状态,即产品价值

看一个关于产品价值的态度:杨勃将豆瓣的核心思想总结为,“可以发现不同的东西,并且适合自己,可以理解为一种以书等具体物体为媒介的人脉关系网”。他还说“一开始做豆瓣不是为了做一个网站,而是满足人们的一个需求,如果对用户没用,只是新鲜是远远不够的。”

原来,从一开始,豆瓣就在集中精力做一件事情,并不是读书、音乐、电影、WEB2.0,这些都是浮云,而是找一个媒介,然后去织一张网。

回过头来,重新审视前面两个例子中的问题:

为什么首先选择读书作为媒介?相比于电影和音乐,能一部一部读书的人,是最踏实的。因此以书为媒,去织第一张网,是最结实的。第一张网可以小一点,但要足够结实,然后才可以更自信的去织第二张、第三张……

为什么不为用户提供积分等级?因为,通过书籍、音乐、电影而成为豆瓣中人脉关系网的用户,彼此之间的链接,不是亲情友情爱情、不是工作同事。所以,豆瓣用户在这张网中的关系,不需要等级去巩固和对比,而需要书籍、音乐、电影去体现。人人网需要等级,但豆瓣,不那么需要。

两个问题,其实归根结底,都要从产品价值本身去找答案,所以最重要的事情,是要精确的罗列你心目中无比向往的产品价值:ABCDLM,然后在面对任何问题和困难的时,反复温习曾经罗列的那串理想,就能做出选择。

所以,多花一点心思在产品初期的需求分析和价值定位上,如果对自己产品的价值无比自信,那么无论以后在产品发展过程中面对任何困难,才能充满自信的根据当初的理想,做出每一次博弈、控制每一次节奏。做减法,需要理直气壮。

只有做好前面的铺垫,过程中的“坚持”,才是正确的选择!

文章地址:http://www.liesong.me/?p=141 作者:劣松