以用户为中心的设计 |
|||
|
大致回顾一下9月21日南京UCD书友会的讨论话题：站内信。 从好的站内信设计开始讨论（虽然没有发现很出色的站内信设计），然后是“站内信解决了什么问题”，分清了站内信的需求层次，最后给站内信下了一个较 为完整的定义：一个网站的用户向其他用户发送的具有一定即时性和一定私密性的消息。所以站内信的设计，便是提供满足这个过程的功能。 在书友会快要结束的时候，我忽然觉得我们陷入了功能规格的漩涡，整个下午的收获就是给站内信下了一个定义！虽然这个定义还挺像样的。（这个定义抛弃了网站发给用户的通知，认为是借尸还魂，此处仅一提，略去不谈） 从使用情景上思考 站内信是一个很特殊的话题，特殊的地方在于它像是大部分网站的标配功能。这个特殊性，很容易让我们陷入功能本身的讨论中去，而不展开并深入到用户层 面。怎么讲呢，用户才不会管你是叫站内信，还是邮件，还是短消息，还是留言等等。重要的是当用户想起要给其他用户发消息（见顺带一提：粒度的问题）时，有 一个按钮、有一个链接在那里，能满足这个需求。 大部分用户（哪怕是专家）都会选择成本最低的方式来操作。比如我给你发个私信，你很大可能使用私信回；我给你打个招呼，你很大可能不会用私信回。同时，当你想发消息给我，必然会选择成本最低的方式，比如头像边上正好有一个发私信的链接、或者正好在看一篇日志于是回复之。 还有些相反的（退出使用）情况。比如，当我发短信给你，你觉得短信沟通成本过高，于是直接打电话。这种情况同样可以对应到站内信中。又比如，我给某 MM站内信（为什么不用留言，是因为留言没有站内信私密，见下文“私密性”）道：美女，QQ号多少？于是就放弃站内信而使用QQ了，因为站内信沟通成本太 高。 于是这就涉及到用户对这个功能的期望。这点在书友会上有提及，我们分两个维度：即时性和私密性。对私密性没有要 求的，用户会选择在个人资料页上留言；对即时性有很强要求的，用户会选择换IM（如果可能）。这话说的不严谨，应该是交叉的四个象限来看，这里简单点就略 了。然后，并不是越私密就越好，也不是越即时就越好，这里面有一定的层次。 顺带一提 粒度的问题：发消息已经是很具体的意象，再往上就是更宽泛的沟通层面。谈到沟通就会涉及到内容的形式，比如文字、图片、音频、视频。本文讲发消息，特指文字。 即时性的问题：很多朋友会觉得站内信没有即时性。这需要看站内信是怎样推送给接收方。在接收方在线的情况下，能即时PUSH站内信，就是即时的，这 也就是站内IM的雏形。接收方是否在线，不能作为评判标准，因为IM也有离线消息，但不能说IM不是即时通信。我们以木桶的最长边来看待这个问题。 站内信的扩展：有朋友觉得做个动作是站内信的一种外延。对此我持保留意见，理由就不赘述了。不过，打招呼还勉强能算。 对设计的帮助 用户想要的是发个消息，而不是去用站内信功能。我们不能为了讨论站内信而讨论站内信，也不能为了设计站内信而设计站内信。一心想着提高即时性等特性，却忽略了需求层次。 把未来的情景描绘出来，而不要陷入功能规格的漩涡。针对情景中不同的需求层次、期望，通过不同的途径（界面和功能）去满足。招呼、站内信、通知、留言等等如此应运而生。他们的存在有一定道理，但我这里提到并不是说在你的SNS产品中就必须得有这些功能。 考虑成本问题。一方面是经济成本，在此次书友会上讨论到的BP机被手机取代的例子，就是因为手机短消息成本很低。另一方面是接入成本，用户会使用马上能用、在手边的功能，而不是到处找站内信在哪儿。 把未来也同样描绘给用户。需要以显性的方式告诉用户，使用这个功能能达到什么效果。比如站内信，需要提示用户对方会怎样收到提醒、在哪里看到内容，等等。这样可以有比较一致的期望（即时性、私密性）。 -- 以上。 记述的稍微有些乱、罗嗦。希望读者能够明白，欢迎参与讨论。欢迎来参加 UCD 书友会。 另，站内信话题还可以写以下文章，欢迎各位参与：
|
