最近在进行面向设计师的可用性测试介绍，在涉及到测试计划这一部分时，布置了一个简单的作业：为TB新版收藏夹设计一个原型测试计划。从回收的结果看来，发现了一些比较典型的问题。在这里简单介绍一下方法和自己总结的几个注意点。

这是面向意欲执行可用性测试的设...

  因为这次旅行从西海岸到东海岸要订10多家酒店，于是频频逛各大网站。有好也有不好的体验，忍不住总结一下。

  首页面，各家几乎大同小异，但是只有这家有输入提示：



 这个功能是否重要呢？个人认为是重要的。虽然说拼new york拼错的机会不大，拼错了也通常有纠错功能，但是有些城市名不好记，特别对使用非本国语的客人来说。好像我们要在几个小城市什么Monterey，san luis obispo过路，有了...

1. Dumas, J. S., Molich, R., & Jeffries, R. (2004). Describing usability problems: Are we sending the right message?

2.Wilson, C.E. (2007). Please listen to me! Or, How can usability practitioners be more persuasive? interactions, 14(2), 44-45

做了可用性测试，总结了诸多问题，可是最重要还是被设计师、管理层等stakeholders理解并接纳。第一篇文章提出了四条沟通建议：

• Emphasize the positive. 强调正面因素

虽然可用性测试的主要目的是挑毛病，但开发者得到一定的肯定评价会使他们更愿意接受批评。

• Express your annoyance tactfully.有技巧地表达症结所在

尽量使用中性字眼，避免使用会引起开发者强烈情绪反应、或让他们感觉被羞辱的词语。例如“不专业”，“荒谬”等。

• Avoid usability jargon.避免使用可用性行话

使用直接、浅显的语言表达问题所在。 

• Be as specific as you can.尽可能地详尽

在颜色和字体的改进建议上，最容易出现模糊表述。

第二篇文章提出了增加说服力的几条建议：

• Do something truly positive for the product team—do not assume that the team will perceive a well-written usability report as something positive.
为设计组提供真正有建设性的建议，不要想当然觉得，设计组会认为一份文字功夫了得的可用性报告就是有建设性的

• Invite the product team and managers to critique your work (for example, the format and content of a usability report).
邀请设计组或管理层的人去评价可用性报告，例如格式以及内容

• Expose people continuously to usability and design issues through various techniques like blogs, bulletin boards, brownbag seminars, and “usability walls.”
利用blog，BBS，午餐讨论会，“可用性墙”等，增加同事们接触到可用性以及设计议题的机会

• Acknowledge good design as well as design that needs improvement. If you are sitting with a developer going over a user interface, be sure to compliment what is good about the developer’s work.
指出需要改进的设计同时，肯定优秀的设计。在与设计师一同评论用户界面的时候，记得赞美他们做出的优秀设计

  因为民国期刊是馆藏发展重点之一，所以经常帮老板找些相关电子资源。发现浙大的这个数字化项目做得不错，资源颇丰，阅读器比国家图书馆的要好用，图像质量也更高。可是网站本身的可用性有不少可笑的地方，例如我登陆后想看某本书，发现没有权限，系统的提示是：

“


对不起，您是CADAL门户的注册用户，您没有权限访问这本书。如果有疑问，请联系我们。


Sorr...