站内信不需要标题

星期一 09.22.2008 - Posted in 互联网产品设计, - 5,338 views
站内信有两大特点,时效性较强,属于比较简短的沟通。三言两语基本能说清楚,既然不是长篇大论,就不需要再用标题概括。以前的经验表明,用户填写的站内信标题有三类: 打招呼,类似...

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

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

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

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

开心网站内短信

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

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

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

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

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

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

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

百度发送新消息

flickr compose a new message

flickr compose a new message

淘宝发送新信件

淘宝发送新信件

开心网发送短消息

开心网发送短消息

© 一叶千鸟(转载请留原文链接,更新于2008年09月22日17点)

12条评论 发表»

ejan says:

discuz6.1 7.0的短消息搞得跟真的似的,太难用了,提了半天意见人家UI TEAM跟本不吊你。不过我现在灰常喜欢开心网的短消息的设计思路。让他们参考开心网,不知道他们会不会学习人家长处。

一巨简单的事情非要搞的巨复杂。

千鸟 says:

就是blueidea的程序吧,那个确实麻烦。
站内信就是普通沟通,既不需要归纳标题,也没必要打腹稿。

guwei says:

真有道理。开心网的很多地方都蛮人性化的。

JunChen says:

除了站内信还有其他很多都不需要标题的 只是被很多人“习惯性”的保留了

Summer says:

反正使用站内信时,我通常不会写标题。就像使用手机短信,没人会为短信写标题吧。

千鸟 says:

对于某些不太理想的设计,为了给发送对象更好的体验,如果标题能说清楚,我尽量在标题说完,内容“如题”;如果事情稍微复杂,还是得考虑个比较得体的标题。

麻烦自己,也不能麻烦对方,这是设计师的原则。

idwalker says:

刚看到这个标题的时候,就觉得够了。确实不需要,麻烦,不值得。
很多时候,我们对于固化的问题都会视而不见了,习惯了。好用不,不好用,怎么办?不知道。
我觉得除了交互设计师(或者体验设计师)能够创造性的提出革新之外还需要一些规范的分析和实验方法来验证和优化。

闲耘 says:

确实,我一般写站内信都是写完标题,然后内容是“RT”。
觉得论坛回复带标题也很多余,还不如现在的线性评论(Thread Comment)。

发表评论

Spammer必读