惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

大猫的无限游戏
大猫的无限游戏
J
Java Code Geeks
小众软件
小众软件
D
Docker
腾讯CDC
H
Hackread – Cybersecurity News, Data Breaches, AI and More
V
V2EX
博客园 - 叶小钗
GbyAI
GbyAI
Microsoft Azure Blog
Microsoft Azure Blog
Stack Overflow Blog
Stack Overflow Blog
B
Blog RSS Feed
酷 壳 – CoolShell
酷 壳 – CoolShell
博客园 - 【当耐特】
IT之家
IT之家
博客园 - 司徒正美
M
MIT News - Artificial intelligence
T
The Blog of Author Tim Ferriss
The GitHub Blog
The GitHub Blog
罗磊的独立博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
L
LangChain Blog
阮一峰的网络日志
阮一峰的网络日志
C
Check Point Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
经验分享丨启发式评估使用的7大法则
江鸟 · 2022-10-24 · via 人人都是产品经理

你是否会遇到产品将上线但是却不知道如何评估问题是否会发生的情况?面对这种情况,作者分享了一种经常用到的评估产品的方法——启发式评估,用自己的理解阐述启发式评估使用的7大法则,希望对你有所启发。

不知道你是否经常遇到这样的问题:

  • 设计方案出来后再用户测试前,希望发现一些潜在的问题。
  • 产品马上就要上线了,能否快速检验下有没有什么问题。
  • 刚入门的新手设计师的设计方案如何验证并且快速优化。

今天本文将介绍工作中经常用到的评估产品的方法——启发式评估。通过它应用的7大注意事项详细的阐述我对该评估方式的理解。

01 什么是启发式评估

1990年尼尔森博士提出的启发式评估指的是安排一组评估人员检查界面,判断其是否与公认的可用性原则相匹配,属于一种简易、通用的可用性测试评估法。

启发式评估主要依靠资深工作经验以及知识储备的评估者(最好非设计师本人或者与当前产品相关的项目中人员,避免陷入知识的陷阱)在可用性原则的基础上对设计好的界面进行评估,试图发现问题以规避。

它由于测试成本低且测试过程较为快速,在团队内部就可以完成该过程,因此也被成为“经济评估法”。

02 启发式评估使用的注意事项

2.1 启发式评估的使用不是万能的

启发式评估在产品设计和开发的任何阶段都适用,不局限于某个特点的时间段或者产品。只不过在原型阶段发现问题的话,修改成本最低,因为此时产品投入资源较少、风险最低。

虽然它有这么多优点,但是由于它不涉及真实的用户测试和用户行为分析,缺乏较为理性的数据支撑,在结果上受测试者的主观影响较大。

那么我们在什么样的情况下使用启发式评估呢?

(1)资源不足

当团队规模比较小,但我们最近想对产品做体验优化,这时候我们可以组织几名设计师一起参与对老产品的启发式评估,去发现需要改版产品的体验问题。

(2)经验不足

当作为一个小白刚入团队的时候,在做完手头项目后对已完成的设计稿可能并没有太大把握,需要检验方案的合理性,这时候可以找团队内较为资深的设计师帮忙,确保设计目标的完成度。

(3)时间紧迫

团队新来一个产品经理,提了一个看似不那么靠谱的需求,这时候作为经验丰富的设计老司机为了避免踩坑,需要快速验证一下产品需求的合理性,避免重复造轮子。

2.2 明确定义评估范围

启发式评估前需要对此次的评估范围做一个界定,是评估整个产品还是产品中的某一块,大多时候我们的评估范围仅仅局限于某一个功能或者某功能下面单独页面的某个模块,局部的评估可以让我们更加专注产品的体验。

我们需要把测试任务划分为多个不同的用户使用场景,这样评审专家就可以站在用户体验的角度,通过完成涉及范围内的任务,发现可用性问题。

2.3 选择合适数量的评估专家

并不是越多数量的评审专家越好,这涉及用人成本以及测试时间的成本。评审结果我们不能仅凭专家的数量堆砌,要靠专家的质量。

根据2012年尼尔森博士的试验证明,只需要5个人就可以发现85%的可用性问题,因为再多的人并不会带来更多问题的曝光率。真正重要的问题都已经被包含,对于普通的版本迭代基本上已经满足。

2.4 确保专家对评估指标熟悉

找专家过来前可以先召开评估的启动会,分享我们要实现的产品指标,以便他们在评估过程中熟悉产品,知道要做什么。

评估指标通常包含3个部分:整体性指标、项目指标以及流程性或者页面性指标。

(1)整体性指标

基于产品总体的整体性指标,主要针对一致性方面的指标。例如整体的视觉风格是否统一。交互逻辑是否统一。文案是统一。不同版本的延续性是否统一等;

(2)项目指标

针对具体项目的特定指标,是指除了通用性或者流程性指标之外,针对具体项目的特殊指标,这需要根据具体的项目去设定,做到评估标准的灵活调整。

(3)流程性或者页面性指标

页面体验中整个流程或者基于每个页面和步骤本身的评估。例如页面内信息的可识别性。页面内信息与真实场景是否一致,是否具有可理解性。用户是否可以进行正确操作。用户是否可以自由的选择操作方式允许用户出错等。

2.5 确保启发式评估原则与当前产品相关

提到原则很多同学第一印象就是尼尔森10原则,这个原则里面的预防错误原则、一致性与标准化原则、系统状态可用性原则等似乎成为了设计通用的准则,那么事实真的如此么?

假设我们现在做一个校园网络后台管理系统,针对该产品,我们首先应该关注什么维度呢?

首先应该是系统运行的稳定性,再者网络安全性我也很关注,其次是系统反应速度得快。那么作为对视觉有点要求的人,系统展示的样子是不是也不能太丑,否则会用不习惯。当然从专业的角度肯定还有其他更贴合产品的维度作为评判标准。

评判产品的标准很多,我们要有所取舍。虽然通用性标准在使用上肯定没有什么问题,但是如果我们站在更符合用户体验目标的角度去分析会不会更加合适。

2.6 建立合适的评估标准系统

启发式评估是一个发现问题的系统,建立可用性问题的评分系统可以帮我我们评定专家发现问题的严重程度。作为评估最后的输出,涉及了事后处理的优先级。根据问题对系统操作造成的影响,我们可以将可用性问题分为以下4个等级:

(1)轻微问题(1级)

不易察觉,视觉表现问题,改起来较为容易,有额外的时间可以修改,优化后可以提升用户体验细节。

(2)一般问题(2级)

可改可不改,偶然产生的可用性问题。它的存在会影响产品性能,但是不影响用户任务的完成,予以一般的优先级。

(3)中等问题(3级)

因为该问题会让产品学习以及操作体验变得困难,明显的增加产品流程中的跳出率,应该予以足够高的优先级。

(4)严重问题(4级)

显而易见的问题,它的存在会极大的降低产品的可用性,予以最高的优先级,需要立即解决。

最后我们可以通过表格的形式把问题界面截图、问题位置、严重程度、问题描述以及优化建议进行罗列呈现,因为我们不单单要发现问题,也要提供解决思路。

2.7 不要用启发式评估替代可用性测试

启发式评估是重要的但不是万能的。

在启发式评估内,我们邀请的测试者不需要像可用性测试那样是真实的用户。在测试过程中之所以采取启发式评估,往往时间与资源都很有限,所以需要我们找到相关的专家集中时间获得产品可用性问题上的反馈。

由于启发式评估过程缺少用户测试以及用户行为分析,结果往往没有理性的数据支撑,最后的因为评估标准多依据自身经验,受测试专家的专业背景影响较大,往往较为主观。

在工作中我们更多的是将两种结合使用,首先通过启发式评估发现用户可能会遇到的问题,然后为了验证,在时间允许的情况下通过可用性测试保证问题解决的精准度。

03 写在最后

以上是我对启发式评估的理解,有了评估后的结果,我们在评审或者后期方案阐述的时候更有说服力哦。

如果你对启发式评估有一些问题和思考,欢迎一起探讨~

本文由@江鸟的设计生活 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。