启发式评估(貌似等同于专家小组评审)这个方法听得比较多,而系统的实际操作经验很少,大部分由于时间关系都只是直接需求评审,逻辑上没大问题就ok了.

本周产品小组的一个产品使用了这个方法,效果还挺好~不过普通只要在时间允许的情况下,由于依赖质量较高的原型设计人员前期的分析.

以下是最近学习的关于启发式评估比较详细的引见和执行步骤(好玩的是材料来自于”通晓Web Analytics“这本书;另,此方法同样试用于客户端产品)

启发式评估的步骤

(1) 使用次要的研讨(调查)来理解那些客户在站点上完成的核心任务,这里有一些场景示例

• 发现站内最热销的产品信息
• 找到和我居住的地方离得最近的商店
• 用PayPal在站点上放置订单(如果站点不接受PayPal,那么客户如何能容易并快速的发现这点?)
• 检查站点上我的订单的提交形状
• 成功的通过电子邮件与技术支持进行联系

(2) 接下来,为每个任务确定成功的标准(例如发现热销产品的信息的成功率为95%).

(3) 像用户一样,完成每个任务,记录体验过程中次要的发现-从完成任务需求花费的时间,到需求采取的步骤数目,到完成任务遇到的妨碍等所有问题

(4) 对违交互规范/产品规范中特定规则的行为进行记录

(5) 针对发现的问题创建一个报告.对Web页面进行截图,并清楚标明发现的问题

(6) 将建议按照紧急,重要和普通进行分类,这样有助于业务决策者确定优先次序.提出的改进建议无需考虑技术可行性(可能此处会有争议)

启发式评估的好处

• 启发式评估实施起来极快,在很短的时间内就能获得认识(从效果来看,结果确实优于往常的需求评审会议)
• 它可以利用公司内已有的资源
• 可以确定站点上最异常的客户问题(通常是所有的最低可接受目标和两头目标)
• 在网站开发的晚期,就可以无效的使用它来发现潜在的妨碍
• 它可以通过协助确定明显的问题来降低完整的可用性的测试成本,这样可用性测试就可以努力于处理隐藏的更深或者其他更艰难的挑战

启发式评估需留意的

• 通常由公司(或以外)的专家来领导启发式评估,他们利用最佳的实践和本身的经验,但他们不是我们的客户
• 如果来自于启发式评估的建议不分歧,则可以将它作为可用性测试很好的信息输入
• 启发式评估在优化任务流,网站设计和站点的全体可用性方面是效果最好的(这点体验比较深刻,确实将一个流程较长的任务链缩短了不少)

最后团体补充下,启发式评估的会议掌管人一定要留意保证会议方向(当然,这个对于产品设计中的很多环节都通用,如可用性测试),不要过早和过多的堕入细节的讨论.应从任务链出发,先确认全体流程,然后再确认环节,而最终各个任务交叉后依据优先级组合生成界面是最后再讨论的.