从用户心理谈QQ的设计缺憾.pdfVIP

从用户心理谈QQ的设计缺憾 发短信问某君 ：觉得Q Q有什么不好用的地方?答曰 ：平时 是聊天 ，没觉得有什么不好的。作为普 通用户 ，Q Q 的设计似乎无可挑剔。这里面有两层可能的原因 ：其一 ，其设计堪称完美 ，无可挑剔; 其二 ，用户已经适应了Q Q 自身的设计 ，所以感觉不出不好的地方了。 笔者的观点是 ，Q Q 的设计趋于完美 ，但并不是毫无缺憾;用户感觉不到Q Q 的缺点说明其设计已经 具有很好的易用性 ，但是不排除其中有用户习惯的因素。本文将围绕Q Q 的核心功能”即时通信”探 讨Q Q设计的美中不足——虽然这些不足在深度用户看来不是太大的可用性问题 ，并提出若干”锦上 添花”的建议。笔者会以一位新用户Leslie的视角进行讨论 ，以尽量避免用户习惯可能造成的影响。 石沉大海的好友请求——好友预留功能 Leslie刚刚申请了一个Q Q号 ，一个好友也没有。他恰巧得到一个朋友A 的Q Q号码 ，马上添加了他 。添加的过程很简单 ，最终系统告知需要对方确认好友请求。Leslie等了好几天 ，仍没有收到A 的确 认信息。A也许这几天没上Q Q 吧?或者没收到好友请求?或者A 忽略了我的请求(笔者按 ：忽略好友 请求 ，系统不会反馈给Leslie)?Leslie这样想着 ，决定重新发送一次好友请求。但是 ，他发现A 的Q Q号早就弄丢了! 　　思考和建议 好友请求如同扔出去的漂流瓶 ，直到对方确认之前 ，你无法在Q Q面板上见到关于该好友的任何 信息。但是意外总少不了 ，有时候你不得不再次发送请求 ，此时你已经没有了t a的号码——再要一 次吗? Q Q需要怎么改进 ，帮助Leslie解决这个问题呢?其实很简单 ，给已添加/待确认的好友设立好友预留 功能 ：在好友请求发送后 ，即在Q Q面板上添加该好友条目 ，并标明”待确认的好友”。此时 ，你们仍 然不是好友 ，当好友请求失效后 ，系统会提醒用户是否重新发送请求或删除好友预留(笔者按 ：请 求失效包括请求被忽略导致的请求过期 ，单纯的请求过期 ，请求被拒绝;但是如果 是请求被忽略 而请求本身没有过期 ，则不反馈给Leslie);若对方接受好友请求 ，则将该好友添加至相应的联系人列 表内。 你邀请朋友到家里吃饭 ，事先都要根据人数摆好座椅 ，虚位以待——Q Q好友预留功能跟这种情形 非常类似 ，在好友确认请求之前 ，系统已经为该好友预留了座椅 ， 等着人来了。 　　图片发过去了吗?——用户对信息对 性的需求 Leslie成功添加了几个好友 ，他开始兴奋地跟美眉B聊天。Leslie发现一张很美的图片 ，他立刻发送 给了B。但是少许之后 ，B却说图片发送失败了 ，看不到图片。Leslie很纳闷 ，因为他这边明明看到 图片成功显示在了自己的聊天窗口内。后来Leslie慢慢知道 ，自己看到的未必是对方看到的 ，有时候 网速过慢 ，图片就有可能发送失败 ，而自己却看不到。之后Leslie养成一个习惯 ，每发送一张图片 ， 他都会问对方 ：发过去了吗? 　思考和建议 Q Q提供给用户的是”即时通信”服务 ，这里也包含两层意思 ：”即时的”和”通信”。”通信”就是沟通 ，沟 通要求双方要表达的文字/图片等以”无损”的形式传递给对方 ，在此基础上的沟通才能顺畅。联想到 日常生活中的打电话情境 ，有时这边能听到对方的声音 ，但由于网络原因 ，自己的声音却传送不到 对方那里 ，这就会造成信息不对称 ，沟通效率继而下降。Q Q发送图片功能的交互设计应当考虑到 这种应当的信息对称性 ，避免图片发送者误以为图片发送成功而事实上图片并未加载完毕或加载失 败的境况。 “即时的”意味着信息的即时和同步可见 ，这并不是说图片要”立即”发送完毕 ，而是指图片的发送状态 要即时/同时呈现给双方。在目前的Q Q设计中 ，即使最终图片加载成功了 ，图片发送者也并不知道 加载完毕的时间 ，这也会造成沟通不同步的问题。因此系统要保证图片发送者和接受者同时看到图 片发送了百分之几 ，以及最终的发送状态。 其实 ，Q Q 的文件传输功能就是这样设计的 ，而大多数手机彩信也支持发送状态提示和反馈。 　空白的聊天窗口——用户对沟通连续性的需求 Leslie百无聊赖地查看了一下最近联系人列表 ，最近他跟很多好友有过交谈。他决定再跟好友C聊聊 。打开聊天窗口后 ，Leslie一时不知道该如何开始这次聊天。他其实很想知道他和C的上次交流是在 什么时候 ，最后都说了哪些话 ，这样或许能找到一些话题。可是聊天窗口内一片空白 ，他 好点击” 消息记录”按钮查看两人的聊天记录。 　　思考和建议 Leslie遇到的这