blockscout环境变量详解（可用性测试你不知道的Buff）

编辑导语：可用性测试，能够让产品经理借助用户，更加客观理性地理解产品功能以及交互，并结合测试结果予以改进。每个产品的迭代都需要进行可用性测试，可以说“可用性测试”是交互设计中进行验证必不可少的环节。本篇文章分享了一些不一样的“可用性测试”技巧，希望对你有所帮助。

之前群里的设计师提起了可用性测试，说面试的过程中被问到了，其实它的流程跟方法并不难，网上的教程资源也不少，很多参与过或了解过的人即使没有主导过却也能说个一二。

哪这门蕴含科学的测试研究方法真就这么简单? 借着这个机会结合个人的一点小心得，来聊一点不一样的“可用性测试”技巧。

一、可用性测试的应用场景与作用

可用性测试(Usability Test)的应用场景是没有行业的明确界定的，它一般发生在产品研发上线的前中期，在功能或交互流程有待商榷之时，通过可用性测试可以获得更加真实的反馈来帮助决策或改进。

当然已上线的产品，同样可以使用可用性测试为下个版本优化迭代做投资。

其中探索式跟验证式是常见的两个可用性测试类型，探索式适合企业对产品进行创新设计以迎合新时代发展的步伐与商业竞争力，验证式适合企业追求精益运营或增长设计。

对于可用性测试的概念，这里我用一段类比的情景来揭示出其中奥妙。

做好一个饭馆，而菜品必定是馆子的核心竞争力之一，菜不好吃，那就很难形成竞争力或留住客人，所以开发新的菜品或改进就很重要。

当厨师开发了新的菜品后，首先肯定是厨师们互相品尝，并不会直接上菜谱开售，这就像是内测过程，当厨师们觉得还可以时，就会找食客们进行免费试吃，通常这个时候厨师们需要食客们给出反馈或一定意见，如果食客们大多表示这个菜不错，下次还愿意吃，那么就是表示这个新菜品的可行性很高，用户满意度不错，就可以考虑对菜品优化上菜谱了。

而这个过程就像可用性测试一样，它为新菜品上菜谱降低了风险，为菜品对菜馆整体体验提升了保障，其中“菜馆的食客”就像是测试的目标用户，请求他们尝试新的菜品并给出意见，这便是招募用户和测试阶段，询问食客是否还会再点这个菜品，觉得这个菜品在什么价位区间，就算是对用户满意度或可行性衡量了。

相比专业可用性测试，只是少了更多的测试流程、测试技巧与科学严谨的分析汇报，但是基本概念是一致的。

但值得注意的是针对单个菜品的研究并不是面向整个菜馆的，可用性测试很少用于研究用户对产品或服务的整体体验。

所以可用性测试的本质就很好理解了，以互联网产品为例，其实就是服务数字化后的功能与流程含有不确定性，而决定找到目标用户还原使用场景进行测试验证，以评测设计是否行得通、哪里需要改进，为功能上线减少风险加强容错，减少试错的成本。

二、高保真原型与测试场景还原

要测试就得有测试内容，所以测试对象是必不可少的内容，这个过程是我们还原真实用户在特定场景下进行产品体验的一系列问题反馈，那么为了尽可能的还原“真实”，肯定不能只是在用户的真实性上下功夫，接近真实的高保真原型就显得尤为重要。

以互联网产品来讲，还原一个可交互的高保真原型并不难，成本也不会很高，可能就是信息内容设计与素材准备会相对麻烦点，对于交互动效，基本可用就行，不必过分追求。

并且实现的工具也很丰富，对于大型框架原型可以使用“墨刀、MasterGo、AxureRP”等制作，小型精致的原型可以使用“Principle、Hype3、Flinto、Sketch、Keynote”等制作。

反而是工业产品设计的原型会比较麻烦，有的可能要出3D打印甚至开发测试样品，尽管这些工作会花费一定的时间与成本，但是从产品稳健发展的战略来看，这些投资是值得的，也是老板们可以接受的。

在大多数的可用性测试文章或教程中，用户都是在一个相对降噪的会议室或实验室进行的，其目的是为了更好的布置设备用于过程的观察与记录，同时为用户测试减少干扰与评估难度（其实也省钱），但事实上还原产品服务的真实场景是很有必要的，并且一些产品服务自身就会含有一定的场景属性，所以你的测试环境就应该考虑接近真实场景的布置，甚至考虑跳出会议室、实验室。

这样的目的也是为了更加真实的还原使用场景，以取得更严谨科学的有效信息来赋能设计，这也是为什么大多数产品需要上前线测试的原因，就像药品诞生于实验室，上架于临床一样，例如出行、运动相关产品，如果依旧停留在写字楼里测试实验，那就是闭门造车。

三、任务与指标定制化设计

产品的本质是为用户提供服务，用户会为了达成自己的某个目标或需求而花费时间使用产品，而我们需要用户测试一系列功能来评测是否能够协助完成目标任务。

所以我们在设定不同任务的时候应该以某个用户需求或目标为导向来驱动用户使用产品功能，而不是系统的指出完成那些操作任务，那样没办法深入挖掘真实有效的信息。

所以在向用户颁布测试任务的时候，我们应该为用户建立一些任务背景，并且尽可能看起来真实可靠，容易接受和共情，甚至你可以在测试前的暖场环节，根据此次的功能作用推导一些使用场景和需求，并与用户进行简单交涉，看看那些需求很有可能发生在用户身上，并以此需求目标来调整任务的话术来驱动用户完成测试。

值得注意的是如果测试的部分比较明确，那么你的任务目标也应该尽可能的聚焦或明确下来。

好了，为了方便理解我要说人话了。

（1）重点补充

因为在整个测试的过程中，参与测试的用户不止一个，所以在了解用户情况后，可以综合一下共同的特征再去提炼优化任务目标，以保证在多个参与者中维持评估的一致性。

并且任务目标应该尽可能的准确有效，我们是要测试新的拍摄识别功能，那我们就应该要求出来，而不是说看完书后使用APP的笔记并尝试各种功能支持，产品或功能所没有的就不要提。不保证有效性，最后也只能让用户感到困惑而已。

通常完成测试任务的过程中，会涉及到多个功能之间的交互，所以任务目标涉及的多个阶段应该贴合实际的操作顺序或流程规范，另外尽可能的避免专业术语的出现，务必考虑“适老化”一下。

（2）关于指标定制化

通常在可用性测试中，是否可用的指标被划分成了三大面：有效性、任务效率、满意度，对于这三方面我们可以继续细化成若干个二级指标用于界定产品可用性。

至于你家的产品是什么行业、什么阶段、什么用途、有何特性，应该满足哪些指标为可用，我就不深入了，相信大家心里都有数。

简言之核心就是考虑产品的特性与阶段，灵活的配置可用性的指标，这里整理了些常见的指标与说明用于参考。

四、用户测试中常见的问题

尽管我们有测试脚本甚至测试排练，已经尽可能的保障了可用性测试的稳定可靠，但实际上在用户测试的阶段还是会出现各种问题，用户像一个熟睡的婴儿，何时醒来何时哭泣不可预见，所以这就要求测试的主持人能够灵活变通，同时在技巧上符合可用性测试的科学严谨。

可用性测试过程中的科学严谨一方面体现在方案的合理性、测试主持的技巧上、及评估分析量化的方法上，这些大多可用性测试的文章或教程中都会提到，这里就不展开啰嗦了。

常见问题举例：

1. 他似乎在想些什么但是没有说出来？

你在想什么可以分享一下吗？

2. 用户好像卡住了或遇到bug了。

这没事儿，是我们产品设计的问题，你可以考虑跳过这一步好了。

3. 就是这个，它怎么就那啥了？表述不清。

你刚刚打算做些什么，如果是你，你准备怎么去设计？有没有一些参考。

4. 然后我要怎么做呢？

对于用户提问说明遇到了障碍，尝试反问你平时会怎么做？

5. 用户反馈了一些趋势或点子，看起来很有价值。

尝试深挖，顺着点子或趋势向用户多问一点，但是不要直接问“为什么”，可以尝试问好在哪里或者哪里不好，让问题更有头绪一点。

以上不难看出，即使有了脚本，但是用户依旧是一个变量因素，所以脚本依旧需要不断调整，也只有去调整才能更好的保障测试结果的有效性，同时主持者也需要随时准备灵活的应对各种幺蛾子。

五、创新与颠覆性设计如何测试

可用性测试被很多人视为评估体验的制胜法宝，但实际上很多产品在行业中已经逐步成熟，并有大企业花费大量资源进行研究摸索，让生态系统更进一步，所以说要是你的产品没有特殊的创新或瓶颈，而是传统的功能研发，其实并不一定要花费成本去做可用性测试，直接按照行业标杆也是没问题的。

那么你的产品就是有创新或颠覆性设计怎么办？

通常这个时候就会面临一个问题，打破传统或者颠覆用户的常识。类似这种颠覆式或创新技术其实非常多，例如按键手机一下到了触屏时代、智能驾驶、语言助手的诞生、刷脸支付等，这对企业是机会也是风险，所以在进行可用性测试的时候也会有些不大一样的地方。

我们悉知在可用性测试的三大指标中就有一项是“效率”，对此也会有一些完成任务的时间作为指标，这些指标通常是根据内部人士或专家完成任务的时间乘上2倍或者更多倍做为一个评测指标。

但是对于颠覆性的变化，我们需要给用户首次测试留出更多的时间去学习去适应，在此之后，可以让用户再进行1～2次的测试，并且比较多次任务完成的时间变化，如果时间能够大幅度缩减且完成任务，那就表示可用，而这样做也是为了保障测试的科学严谨性，以避免学习门槛对创新性的评测影响。

六、多版本Battle你需要小型可用性测试

可用性测试需要招募用户进行测试，预算时间精力可谓一项都不能少，但是大多公司的窘境却是公司小资源又有限，又不给预算招募，可用性测试做不起来？内部产出版本过多，不知何去何从？别担心，小型可用性测试了解一下！

1. 什么是小型可用性测试(Small Usability Test)？

小型可用性测试就是在标准的可用性测试的基础上减少了一些流程与要求，这就像是大公司与小公司之间会有各自的研发流程一样，两者各有千秋，对应公司规模与背景对症下药。

在小型可用性测试中，也有脚本、简易的暖场、用户定义、测试目标、测试任务、测试原型、测试参与者、测试观察、思考总结，更多的也是发生在功能上线之前的推敲阶段，它比较适合设计师在自测阶段后的验证以及多版本Battle，帮助你Pick一套更加合适的方案。

但是整个过程相对正式可用性测试会更加简单易行，其中价值观念与目的都是一致的，都是以用户价值与用户目标来驱动（使用动机）使用产品，并且观察用户的使用过程以获取有效的反馈来改进或决策。

不过呢，脚本会更加简易一些，原型材料也不用那样精细，主要能表达功能作用与信息流程为主，其中测试者更多的是寻求那些关心我们产品或有需求的用户，另外也不会准备那些知情书、协议、录制设备、测试指标啥的，更多的是寻求熟人或哪些有意向的用户快速进行测试并观察，这样不仅时间成本都节省了，难度降低了，也能拿到一定的有效测评结果。

基本上主要的实践步骤就这五点，还有一些布置会穿插在其中，后面代入案例讲解一下。

2. 案例代入讲解

便于直观的了解和感受小型可用性测试，这里代入一个老案例讲解一下，关于案例背景这里简单交代一下。

（1）背景

平台服务于游戏相关的订单交易、互动娱乐，本次测试的内容是新的游戏订单定制服务，通过推出一批专供用户定制游戏服务的客服来完成沟通与定制下单，其价值在于帮助用户快速了解平台游戏服务以及快速定制服务并完成下单转化，以沟通的方式减少用户下单的操作流程与门槛。

（2）任务流程

设计服务入口与流量分发->用户选择心仪的小鱼（专供客服的代称）->进入小鱼的会话界面->沟通需求目标->小鱼制定用户专属服务订单->用户支付确认->转到订单流程

为了加快讲解和体现测试的价值与方法，这里就不跑全套流程了，就以小鱼入口的设计与流量分发来代入讲解，测试前提是聊天会话界面中已经集成了“小鱼”所受理的主要游戏业务介绍，以及快速下单的入口。

当然一般都是在用户向“小鱼”倾述目标需求后，由“小鱼”进行服务定制，并向用户发起订单等待用户确认支付，之后便是等待订单完成到验收评价，平台转交佣金。

（3）首先定义用户与目标

在这个测试任务开展前一定要知道开展目的是什么，然后就是这个过程中你的功能或产品是为什么样的人服务，能为他们带来什么样的价值，也就是前面一直提到的价值与目标驱动用户的概念。

为此你可以建立一个简易的用户原型来定义用户的特征属性，使得目标群体再具体一些。

然后将小鱼的服务价值写出来，让参与者能够快速知道小鱼功能有什么用：

（4）创建适用于目标的测试任务

对于测试任务的创建，应该是围绕目标的。

根据流程的多少或复杂程度，可以划分为多个阶段，这样具有阶段性会更好控制测试节奏或分段进行，然后就是将多个任务按照流程顺序或是操作难度排序，目的是使得任务流程正确或是用户接受起来更容易。

当你把任务清单罗列出来后还不算完，这套清单你可以放在脚本里，但是当你描述给用户时，你应该代入对方视角去描述并且带有目标性，所以还需要进行一次调整后应用：

（5）找到合适的测试参与者

关于参与者我们会参考第一步中所设定的用户原型，不需要全部中标，但至少这些人要看起来会用得上你的产品才行，通常这些人建议通过熟人关系去寻找，甚至可以是你的同事，只要他们对产品没有额外的偏见，且不是相关设计者、营销运营者或技术研发人员，因为这些人对该领域的知识掌握甚多，有失真实性。

当你找到这五六个接近真实用户的参与者后，你只需要将起初写下的“功能价值阐述”告诉他们，让他们知道要做一个怎样的服务测试，然后预约他们在不同的时间节点上花费半个小时来做一个简单的功能测试即可。

（6）观察参与者如何执行任务

在这个阶段，你需要保证已经准备好了测试原型，以及一份脚本，脚本中会规范以上的功能价值、测试任务、一些简易的指标、关注要点、暖场介绍、流程顺序等。

然后你要找一个相对安静低调的测试场地，不一定是会议室，不用很大空间，一个桌子两个椅子和一些必备的材料即可，但不要有一些产品相关或商业的痕迹，会形成干扰。

在测试开始前你需要将测试原型初始化，以确保每个参与者测试的一致性。

在暖场和任务布置完成后，就是测试者的Show Time了，主持者可以拿好自己的小本本或者录音笔，认真的观察测试者的操作或口述反馈，当测试者遇到一些问题不知所措时，也不用着急指导，告诉测试者先按照自己的认知或想法去做就好。

如果测试者在一个地方卡了好几分钟，没有一点头绪甚至感到受挫那就让测试者先跳过障碍，避免整个测试节奏失控。另外记得提醒测试者口述反馈，这很重要。

当在计划的时间段完成测试后，就为测试者送上准备的奖品，寒暄几句后送测试者去休息或离开，然后对材料或记录进行简单整理后，准备下一场测试。

（7）思考与总结

在完成一轮简单的小型可用性测试后，通常一定会拿到一些有用的反馈，可能有些零散还需要进一步的整理，但这不影响最后的分析结果，为了方便验证和整理，我们会提前把一些重要的问题点罗列出来，然后根据测试者的反馈进行记录归档。

最终当你完成了这些测试及反馈信息收集以后，产品方案中究竟哪里出了问题应该就了解的差不多了，一些比较明显的问题甚至会被测试者多次提及，或许是页面信息不被理解、交互难懂、提供的内容不受测试者喜爱，亦或是测试者都认可、设计亮点被用户亲睐。

尽管会发现一些跟我们预期不大一样的结果，但都是正常的，值得注意的是，我们应该结合这些数据进一步的反思，究竟这些反馈有何含义有何价值，哪里还能优化，基于不用的产品服务或受众，反思点可能会有些不同，这里我泛举一些；

最终呢，我们也是通过测试取得一些有效的反馈，并根据反馈深思了更好的设计方案，我们对小鱼卡片的信息进行了丰富以保证可比较性，将每批三个小鱼卡片扩展到了8个，用户可以通过横向滑动查看更多，同时为了方便用户更好的换到下一批，在最末尾给予了滑动换批次的交互，使得用户可以一指滑动到底完成查看与换批次的交互衔接，在之后的验证测试中也是获得了测试者的认可与看好。

相信说到这里，怎么做好一轮小型可用性测试已经了解了，当你完成了这些测试任务，一定记得不要忘了后续的反思与优化迭代，甚至制定后续的研究计划。

七、多版本方案如何可用性测试

有时候设计产生多个版本也是在所难免的，那么对于多方案是应该将内部推荐的拿出来测试，还是应该直接两个版本一起拿出来，两个一起会不会因为采集量过少不准确呢？

这里我们再说说有多个版本怎么做好测试计划与分配，当有多个版本准备可用性测试时，如何制定测试计划还要看版本数量、版本差异化这两大维度，力争做好有效且不费力。

如果说在设计过程中产生的多个版本差异不大，那么都进行测试的必要性我认为不大，通过在商业价值与用户体验间做衡量，选择一个更加符合产品阶段的方案进行可用性测试即可。

但是如果多个版本差异较大，难以决策且不确定性较大，那么第一件事就是经过一轮决策将版本减少到两个左右，然后再进行可用性测试，对于此类情况基本上有两种方法进行分配测试；

1. 将版本分为两组进行测试

如果说直接分成两组进行可用性测试，那么需要数据样本会更大，数据采集量过少确实会有不准确的可能，因此直接分成俩组进行测试的话，会需要招募更多测试者和测试准备，但同时可能会有意外的惊喜。

往往我们以为的，可能会在测试者那里收获意料之外的反馈，这将允许我们以真实用户的视角去挖掘价值或决策，避免内部短视而埋没了好的设计。

2. 一组人员测试两个版本

相比分多组测试，一组人员测试两个版本在成本上会更有优势，但同时会面临两个版本测试的前后顺序影响，要知道第一个版本会对用户形成更多印象，甚至产生一些偏好，所以为减小测试结果的偏差，我们会将测试者分为数量相同的两组，并安排两组不同的先后顺序进行测试来打破僵局。

八、测试结果的量化或汇报技巧

测试结果量化的目的在于更好的衡量可用性在怎样的一个水准线上，同时便于整理复盘整个测试过程，并将结果更加直观的展现出来，便于同事们了解。对于测试结果量化有两个方面；

一方面是将整个测试过程中收集到的各种问题反馈进行分类整理，并用数据图表现出来，这样能够很直观的展现问题缺陷与突破口，同时能够快速体现测试价值，或者说你进行可用性测试为业务带来的价值。

另一方面则是通过面向用户的问卷调查获取可用性测试量表，最常见的标配问卷即ASQ(任务后评估问卷)与SUS(系统可用性问卷)。

除此之外还有专门面向网站产品的WAMMI(网站分析和测量表)、SUPR-Q(标准通用的百分等级量表，但是获取有效的百分比数据需要购买服务，所以不额外介绍了，有兴趣的自己百度下)，以及面向APP使用体验的SUPR-Qm(APP用户体验量表)，在说明这些量化表怎么使用和定义前，我需要额外说明一些量化表的概念，这很重要！

1. 可用性测试量表标准

作为一个合格的标准化量表至少需要保障以下几点：

（1）可信度

对同一对象测量得到的结果是否一致，这将直接决定问卷获取的结果是否能可靠，可以通过重复测量信度和分半信度测量， 测量出的信度会在0～1之间，越是接近1的可信度越高，因为量化结果会被直接引用，所以信度至少高于0.7才比较有意义，不然一个半信半疑的结果真的充满风险。

同时以上我提到ASQ、SUS、WAMMI、SUPR-Qm这四个量化问卷也都是经过业内长期试验与验证后信度较高的靠谱问卷模式。

（2）有效度

主要理念在于是否密切关注到了你所在意的问题点，以及问卷问题是否与验证系统有关联性，对于效度也有效标效度（皮尔逊相关系数）和内容效度（因子分析）两种评估方法，不过并不一定要有很高的系数来证明很有效。

（3）灵敏度

指达到统计显著性所需的最小样本量，例如一个水果偏好二选一问卷，你问两个人可能是答案A，但是你问完10个人后却是B，当采量过小没能达到统计显著性所需最小样本量时，可能会获得不够准确的答案。

（4）客观性

一份问卷应该保持客观性，不能携带编辑者的个人偏好或主观意愿影响，这会让问卷有失统一性。

（5）重复性

尽可能的使问卷框架结构能够复用，一方面便于更多人可以研究验证，另一方面可以使得问卷本身价值最大化。

（6）可量化

对于问题的答复最好进行量化处理，而不是单纯的是或否，目的在于可使用高效的统计学方法来理解结果，或进行对比，亦或是数据可视化体现更加精密的差异。

所以说开发或调整一套标准可用的度量问卷也是一门富有学问的技术活，并非简单问几个问题这么简单。

2. 任务后评估问卷(ASQ)

也叫场景后问卷，一般在可用性测试完毕后进行，它可以直观的在任务难度、完成效率和帮助信息上获取到测试者的直接反馈，主要就固定三道题目，答案采用5分制或7分制，所得分除以总分即可得到一个均分，该分值至少要大于0.6才能合格，要获得大部分人满意或认可，则要高于0.7。

3. 系统可用性问卷(SUS)

SUS总共10题，奇数项是正面描述题，偶数项是反面描述题，答题采用奇数的5分制。SUS益于它正反向问题结合，以及具有泛应用的可用性与易用性题型，在业内具有大量应用数据为基础，不论是客观性、灵敏度、可量化还是信度都具有较高的水准，这也是SUS能够成为可用性测试后问卷最主流的原因。

（1）SUS量化分数计算

在SUS的相关创建者经过对大批数据的研究，其中可用性部分量表信度为0.91，易学性部分可行度为0.7，为使得整体量表得分兼容在0～100的范围，最终需要对可用性量表总分乘以3.125，易学性量表总分乘以12.5。而经过长期的应用迭代，最终分数的计算方式进行了定格：

1. 步骤一：所有奇数编号题目得分减一后相加；
2. 步骤二：所有偶数编号题目得分由五减去后相加；
3. 步骤三：将奇数项最终得分 偶数项最终得分后 乘以2.5 即最终SUS得分。

（2）分数值概念

在经过创建者的研究与沉淀，最终构成了5层不同级别的评级，A即最优评价，并且对应0～100分，有趣的是5个评级并非是将100分平分，为了解释评级与得分的强关联性，创建者新增了第11题进行整体而言的数据收集与分析，最终得到了以下图中所对应的关系。

如果说结果是“Good(C)”，那么对应的平均分值则是“71.4”，如果说你的得分高于85.5分，那你的评级则处于“Excellent(B)”，这可能已经意味着你的产品优于绝大部分产品了。

4. 网站分析和测量表(WAMMI)

WAMMI的建立是为了专门量化网站产品的，该问卷一共20道问题，采用5分制回答，整体信度高于0.9，但是吸引力、可控性、效率、帮助性、易学性多个因子测试信度只在0.63～0.74，因此该问卷对测试样本要求不少于30个。

若该产品属于学术或专业性较强类型，则样本量不少于100个，平均分值为50分，总分100分，但是也受样本量影响，WAMMI很难在可用性测试场景后使用，不过它的问题可以在小型可用性测试中进行应用或自检。

WAMMI官网：http://www.wammi.com/index.html

5. APP用户体验量表(SUPR-Qm)

作为一个APP用户体验量表，涵盖了更多的体验度量面，而不仅仅是衡量了可用性（比如SUS），并且可以在可用性测试期间或可用性测试之外进行，也可以与其他问题混合使用以便于测量某些特殊产品(如游戏)的用户体验，同时它的信度也高达0.94，SUPR-Qm一共16道问题，采用传统的5分制李克特反应选项。

SUPR-Qm的16道题原本来至23个其他相关文献中的题目和4个开放性的问题，经过不断测试验证和减少冗余后，留下的16个具有单维的、可靠的、有效的、兼容强的问题。

SUPR-Qm原博客说明：https://uxpajournal.org/supr-qm-measure-mobile-ux/

6. 关于测试结果汇报

有些同学一直不清楚可用性测试报告要写些什么，有无固定格式，其实报告没有什么特别的地方，简言之就是将测试的目的、测试过程、测试结果进行整理汇报并反馈优化意见而已。

其中大部分内容没有硬性的格式要求，看起清晰易懂是重点，你可以是文档汇报也可以是PPT汇报，另外记得测试汇报讲究真实性，可以把测试过程中的照片或截图等放进去用于佐证。

另外就是测试结果的归档，我们通常会借助表格的形式来呈现，这样能够更好的将信息整合。

但是考虑报告输出，不是一味的反馈负面问题或解决方案，同样也可以反馈被用户认可的设计，这也是测试的一种价值作用，能够为后续的优化设计提供一定的方向指引与团队信心，所以我们将常见的测试结论归档表进行了一些轻微的调整，补充了反馈的正负趋向，最终呈现如下：

九、关于用户反馈的思考

用户反馈本身就是用户在使用产品的过程中遇到了问题，然后通过找客服或反馈入口所给予的反馈。

如果一个应用的用户忠诚度不高，即使你在应用内发布问卷收集反馈，用户的参与也会很有限，反而是因为一些问题让用户受阻了才会产生一些宝贵的反馈，而让用户准备和提交截图凭证更是困难。

所以这个时候让用户反馈的入口更好找，对问题类型提供细分选项，甚至对截图等动作做出一些预判都是不错的选择。

以支付宝的使用场景为例，我们有时候截完图是不是就马上会收到弹窗提示是否遇到什么问题了？

这便是对用户反馈的一种重视，如果你确实要准备进行反馈，那么你后续的操作步骤会少很多，使你更容易达成而不会因为繁琐的步骤而产生放弃的念头，并且截图时询问的窗口也是极力克制不会产生过分的干扰。

这么说来你是否对用户反馈这个功能有了新的看法，并有了给自家产品优化一下的想法呢？

写着写着就又没刹住车，又成了所谓的万字干货了。

不管你是从事什么职位，都希望你能够有所收获，即使你脑子里一灵光有了新的想法或不同意见都欢迎来找我交流。

最后也感谢那些不厌其烦与我交流的用研大佬们，下次有想法了还来烦你们哈哈。都看了这么久了，点个赞收藏一下吧～

本文由 @泡泡 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自Unsplash，基于CC0协议

,