站内信 - UCD大社区

留言、评论和站内信

千鸟 — 2008-12-24 23:04:43

上周日下午还是在詹老师的奇遇咖啡馆，除探讨既定的“留言和评论”话题，还有个重要事情，曾经很早推荐过的《Communicating Design》中译版今天首次面世。同时，我们还请来了译者樊旺斌同学，机械工业出版社朋友也带了好多书过来。

下午阳光明媚、天气惨烈，说实话我都不想来了。几乎没准备，其实也应了咱们的初衷，探讨而不是准备出有价值的观点。以下内容为编辑整理，增加了几个例证。

留言和评论

最早做个人网站的朋友可能都还记得，当时最流行的功能就是留言，作为与站长交流的最便捷、实用的唯一途径。随着功能越来越丰富，单向留言也变成了双向回复，总结特点如下：

对人
N对一
基本为文字

最早做个人博客的朋友也可能都还记得，当时流行的asp博客系统上都有个留言模块。有可能来自个人网站的传统，但随着博客系统的发展，留言模块逐渐被淘汰。因为博主们逐渐发现，日志评论已经能满足与用户的沟通需求，留言板则几乎成了spam的乐园。其实评论应用可能更泛一些，但不管是文章、照片、邮件、帖子，还是多媒体内容，或富媒体应用，尤其社会化网络产品体现很明显，特点也有三：

对人、事、物
N对N
文字为主，图片、动画占一定比例

因此我认为评论是留言的升级，产品完全社区化之后，已不再需要独立的留言模块。并且在产品发展更贴近线下业务的前提下，评论设计更趋于个性化定制，比如打分、顶、拍砖、抢家具等更以用户为中心的应用，或设置更符合产品发展的人为障碍。

留言和站内信

分析到最后我发现，私人留言其实就是站内信，它们之间的关系很直接。也就是说，传统留言的功能模块已经退出历史舞台。隐私应用等同于“站内信”功能，公共应用则扩展为更有针对性、更具目标导向性的“评论”功能。

处理较好如豆瓣，除能对图书、音乐、电影进行评论，还支持站内信，并且取了“豆邮”这个更符合品牌特色的名字。处理欠妥如开心网(kaixin001.com)，个人首页消息中心并排“短消息、留言板、评论”六个链接，尤其留言还有“悄悄话”功能，完全与短消息应用重叠。

相应给淘宝个人店铺提个建议，取消对店铺的留言功能。顾客要咨询某件产品尽量引导到产品页发言，店主要对顾客留话，店铺公告也完全可以满足需求。在互联网灰色营销方法发达的如今，多一事真不如少一事。

奇遇咖啡馆
http://storygarden.me/

《Communicating Design》中文版面世 - UCDChina
http://groups.google.com/group/UCDChina/…/thread/86d3d5e42c67e4b9/

《Communicating Design》 - UCDChina
http://groups.google.com/group/UCDChina/…/thread/d0e1f3562a0969e8/

相关话题：站内信留言和评论源地址：http://blog.rexsong.com/?p=3064

欲废此功，必先自宫

白鸦 — 2008-11-15 21:57:54

（图1，阿北很早时候的豆瓣截图）

如上图，阿北的豆邮有1206封未读。（如果是邮件处理的，算特例，在此不做分析。其实邮件处理对于普通用户来说是把双刃剑…）
注：豆瓣的站内信最早包括关注通知、站内信等信息，现在“在九点的关注”还阴魂不散的出现在这里。

（图2，UCDCHINA的百度站内信截图）

如上图，UCDCHINA的百度站内信有50封未读。（前面一百多封的时候我还在百度，有信息就处理，粘度高的不能再高。后来交给UCDChina的团队用，这些站内信就都懒得处理了…）
注：百度的站内信是整个百度线的沟通渠道，包括所有百度可能需要发给用户的信息、站内信，甚至新用户注册的时候也有几封信。最早的时候这些信息在站内信里面连分类都没有，现在有了。

在豆瓣、百度、facebook、Flickr、5Gme.com…，你的站内信有多少未读？

为什么这些站内信失去了作用？原因很简单：欲废此功，必先自宫。

别指望用站内信来教育新用户。
新用户不会对“站内信”产生很大的兴趣，如果不是有相对迫切的“需求”，用户不会专门跑到你的网站看站内信和听你用机器说一句“欢迎光临”。给新注册用户默认发“欢迎”的信件，坏多于好（具体得看你的用户层次和产品性质，“欢迎”是最俗的主题，可以想想有没有更好的主题）。
发一封，并同时给用户提供方便删除的途径，有时确实可以起到提醒、教育用户对“站内信”的认知作用。但，某些网站在一注册就收到“欢迎”“系统通知”“申明”“密码安全”等四五封站内信。无异于自毁城墙，对于大部分非“初级网民”来说，他们看看标题就直接离开了。留下”站内信(4)”这个烙印，永不再用。（有些是为了推卸“法律责任”，这么干是最没有出息的行为）

清零。让用户清除压力。
已读、删除功能很重要。如果必须发，没有必要的话不要默认预览太多内容。一封看了标题就能明白大致内容的信，如果不是很有兴趣或者必须要处理，用户不会打开同时也懒得随手删除。两封、三封、四封.. 人都有天生的“懒惰性”，再无聊的用户，看着数字到了两位数，就失去了感觉，对站内信产生了天然的“免疫力”。
必须很突出的展现给用户很方便的“清零”功能，让他们很熟练的运用“清零”手段。甚至不惜以牺牲体验为代价，设置一定的阅读门槛（比如，默认预览内容少）让他们“打开”（打开=清零）。

最好把“系统通知”和“信件”分开。
繁复的不停更新的“系统通知”会让用户失去对站内信的兴趣，进而影响对真正“信件”的兴趣。在重要界面上（往往是首页）开辟一个“通知”区域很有必要，这样可以增强用户对“通知”的重视，也会降低系统对于“信件”的干扰。因为，站内信一般情况都只是在导航上有一个“未读数字”的提醒，用户可以很快的视而不见；而通知在首页上会是一块内容，相当于“眼中钉”，“清零”动作也变成了随手的“任务”。某种意义上“通知”就等于“任务”。

“站内信”不是取之不竭的“金矿”。
最害怕给网站添加站内信功能，因为每次添加站内信功能的时候，最重要的工作就是“谈判、立军法”。不立“军法”，不敢开战。
因为，站内信一出来，肯定是没完没了的“这个活动需要给用户群发…”“这个促销需要群发..”“这个新功能需要群发…”
没完没了、没完没了、没完没了… …

特别是一些根本不懂互联网运营（大部分运营人员还是很强的，少部分如此）的人，特别是一些只知道盯着PV看自身网站资源能割多少肉，根本不去管产品会不会废掉的运营人员，特别是一些只知道眼前KPI的人。他们真的想象力匮乏，站内信对他们来说就是一个“金矿”、“救命稻草”，甚至不停的告诉你“打开率很高、效果很好…”
就算你不停的给他解释“打开率肯定随着活动的越多在不停下降，这个打开率的下降就是站内信这个功能的慢性死亡的征兆”，他们也一样熟视无睹。只知道不停的说“老板要KPI…”
如果没有军法，如果你的运营搭档很XX。你必须的得罪他们。或者你死掉。

当然，我不是反对完全不可以用站内信去做运营和营销的事情。只是“必须有节制”，必须把这些内容当作“对会员有用的增值服务”，不附和这个标准的就是在屠杀产品。

很显然，当一个网站技穷到只能在自身产品核心功能，或者核心和用户的沟通渠道上，附加大量多余营销内容的时候，这个产品/渠道（包括短信通道，给用户的通知邮件等等）已经患上了慢性癌症，死亡的征兆已经来临。
往往运营一段时间以后发现功能已经无法运转了，不是因为“产品有问题”，而是我们在市场运营、产品运营的时候给这些基础功能强压了太多，他们本不该承担的“责任”。最终导致夭折…

只要是对用户有价值的功能，用户不会嫌弃。绝大部分时候，是你，是你逼着用户嫌弃它们。欲废此功，必先自宫。

.
最后，附图一张：

（图4，我的的5Gme.com站内信截图）

未读信息为0。这是我站内信利用率最好的一个网站。因为除了私信就是私信。不是因为他是sns，而是因为他抄的和facebook一样，分开了处理，没有干扰。）

相关话题：站内信源地址：http://uicom.net/blog/?p=795

站内信是不是鸡肋

陳金餅™ — 2008-10-01 09:40:27

如果你已经拥有一些关于某个素未谋面的朋友的个人信息，比如年龄、职业、兴趣爱好、邮箱、QQ、MSN，你还会给他发站内信吗？

我的答案是：那是必须的。

可以设想一下这样的情景：你在豆瓣上看到这个朋友收藏了某部你喜爱的电影，由于豆瓣在电影单页上并不提供点对点的交流，那么你只能选择发个豆邮给你的朋友“嘿，我也很喜欢这部电影呢！”又或者，在Gmail邮箱里收到朋友的电子邮件（如果你恰好打开了WEB GTALK，它就相当于一个离线消息），询问一些急切但不一定重要的问题，很多时候，你可能会选择直接在他的头像上点一下，直接回复。

开心网的用户是典型的鼠标用户，他们喜欢在网站上投票，测试，玩游戏。我注意到，开心在消息提示中细分了系统消息、留言、评论和站内信，同时它们还提供了WEB的站内IM和一款聊天室游戏。即使提供了如此丰富的交流方式，这群以IM邀请形成的开心用户群体之间仍然有79%的人会选择站内消息作为聊天的方式，选择站内IM和电子邮件聊天的用户仅为17%

出乎意料的是，用动作表情代替文字交流的居然占到10%，看来踢他一脚和送礼物的行为已经足够让开心的用户获得好友的关注。

还是继续说开心吧，有意思的是它玩了点不诚信的小把戏，却使用户之间的评论交流在增加，准确地说，它把短消息、留言和评论融为一体地处理了，多数时候用户会觉得隐私外泄了，但开心的小把戏还是得逞了

1、站内消息+照片评论

回复评论变成了站内消息，回复站内消息变成了公开评论，新的评论又变成了站内消息，自如切换概念的开心。

2、争车位的举报卡

购买时注明了匿名举报，但在使用中则“泄露”了举报人

结果是，用户纷纷购买举报卡伺机报复

最后，举报人被口诛笔伐，开始认罪

先是让用户到处停车加油争着换购名车，再到各种各样的道具出炉，引发争议，使玩家们不知不觉地扮演着各自的角色，这就是巧用站内信的开心游戏体验。

相关话题：站内信源地址：http://itoi.blogbus.com/logs/29714307.html

由Facebook的一封站内信说开去

OutC — 2008-10-01 09:08:58

最近UCDChina的话题是站内信，我的话题也由站内信说起，不过内容跟站内信无太大关系。我们看一封Facebook发给某用户的站内信：

请注意，Facebook账户仅为真人用户而设立，我们期望Facebook帐号可以真实反映“现实生活”中的联系人(例如：家人、同学、同事等)，而不是仅在网络上的朋友。正如我们在首页的声明，Facebook是一个社交工具，而不是“社交网站”。也就是说，我们希望连接你和你身边的人，巩固彼此认识的朋友之间的友谊，而不是找到一大群新朋友。如果此规定有悖于你先前的想法，我向你表示诚挚的歉意。但这就是我们创办Facebook的初衷。
如果注册帐号仅仅是为了使用应用程序，那么就违反了我们的用户协议。很遗憾，我们不会重新启用你的账户。为此而引起的一切不便深感抱歉，但这个决定不会改变。
感谢你的理解。
劳伦

这是Facebook团队发给用户的“劝告信”，当初用户为了玩Facebook里面的插件游戏而去添加不认识的好友或者一个人注册多个“马甲号”，现在却因为这个原因而被Facebook封号。因为Facebook的初衷不是让用户通过自己结交大量新朋友，而是为了巩固彼此认识的朋友之间的友谊。

我不得不说，Facebook是一个有思想的网站，最起码他们知道自己要的是什么。

我们反观一下国内的校内网，不可否认，校内网以同学作为社区的关系纽带有着得天独厚的优势，目前的用户群在国内的各大社交网站中也是最大的。不过，“有头脑，没思想”这句话用来评论校内网最合适不过。

自从校内开放了API之后，各种应用插件如洪水般涌入，比如争车位、好友买卖、在线宠物等等，这种“涌入”造成的直接现象就是在个人首页的“新鲜事”列表里充斥这大量的低价值用户操作信息，如“张三在李四的车位上停了X小时，赚了X元”，“ 王五花了Y元买赵六为奴隶”等等，甚至连某某人摸了摸好友的宠物小狗都要在列表里亮一下。与那些高价值的新鲜事相比，这些信息彻底混淆了用户的视线，整个校内网完全被游戏娱乐的氛围所笼罩，高端用户进一步流失。

国内网站的发展路线随着时间也会慢慢走形，对小网站来说，姑且可以称之为“小网站的灵活性”，但是对于大网站来说，这恐怕就不是战略所能决定的变化了吧。试想一下，如果校内把那些应用程序来作为赢取用户的主力军，那么我想知道的是，这样的用户忠诚度能有多高？

对于有些事，我们不妨学习学习Facebook：我们本来希望你这样这样，而你却那样那样，那我们不要你了，连这样也不给你。

再回头看看那封站内信，Facebook显得是那样的自信和有原则。

相关话题：站内信源地址：http://outc.yo2.cn/archives/29067

站内信——从使用情景上思考

JunChen — 2008-09-23 22:31:52

大致回顾一下9月21日南京UCD书友会的讨论话题：站内信。

从好的站内信设计开始讨论（虽然没有发现很出色的站内信设计），然后是“站内信解决了什么问题”，分清了站内信的需求层次，最后给站内信下了一个较为完整的定义：一个网站的用户向其他用户发送的具有一定即时性和一定私密性的消息。所以站内信的设计，便是提供满足这个过程的功能。

在书友会快要结束的时候，我忽然觉得我们陷入了功能规格的漩涡，整个下午的收获就是给站内信下了一个定义！虽然这个定义还挺像样的。（这个定义抛弃了网站发给用户的通知，认为是借尸还魂，此处仅一提，略去不谈）

从使用情景上思考

站内信是一个很特殊的话题，特殊的地方在于它像是大部分网站的标配功能。这个特殊性，很容易让我们陷入功能本身的讨论中去，而不展开并深入到用户层面。怎么讲呢，用户才不会管你是叫站内信，还是邮件，还是短消息，还是留言等等。重要的是当用户想起要给其他用户发消息（见顺带一提：粒度的问题）时，有一个按钮、有一个链接在那里，能满足这个需求。

大部分用户（哪怕是专家）都会选择成本最低的方式来操作。比如我给你发个私信，你很大可能使用私信回；我给你打个招呼，你很大可能不会用私信回。同时，当你想发消息给我，必然会选择成本最低的方式，比如头像边上正好有一个发私信的链接、或者正好在看一篇日志于是回复之。

还有些相反的（退出使用）情况。比如，当我发短信给你，你觉得短信沟通成本过高，于是直接打电话。这种情况同样可以对应到站内信中。又比如，我给某 MM站内信（为什么不用留言，是因为留言没有站内信私密，见下文“私密性”）道：美女，QQ号多少？于是就放弃站内信而使用QQ了，因为站内信沟通成本太高。

于是这就涉及到用户对这个功能的期望。这点在书友会上有提及，我们分两个维度：即时性和私密性。对私密性没有要求的，用户会选择在个人资料页上留言；对即时性有很强要求的，用户会选择换IM（如果可能）。这话说的不严谨，应该是交叉的四个象限来看，这里简单点就略了。然后，并不是越私密就越好，也不是越即时就越好，这里面有一定的层次。

顺带一提

粒度的问题：发消息已经是很具体的意象，再往上就是更宽泛的沟通层面。谈到沟通就会涉及到内容的形式，比如文字、图片、音频、视频。本文讲发消息，特指文字。

即时性的问题：很多朋友会觉得站内信没有即时性。这需要看站内信是怎样推送给接收方。在接收方在线的情况下，能即时PUSH站内信，就是即时的，这也就是站内IM的雏形。接收方是否在线，不能作为评判标准，因为IM也有离线消息，但不能说IM不是即时通信。我们以木桶的最长边来看待这个问题。

站内信的扩展：有朋友觉得做个动作是站内信的一种外延。对此我持保留意见，理由就不赘述了。不过，打招呼还勉强能算。

对设计的帮助

用户想要的是发个消息，而不是去用站内信功能。我们不能为了讨论站内信而讨论站内信，也不能为了设计站内信而设计站内信。一心想着提高即时性等特性，却忽略了需求层次。

把未来的情景描绘出来，而不要陷入功能规格的漩涡。针对情景中不同的需求层次、期望，通过不同的途径（界面和功能）去满足。招呼、站内信、通知、留言等等如此应运而生。他们的存在有一定道理，但我这里提到并不是说在你的SNS产品中就必须得有这些功能。

考虑成本问题。一方面是经济成本，在此次书友会上讨论到的BP机被手机取代的例子，就是因为手机短消息成本很低。另一方面是接入成本，用户会使用马上能用、在手边的功能，而不是到处找站内信在哪儿。

把未来也同样描绘给用户。需要以显性的方式告诉用户，使用这个功能能达到什么效果。比如站内信，需要提示用户对方会怎样收到提醒、在哪里看到内容，等等。这样可以有比较一致的期望（即时性、私密性）。

以上。

记述的稍微有些乱、罗嗦。希望读者能够明白，欢迎参与讨论。欢迎来参加 UCD 书友会。

另，站内信话题还可以写以下文章，欢迎各位参与：

用户与用户之间沟通的层次
站内信与站内IM vs Email与IM
站内信是否是历史的过渡？站内IM会取代站内信吗？
等等

UCDChina九月北京书友会全记录

栗子 — 2008-09-23 01:08:08

时间：2008年9月21日星期日14：30——17：30

地点：奇遇花园咖啡馆

本期主题：站内信

首先讨论的是由周波（新浪房产数据分析师）引发的网站数据分析，主要讨论了一下数据分析的工具和方法，对我这个数据白痴有很大的帮助。定量分析应该是网站做用户行为分析、流程分析最主要的方法，而我个人也一直认为定量分析比定性分析得出的结论更有可靠性。当当大姐（在当当网工作的那个大姐，非常抱歉，没记住叫什么，就这么叫吧）提出，数据分析师是否会将分析结果转化为生产力？这也是数据分析的根本意义所在。周大哥说他们会根据分析结果向相应部分提出各种改进的方案。我没有做过这方面的工作，以后在这方面应该多注意些！

接下来主要探讨的是“用户测试”的问题。记不清是谁提出的这个问题，但大家都交流了自己参加的用户测试的很多经验。尤其是林小龙（以前在灵图软件，现在自主创业），貌似经验非常多，利用自己做车载地图导航的用户测试与大家做了交流，并提出“主持人的主持在很大程度上决定了用户测试是否会成功”的观点。对这一点我非常赞同，我们公司上次组织用户访谈，会后总结，大家都在夸经理非常有主持天份，影造了非常轻松的氛围，并能非常有效地组织大家围绕着相应的话题做讨论，控制好访谈的节奏，达到公司预定的目的。关于用户测试，我的经验是前期一定要充分准备好，包括问题的设置、会议的流程、时间的控制、氛围的影造、访问的形式（一对一、一对多、多对多等），这些都直接牵涉到用户是否会真正地表达他们的观点。最主要的是如何从用户的测试中发现有利的价值，我想这与每一个项目的具体问题相关，我就拿我们公司的“魔法相册”的用户测试跟大家交流了一下，希望大家也能明白我所表达的观点。关于用户测试的常规则方法，很多书中有介绍，但那些都是一个基本的指导，不同的项目实施也起来，差别太大了，还得灵活掌握！

谈到用户测试，又联系到“焦点小组”，其实我理解的焦点小组在很多时候应该是小规模的用户测试，当然是对于产品已经开发完的情况下，如果是在产品的设计策划阶段，我觉得“焦点小组”更像是“头脑风暴”，尤其是公司内部的“焦点小组”，能从很大程度上解决产品功能需要和开发的问题，这点我有深刻的体会，公司在设计一个产品时，产品、运营、技术甚至市场部门的人都会一起参加，在产品的初始设计阶段，即融入各个部门的意见，对于以后的合作、产品的开发进度等都有很大的帮助。

接下来由于聊了很多关于当当的东西，大家都在抱怨当当的很多不良体验，不知做当当UE的大姐是什么感觉！难道他们都没有意识到用户的这些问题吗？不是的，当当大姐谈到公司体制的问题，呵呵，这是所有设计师最头疼的问题！有能力发挥不出来，绝对是公司体制的问题！其实用户体验对于电子商务类的网站是最主要的，直接关系其商业利润，真的希望当当早些时候做些改进，毕竟它也是一个响当当的品牌，很多像我这样的用户，经常上去买东西！

瑞星的大哥提出来他当前面临的几个非常痛苦的问题，征求我们的意见，可惜行业差距太大，没有一个给出一个比较有建设性的意见。从他的交谈中，也深切体会到在这种技术导向性公司做设计的困惑，真的太难了！瑞星的大哥准备搞用户调研，可他准备从中关村商户和瑞星购买商做起，其实我并不赞同他的这种做法，我觉得应该调查的真正使用瑞星的普通用户，他们是瑞星真正的使用者，了解他们的使用行为才能真正地了解这个产品。当然，他那样的做法，对于市场部门是一个好消息！另外，有一个小小的收获，第一次知道360竟然不是杀毒的！对于病毒，目前的软件有三种做法，一是发现病毒，二是拦截病毒，三是杀掉病毒，360违反行业常规，只做了前两者，没做第三步。其实这从另一个侧面可以说明，对于我这样的普通用户，真的不了解甚至不想去了解这些杀毒软件到底是怎么工作的，我的目的只有一个——让电脑不中毒，只要达到这个目标，不管你是什么软件，使用什么工作原理，对于我来说，就是最好的软件！

不知不觉时间就到了三点半，范老师组织大家集中座在一起，开始了这次书友会的话题——站内信。

站内信的功能：

站内信的功能就是与其它人交流、沟通，是一种非即时化带有隐私性的交流（如果需要即时化，有QQ等IM工具，如果没有隐私，直接留言即可），也是一种最基本的交流工具，其形式以一对一为主，有时也会有一对多的形式。我个人的理解，留言板、打招呼以及现在比较流行的“动TA一下”，都是站内信的一种外延形式，是站内信的一种发展。

站内信的群发：

站内信是否需要群发功能？这要根据网站的性质而定。当然对于网站管理员发给用户的各种站内通知选择群发是必然选择，但用户基本是不需要群发功能的，甚至当当大姐都说自己从来没有给第二个人发过相同内容的站内信，其实这也是大多数用户的行为。可是必然会有一些用户会需要到群发功能，可是群发必然又涉及到广告的群发，这是网站和用户都不希望看到的东西。如何防止广告的群发是对站内信的考验！大家也没探讨出非常好的方法。不过好像现在还没有网站能够在“收信人”栏中提供可以输入多个名字的功能，只是对多次给多个人发送相同内容做限制，像开心网的“动TA一下”可是说是站内信的一种外延形式，可以在姓名栏中输入多个名字，这是由于其功能需求及产品本身的特性决定的。目前校内的做法好像是会检测每次发送的内容字段是否与上次相同，如果单位时间内相同内容达到规定次数，则会限制权限。我就曾经被限制过，当然我不是发广告，而是给初中同学发聚会通知。当然还有很多网站对关键字做限制，如反党、分裂、色情等很多字段。

站内信的显示方式：

目前站内信的显示方式主要有两种，一种是按对话形式显示，一种是按时间先后显示。当然，目前大部分的网站都会选择前者的方式，后者的方式主要出现在“留言”版块。Tony提出，以主题、观点类的适用于前者，以联系为主的内容适用于后者。这一方面，以后写篇详细的文章介绍。其实对话的形式更符合用户的心智模型，把站内信内容做成IM的表现形式，也有利于用户回忆以前的内容。

站内信的发送方式：

这是千鸟提出一个非常具体的问题，主要是交互上的细节问题。详见千鸟的文章。

站内信的提示方式：

提到这个问题，千鸟马上提到由台湾穿过的论坛声音提醒“您有新的消息，请注意查收”，幸好这个如此恶心人的设计慢慢消失了。但现在又出来了以开心网为首的把站内信IM化。大家讨论了这种设计的优劣，对于用户来说，将站内信的IM化，有利于用户及时地阅读到站内信，但我个人认为，那种闪动的设计，对我个人并不是一个良好的体验。我觉得站内信提供的就是非即时的信息交流，我也不需要马上去看到它，甚至会因为它的闪动，严重影响我的工作流。

站内信有许多的提示方式，比如说字体颜色、字号、图标等，都有很多可做文章的地方，个人更喜欢它能够默默无闻地工作，等我需要它的时候，自然会让它发挥它应有的功能。

站内信的标题：

这个问题，大家讨论得也非常热烈，并得出了结论——站内信不需要用户写标题！站内信本身就是简单的交流，几句话的事情，为什么还要写一个标题呢？！我想，很多网站之所以设置标题，而且为必填，可能是借鉴了“邮件”的书写形式。而邮件之所以些标题，是因为它的内容一半都比较长，写标题个人认为是为了以后的邮件搜索和阅读。

而且用户一般地会把标题理解为“打招呼”，用户会输入“你好”之类的话，还有用户（像我）会把内容里面的话复制到标题里，甚至有的用户干脆就输入一些乱七八糟的字符。总之这个标题的设计并没有给用户带来任何的良好体验，最为关键的是，绝大多的网站在站内信中是根本不显示标题，而直接显示内容。

站内信的发展趋势：

站内信在长时间内还是会长期存在的，它就像twitter弥补了IM与邮件之间的不足一样，是IM的先锋军，因为很多用户都是通过发送站内信向对方索取IM的通讯方式，所以它有长期存在的意义！

站内信不需要标题

千鸟 — 2008-09-22 02:22:01

站内信有两大特点，时效性较强，属于比较简短的沟通。三言两语基本能说清楚，既然不是长篇大论，就不需要再用标题概括。以前的经验表明，用户填写的站内信标题有三类：

打招呼，类似“你好”这样比较罗嗦的客套。
复制内容，为了图方便的无奈之举，来来回回就一句话。
废话，类似“问个事情”这样完全失去标题功能的浪费。

如果大家有可靠数据支持，不妨分析来验证。相应在收站内信时，一次性看完即可，不需要标题再提炼，也不需要点击标题阅读全部这么麻烦。

最早站内信是单通道功能，跟以前对讲机一样。为了避免沟通上的断层，逐渐使用“引用原文”功能。后来才出现的发件箱，再后来就是比较完善的“对话式”列表呈现了。

站内信主要的交互细节有如下几个，根据产品特性和商业需求来选择：

A. 发信时选择发送对象的处理。是列出好友翻页查找？还是下拉选择好友列表？或者直接录入、智能判断相应好友并选择？继续深入，将牵涉是否支持给多好友发送的问题。

B. 发送成功返回的处理。是直接关闭？还是返回进入页（个人资料、短信列表等）、固定页？或者过渡页？过渡页继续深入，又会碰到是否需要关闭、自动跳转、继续发送等功能。

C. 新消息提示的处理。不管是数字颜色，还是图标都会涉及两种设计模式；同时还可以选择信息提示框、真人声音，或者更豪华的任务栏tiitle闪动提示。作为运营方，希望用户赶快看到、赶紧删除减少资源消耗是肯定的。

D. 表单验证的处理。通常为资源上的考虑，都有字数限制，是否告诉用户？如何告诉用户？是否支持UBB编码和HTML代码？验证的出错信息等，都需要考虑周密，没有标题工作量也少。

控制好站内信功能，提供恰当的信息通道选择。比如淘宝例子，如果网友需要咨询产品，现在有四种方式，第一站内信、第二产品页留言簿、第三店铺留言、第四旺旺留言。

提供不同类型的入口渠道是对的，但如果都分类处理，会大大增加店主的管理负担，应该考虑汇总处理、分发显示。我在淘宝的站内信基本就是广告箱，最近广告比较少，我在想是不是骗子都不喜欢了，前几天也看到有公然写出“站内信收不到，请用旺旺留言”的店主公告。

百度发送新消息

flickr compose a new message

淘宝发送新信件

开心网发送短消息

相关话题：站内信源地址：http://blog.rexsong.com/?p=1202

北京书友会——站内信

冰桃 — 2008-09-21 23:12:31

秋意渐至，窗外雨声淅沥、行人匆匆。今天，UCDChina北京分舵相聚在奇遇花园，畅谈“站内信”

跑题部分不表，今天主要主持人是千鸟，引导我们讨论了站内信及相关种种，我就拣记得住的简要说说：

1 什么是站内信

2 站内信与一般邮箱的差别
内容简短时效性（系统自动清空过期邮件）标题是否必要，或者直接显示正文前几个字……

3 站内信与IM的差别
什么情况下用户会使用站内信什么情况下只是将它作为一个跳转到IM的跳台

4 站内信的发展趋势
IM？邮箱？还是视网站本身的性质而定，目前看来站内信有长期存在的意义

5 如何抑制站内信的弊端（如广告、骗子信息等）
关键字过滤，发信频率限制如何限制群发功能这里涉及到好友的定义和使用

6 站内信的本质
满足最基本的沟通需求，无需太多花哨功能，豆邮那样的聊天记录式是一个好范例

7 站内信的交互细节
诸如：从哪里进入发信状态、收到信后的提醒方式、发信窗口的打开方式（哪种窗口）、点击发送之后页面的切换方式（如何反馈发送成功），发信之后回到哪个页面。这里我很想推荐的是水木站内信的交互方式，尤其是term下的。

今天由于有某严肃婚恋网站的朋友在，大家重点讨论了相关话题；p
例如什么情况下鼓励发信骚扰，什么情况下是商业利益驱使……
结论是根据具体情况去鼓励发文（交友）或是提高发文门槛（豆瓣评论）
嗯看来没有绝对的真理，还是要根据网站的具体情况具体分析。

相关话题：站内信源地址：http://www.icepeach.cn/archives/28466