Archive for the ‘案例分析’ category

SNS网站需要开发IM才能提高用户粘性?

June 21st, 2009

以下是来自易观国际的研究文章:

易观国际(Analysys International)建议:SNS网站应该重视IM的聊天功能,有实力和用户基数大的网站推出自主IM客户端(可以是Web版本);较小的SNS网站可以与现有IM进行合作,实现用户数据共享;以此来增加用户粘性。

易观国际(Analysys International)《中国SNS市场用户调研报告2008》研究发现,“查看好友空间/动态”、“和好友聊天”、“更新自己的空间/动态”是SNS用户在平台上最喜欢做的事情。

用户在SNS平台最喜欢做什么

“个人空间”(包括相册、日志)、“群组”和“分享”是用户使用的最多的SNS系统功能。

用户使用过的SNS系统功能

结合两个调研结果,可以看到“群组”和“分享”功能,很多用户尝试过但却不经常使用,网站可以考虑将其放在次要发展地位或者对功能进行改进;而“聊天”功能被很多用户经常使用、但网站却没有提供强有力的聊天工具。

不过根据笔者近期对SNS和IM的用户访谈所得到的灵感却对这一建议并不乐观。

首先SNS和IM的用户在好友分布以及对即时聊天的要求上都有很大的差别。

先说好友分布:就校内,开心,51来说,其用户群是有显著的区别,但共同的一点是这些SNS上有大量的熟人,就是点头之交的同事或同学。而IM上的好友则有更多关系密切的朋友,虽然也会包括熟人和陌生人等。但是IM与好友的及时沟通的这种用户粘性不是现在的SNS通过加上一个IM就能抢占这部分用户的。

再说对即时聊天的需求。SNS如开心网上的用户对即时聊天的要求很低,大部分人都是通过一些游戏组建引发一些交流,但是这种并不要求及时回应的沟通也大大迎合了熟人之间也需要维持交流和增进感情的情感需求。目前在SNS上交流的用户如果有进一步增进感情的需要,很多都会选择加为QQ或者MSN的好友。也许你觉得这对于SNS就是一个机会。但是别忘了用户的这种习惯并不是轻易能改变的。因为用户多增加一个IM,其管理负担要相应增加很多。比如每次启动电脑都要启动好几个,不同的IM还要用于不同人群的联系。以前曾经很多的门户网站发展自己的IM都以失败告终就是一个很好的例子。

当然对那些需要通过SNS来交更多的陌生朋友的人来说,有这个SNS的IM会方便很多。对这些SNS是唯一交流平台的刚认识人来说,优先选择该SNS提供的IM来进行即时聊天,以此增进感情。问题就在于如果他们一旦关系已经很深的情况下,会不会考虑加到QQ或MSN来聊天就很难说了。

其次对SNS网站的Web IM来说,应该是一个机会,至少方便了偶尔有这种即时聊天需求的人;或者方便了那些要通过SNS来交新朋友的人的需求。但是对那些真要这个和熟人之间交流以增进感情为目的的人来说,Web IM显然是不够用了黏住用户的,他们很容易的转到常用的IM上来。如果想靠Web IM来黏住用户,也是不现实的。

笔者觉得SNS应该更多的创新,从研究人的深层次沟通需求来提供用户的粘性。沟通除了言语和文字的直接的交流,也有现在的基于一些动作式的(如握手,拍一下等),和共同游戏的间接的交流(如投票,真心话等)。而对于很多熟人之间,这种非直接的沟通方式也同样增进了了解,增进了感情,这种沟通方式是有效的。SNS不一定非要转到直接的文字和言语的交流,因为这种交流更多的是IM和电话所占据,不是SNS目前要去关注的。

SNS的手机客户端用户访谈

June 4th, 2009

索尼爱立信最近宣布其多款在中国发布的手机将内置开心网,也就是开心网在手机上的客户端。校内网之前也发布了其Java版的手机客户端。

开心网手机桌面客户端 开心网动态
校内手机登陆 校内好友动态

深度访谈了7个校内网和开心网用户(包括手机端用户和PC端用户),了解他们在PC和手机上的使用行为,以及对待各种交流工具(即时通讯,社交网络,手机短信电话等)的态度。

最后也让用户试用了一下开心网和校内网的手机客户端,看看他们的态度和期望。

下面是一些对访谈结果的思考。

一.各种交流工具的关系图:

relationship between different communication tools

该图解释了SNS,IM以及SMS等不同沟通工具的关系

1. 短信和飞信的重合度非常高,且绝大部分用于关系亲密的对象。而SNS上有很多只是熟人(如同事和同学,但好多只是点头之交,通过这个平台加入好友),与这些人交流的即时性要求很低,通常只需要每天查看一两次就可以了。

2. 这些交流工具上的联系人不是一成不变的。通过SNS上认识的成为好友的,会加到IM上,IM上关系更亲密的会用手机短信和飞信联系。当然IM上的好友也会有部分被邀请到SNS上。

3. 被访者在SNS上的直接的文字交流很少,都是通过投票,真心话,组件游戏等进行间接的交流。如果需要更多更即时的交流,他们更多地会选择通过IM来交流。

4. 某些SNS也试图在PC端做一个自己的IM,如校内的PC客户端“校内通”旨在让用户能很方便的直接与在线用户聊天,可是用的人却不多。该模型能帮助我们理解为什么“校内通”很难达到其预期的目标。

5. 开心和校内用户的区别:

为什么同样是种菜在开心上这么火,在校内上却没有如此呢?

因为开心用户群绝大部分是上班族,上班用电脑上网是没有问题的,这样很方便随时有空上来玩一会游戏。而校内用户大部分是学生,对于一个以学业为主的学生来说,像花园这样的游戏显然牵扯太多的精力,所以他们对待校内游戏的心态,显得更理智一些。

同时我们也发现虽然校内并不像开心那样主要以游戏为吸引点。在校内上同学好友之间的内容创建和分享(学习资料如雅思,托福,励志文章,搞笑图片和视频),日志,照片分享等比游戏更具有吸引力。

P.S.:网上调查结果(明年这个时候你还会在开心上种菜吗?)

image

80%的人认为不会,结果让人吃惊,现在这么火的游戏,每天上好几次,但是大家都不认为热度会持续一年。

是都在等待下一个流行的应用吗?

问题是,如果没有下一个流行的应用,开心拿什么留住用户?

二.开心手机客户端拿什么吸引用户?

1. 移动,随时随地都可以上。当然开心最吸引用户的,像抢车位、开心农场等是必不可少的。这部分用户占开心用户的绝大部分。

2. 间接的交流:借助开心的非即时的文字交流平台(如日志,评论,投票,真心话等)大大增进了很多只是点头之交的同事或朋友之间的了解和感情,对于提高开心用户的粘度和忠诚度有着非常重要的作用。如果和开心上的好友之间的交流对开心用户不是最重要的,那么无疑仅靠游戏是很难黏住这些用户的。

3. 但是这种间接的交流方式是不需要用户在手机上时刻挂着这个程序的,因为对即时性的要求很低,每天查看一两次也就够了,像电子邮件一样。

4. 那有什么理由要求用户一直挂着这个手机客户端呢?

采访中知道用户很多会挂着QQ和飞信,因为这是即时的通讯,虽然耗电是个问题,多任务处理也不是对所有手机都适用,但是客户挂着IM有其现实的需要:比如飞信用户,很多常常短信联系的朋友都在飞信的好友列表上,即便对方不在线,也能通过飞信发短信到对方手机上;而对于QQ用户,由于现在常拿手机挂QQ的人多了,用手机聊QQ的现象也随处可见。一位最年轻的被访者(19岁)说,他的很多好友都使用手机QQ聊天,这意味着他可以很容易的在移动QQ上找到自己要联系的好友。

5. 对手机电话簿创新设计的启示:

考虑到用户会根据不同的交流需求在不同的沟通工具中来回切换,比如,收到一条手机短消息,回复的时候会通过飞信。对我们的启示是:用户如果有一个集成手机电话簿和IM好友的通讯录,在回复的时候可以选择手机短信回复,也可以选择通过飞信回复,或者QQ,MSN,无疑这将给用户带来了非常好的无缝切换的沟通体验。

飞信和手机电话簿的高度集成是一个可以首先考虑的方向,因为飞信和手机电话簿的重合度非常高。

但是与手机电话簿高度集成目前并不适合SNS用户,一是因为二者重合度低,二是SNS用户对SNS上好友的即时通讯的需求低。

开心的好友列表没有它看上去那么重要。被访者并不会经常去点开一个好友的页面,查看详细信息。通常都是通过好友动态来查看相关信息和参与各种交互。

三.目前开心客户端的问题

(省略)

四.如何保证开心手机客户端的用户体验?

1. 流量要清楚,透明:任何时候用户都要清楚的知道流量是多少,包括下载页面,和上传图片(图片大小多少K)

2. 用户的期望是客户端能实现wap的全部功能,如果要超过用户的期望,则需要客户端能提供给用户更多的附加值:快速实现在PC上常查看的内容,比PC能更简单快捷地实现挪车位和偷菜等(如一键偷所有好友的菜等)。

3. 桌面开心,需要给予用户更多的控制权,如可以最小化;可以控制不显示桌面开心,但仍保持开心在后台运行。因为手机桌面上有很多用户自己认为更需要的东西显示,比如自己设置的桌面图片,各种快捷图标等。

4. 支持客户端显示全部内容(不需要上Wap端),能支持当前开心上的热门游戏。

5. 考虑手机的实际使用环境:很多用户的手机里通常还装了其它的软件,比如QQ,飞信,MSN等,考虑多任务的情况;还需要考虑各种常用客户端经常使用的快捷键,如翻页(Page Down/Up),回到顶部(Home/End)等,并保持与其它常用客户端的一致,也会减少用户学习使用新客户端的时间,保证良好的一致的用户体验。

完。欢迎大家批评指正,谢谢。

SAP的UCD设计流程

October 24th, 2008

SAP最有特色的地方是将每个application的设计分级别,比如A,B,C三个不同的级别。
A级:应用full UCD process
B级:选择性的执行一些validation steps以及部分用户研究和可用性测试
C级:使用推荐的适合这一级别的方法
然后根据不同的级别,采用相对应的UCD设计流程。
» Read more: SAP的UCD设计流程