在过去的几年中，在为项目组开发工具的过程中，经常会遇到几个常见的问题：工具的功能虽然实现了，但使用起来却让人感觉不畅快，导致使用率低下；有时明明功能按钮和使用说明就在页面上显眼的位置，但用户就像视而不见一样；甚至有时我们花费了大量的时间和精力开发了一个功能，结果半年下来使用次数竟然只有个位数。这种情况下，我们必须在产品方面进行深入的反思和复盘，才能找到我们的瓶颈何在。
我所在的测开组，除了常规的测开工作外，也一直致力于为项目组的全职能开发提供效率工具。我们在去年年底的时候，就设定了一些产品维度的目标，旨在提升工具的易用性和用户的满意度。在这个过程中，我通过各种途径积累了一些相关的经验，虽然这些经验尚未形成完整的体系，但我相信对于新入行的测开人员来说，还是具有一定的参考价值。
需要注意的是，我并非专业的产品岗位出身，所以很多内容只是借鉴了一些广为流传的产品知识体系，并结合了自己的工作实践进行总结的，可能并不够专业。产品的经验因人而异，我相信很多人对于同一件事情可能会有不同的看法。比如，在项目内的测开为项目组这种相对固定的开发环境开发的工具，其视角和侧重点必然会与那些需要不断开拓、为整个部门开发中台工具的情况有所不同。我非常期待能与大家交流，分享你们的见解和建议。
1.
了解用户习惯
一般的2C互联网产品，常常需要在众多潜在用户中精准定位目标用户群体，通过深入的用户画像来分析他们的具体需求和偏好。但对于我们主要的2B产出而言，用户群体的定位则相对明确，因为我们的工具大多具有特定的需求和明确的受众。工具的设计和需求的实现，很大程度上取决于其面向对象。
以面向技术开发的工具为例，其效率需求通常会超过界面需求。这是因为技术们更看重工具的功能性、效率和稳定性，以及是否符合他们长期养成的工作习惯。就像很多牛逼的程序员更倾向于使用vim而不是各种IDE一样，他们对于工具的外观需求并不太关心，但会对工具的功能细节提出更多的要求，比如功能的完备性、操作的简便性和效率以及是否符合他们的直觉需求。
如果工具的使用者是非技术人员，比如PM、策划或美术人员，那么易用性就成了最重要的考量。在设计这类工具时，关键是要突出常用的功能入口，确保用户能直观地找到他们最常用的功能，从而降低他们的思考成本。同时，我们还需要特别注意“知识的诅咒”现象，也就是避免使用一些只有我们QA团队熟悉但其他职能部门可能不了解的专业名词，并确保我们没有忽略他们的工作习惯。例如，在早期的一个项目中，我们曾在launcher的出包列表上标注了“bvt失败”，并将未通过bvt测试的包显示为红色以表示其不可用性。
将未通过bvt测试的包显示为红色以表示其不可用性
但我们在后来的调研过程中发现，绝大部分其他职能的同事只知道标红的包体代表不可用，而并不理解“bvt”到底是什么意思。所以我们后续的一个改进就是取消“bvt失败”的状态显示，而是把所有人都能理解的失败原因直接显示在launcher上。
至于面向其他QA的工具，我觉得更重要的是“少猜多做”。他们是我们平时最容易观察到的用户，也是反馈最为直接的用户，甚至我们的工作内容的本质在很大程度上都具有重复性。如果平时主要做工具，不接触产品测试内容的话，我建议如果有机会，最好还能亲身体验一下作为产品QA的工作，会对找准痛点这一方面大有裨益。
（上面这些论述是带有一些个人刻板印象的结论，并不是所有人都适用！项目组里其他合作伙伴的性格和偏好各位应该在日常工作中都有所了解，一定要根据实际情况做调整。）
很多时候，我们的工具并不是专为某一个特定职能设计的，而是需要满足整个项目组的多样化需求。针对这类工具，我们需要确保它既具备前面提到的所有特点，同时也要遵循KISS原则（Keep it simple & stupid）。对于所有职能都需要使用的功能，界面设计应简洁明了，同时为少数需要使用专业化功能的用户预留足够的自定义拓展空间。
举个例子，我们的launcher在开包的时候，支持填写一些命令行参数来启用一些额外功能，比如开启代码染色、开启性能收集等。程序通常会使用这个功能来达成他们各自的一些个性化需求。我们也经常在集体测试时让用户填写一些参数来收集项目级别的性能数据。但其实对策划美术来说，让他们去理解命令行的作用，去写命令行参数是一件理解成本比较大的事情，所以他们经常跳过我们要求的设置步骤。所以后来，我们直接将一些命令行参数抽象了出来，做成一个选项的形式，用户只要按我们说的勾上对应的选项，就相当于填了一个默认的命令行参数，他们不需要理解这个选项具体干了啥，只要点一下就行，大幅降低了他们的理解成本和使用成本。
launcher在开包时支持填写命令行参数
2.
用户诉求与需求
《人人都是产品经理》里有一个很经典的表述，相信很多人都听说过，就是“听用户的话，但不要照做”。类似的，还有一句话是乔布斯说过的“人们不知道他们想要什么，直到你把产品拿给他们”。这句话拆解一下，其实表达的意思包括：
人们通常无法表达自己的诉求。
人们表达出来的需求经常是不准确的。
用户在使用产品时才能验证自己的需求。
在书里看到过一个例子，“如何定义搜索引擎的使用体验”，大部分普通用户会回答界面好看、信息排版等舒适等，但如果刻意抽象后会发现，用户最烦躁的时候往往出现在搜索结果出现后翻了许多页都没发现自己想要的结果时，因此前几页的点击量就是搜索引擎质量的一个表现，是需求和体验的一种抽象，但是这样的表述想让普通用户说出来实在是有些强人所难了。受限于视野和考虑维度等因素，人们常常无法表达出使用产品时真正的需求，往往都是直接给出一个他们视角下容易想到的一个解决方案。我们部门之前的某个分享里也提过一个需求分析的“Y模型”也有过类似的表述，如果你问用户想要什么，他们往往会说想要一匹更快的马，但是产品必须意识到，他们背后的需求是“更快的交通工具”。
需求分析的“Y模型”
对于我们开发人员而言，这其实更是一种需要时刻锻炼的意识，在接到用户的需求后，先想想“他为什么需要这个？”这时也可以用5why分析法，对自己连问5个为什么去对需求究根究底。倘若有时候你对他提出的需求感到诧异，觉得“他为啥会这么想/这么做”，那多半是对需求的拆解还不够清晰，对用户所处的场景和行为分析不够透彻。
然而，需要注意的是，考虑到认知方面的差异，我们所分析的需求也并不一定是用户的真实需求，因此，在尝试对用户需求进行抽象和拆解的过程中，沟通是至关重要的。在我们的日常工作中，这种情况其实很普遍，尤其是跟我们打交道的经常是一些开发岗或者策划岗的角色，可能是出于职业习惯，他们经常会拿着比较明细的需求条目甚至是原型图来找到我们希望我们实现。在这种情况下，我建议各位都可以先尝试一下分析他们的诉求与需求，如果你认为存在更优的解决策略，可以尝试用下面这套标准化话术：
“您的需求我了解了。您是希望通过……手段，达到……目标（复述需求），我这边有个想法，我觉得可以考虑尝试一下……（描述你的思考），这么做的好处是……，但可能存在的问题是……（提前帮用户理清利弊，便于达成共识），您觉得怎样？（把选择权交还给用户）”
当然，如果条件允许，验证自己猜想的方法比较简单（比如只是实现一个简单的前端表单设计），那么你完全可以迅速捏一个原型给用户，看看用户的反馈。如果用户同意，皆大欢喜。如果用户不同意，那么也可以重新定位一下，为什么你给出的方案用户不认可，你对用户的需求是否存在误解，用户需要的是否真的是你一厢情愿认为的“更快的交通工具”？在沟通中对齐需求，对最后的产品呈现非常重要。
最后，作为QA职能，我们产品工具的底线也十分明确，即保障项目整体流程的质量和稳定。当遇到与这一原则相悖的需求时，我们必须予以高度重视，并不能盲目地接受所有需求（尽管在多数情况下，这些需求可以进一步拆解和抽象出真实的用户需求）。
我们组在几个月前曾经接到过一个美术同学提的需求，他们希望我们在编出新的UE编辑器的时候，标注一下哪些是有引擎改动的编辑器，然后他们只更新这些编辑器来工作。但这个需求是存在质量隐患的：使用非最新编辑器提交的资源，很可能会在后续的步骤产生问题导致打包失败或资源表现不符合预期，浪费大量时间。
通过进一步沟通，我们了解到美术提出这个需求的背后原因，一是因为他们每次更新编辑器所花费的时间很长，这段时间内他们是无法正常工作的，会觉得很浪费时间，而且他们觉得编辑器质量很不稳定，出现过几次用长时间更新出来的编辑器因为各种情况无法正常使用，结果还得花大量时间回滚编辑器版本来正常工作，非常影响效率。在这个情况下，在下载速度我们无法做明显优化的情况下，他们的诉求其实是提高编辑器的稳定性，所以后续我们主要采取的手段是和技术方面合作，通过增加自动检查等方式去提高编辑器的稳定性，以及制定标准规范来提高编辑器错误的修复时效。这样既满足了美术们的诉求，又能确保整体项目的质量和稳定性。
3.
用户场景
产品经理刘飞分享过一个故事：在他们做外卖产品的时候，项目组的人在反复测试外卖配送的流程，其中有一步，是接到订单后，手机发出非常响亮的声音“您有新的外卖订单，请注意查收”。这个播报在手机内强制最高音量且会连续播报四次，不可打断。这个声音在办公室环境下此起彼伏，非常吵闹，让人心烦，以至于项目组讨论过这个强制功能的必要性，是不是可以手动打断或者是调低音量。但当他们穿上外卖员制服，骑着电瓶车跑了几单以后，很快达成了共识：维持原状是更佳的做法。
这个例子突显了“用户场景分析”的重要性，而进行用户场景分析，最重要的就是“到现场去”。如果有机会，我觉得真正去“成为用户”是做产品非常有价值的一个步骤。测开平时很多时间为QA产出工具，我对我们组测开的一个要求就是必须至少参与1个游戏功能模块的全流程跟进，真正体会一下QA的日常工作，去看看自己做的产品用起来到底是个什么体验，也去看看日常测试过程的效率卡点在什么地方，这样才能更好地发现产品和流程中的痛点，进行针对性的优化和开发。这一点可以说是产品团队测开的独特优势了。
除了QA职能外，在给其他职能做工具的时候，也必须保持“同理心”的意识，尽可能换位思考，考虑对方对工具的可能使用场景。但是考虑到经验和背景问题，我们对用户的场景思考很难做到面面俱到，这个时候，沟通依然非常重要，及时的沟通能够有效减少战略误判，帮助我们认清需求。
我在我们项目推行定时访谈机制，每4个月，组里的测开会分别寻找其他职能进行访谈，访谈对象覆盖各个职能（策划、技术、美术、QA、PM）且横跨各工龄阶段，每次访谈约15-20人左右，访谈的内容大致包括一段时间来对测开工具的满意度、在测开整体产出的几个维度进行打分（交互设计、功能全面、性能、支持等要素）以及收集下一个阶段有没有什么新的需求。其中，打分这块，根据我自己的使用体验，我一直觉得我们的工具在交互和易用性上是最需要改善的部分，对其他方面还比较满意；但4月份的用户访谈结果却令我感到比较意外：绝大部分用户对交互设计的满意度都挺高，但是对工具性能给的分数都比较低，而性能不满意的点都集中在launcher上。
测开工具的满意度评分汇总
令我感到意外的地方在于，我自己平时在使用launcher时并没有感受到明显的性能问题，平时QA组内也很少听到关于launcher性能问题的反馈，也因此比较少在意launcher在性能方面的表现，但从访谈记录里得到的信息显示，其他职能的很多角色都遇到过launcher卡死、无响应等问题，而且频率并不低。
在对访谈内容进行分析和用户单独沟通后，我们确定了两点原因，一是反馈卡顿的用户平时工作大多会开着编辑器+游戏包体，程序还可能开着IDE，美术还可能开着设计软件，这些都占用了非常多的系统资源；另一方面，部分员工的电脑配置比较差，加重了launcher性能的问题表现。而QA大部分都是20年后入职，电脑配置已经提升过了一波，且QA日常工作中不需要开很多很耗的后台软件，因此虽然launcher存在较高的性能消耗，但QA在日常工作是很难感受到问题存在的。
这次调研访谈对我的触动很大，以至于在看到本段开始的那个外卖故事的时候产生了很强烈的共鸣。有时候站在我们的视角上真的很难感受到用户真实的工具体验，只有当我们去更多与用户面对面，或者直接成为用户本身时，才能发现问题的存在。
4.
用户认知偏误
在2C的产品中，有很多用户认知偏误是产品经理在设计产品时应该注意的，例如损失厌恶（面对相同级别的收益和损失时人们往往觉得损失更难以接受）、逆火效应（当假设被相反的信息否定后，反而会使人们更加坚信原本的假设，比如某些新闻，官方越辟谣，群众越相信事情真实存在）和框架效应（同一个问题在不同的描述下，人们通常会选择更顺耳的描述）等。但绝大部分与用户在心理学层面的博弈在我们的业务里应用不是特别明显。这里我着重来提一提注意力偏误，这个坑在我们产品设计中倒是经常碰到。
有一个很经典的心理学实验，各位可以在不开弹幕的情况下试一试：心理学实验（非注意盲视），看看如果在没有了解过的情况下，自己能否回答出试验后的那两个问题。
在我们的开发过程中也经常能观察到一个现象，就是哪怕我们的文字说明写得再详细，也总有很多用户不会去看或者压根发现不了，甚至我们写的说明文本越多越详细，用户就越不在意。在使用工具的过程中，实现目的是主要目标，次要因素对用户而言并不重要，很容易关注不到，这就是注意力偏误。
基于这个认知，可以引申出几条设计原则：
主线流程之外的信息要默认用户不了解；
大段落的文字和小字体的文字要默认用户不会阅读；
有重要的流程步骤或者信息传递，需要更加突出，或者直接使用阻断式的提醒。
上述的这个实验名为大猩猩实验，它所代表的现象在实践中其实也能明显感知到，指望着用户会去阅读大量的指引文档来学会一个看起来不是很直观的功能点是不太现实的，用户多半会直接POPO你问怎么用，或者干脆直接选择放弃。因此，在日常工具制作中，要尽可能做到重要信息突出显示、关键信息阻断式显示、小字信息只用于专业需求和附加需求。
“任何在用户体验上所做的努力，都是为了提高效率。这基本上是以两种形式体现出来的：“帮助人们工作得更快”和“减少他们犯错的概率”。人们所使用的工具在效率上的改进，会直接带来企业的整体生产力的提高。在完成任务时你花费的时间越少，那么在一天之内你能做的事情就越多。根据一直以来“时间就是金钱”的观点，节省员工的时间就直接等于节约企业的金钱。“
——《用户体验要素》
1.
用户体验要素的五个层面
很多产品类书籍在讲解用户体验要素时，都引用了上述《用户体验要素》一书中的表述，即将其划分成了表现层、框架层、结构层、范围层和战略层。这本书虽然是面向早期网页开发的，但核心思想我依然觉得很有道理，与大家分享一下。
用户体验要素的5个层面
从抽象往具体来讲：
战略层：在我们进行具体的工作前，先自问一下，“我们要通过这个工具得到什么？”“我们的用户能通过这个工具得到什么？”这两个问题，第一个描述了我们的产品目标，第二个描述了用户需求。我们越能清晰地表述出上述两个问题的答案，就能越精确地满足双方的需求。这是我们后续进行所有工作的基础，请务必保证自己对战略层有清醒的认知。
范围层：当我们搞明白了战略层中的产品目标和用户需求，并且把它们转变成具体提供给用户的功能时，战略就变成了范围。在这个层面上，我们主要考虑的是功能规格，其实也就是确定需求。
功能规格的撰写有两个要点，一是保持乐观（be positive），描述系统将要做什么事情去“防止”不好的事情发生，而不是描述系统“不应该”做什么不好的事情，比如“这个工具不允许没有权限的人登录”，这个表述会更好“当没有权限的人登录时，提示权限不足，并给出权限申请指引或自查文档”。二是具体（be specific），尽可能避免模棱两可的描述，比如“重点数据应该放在前面展示”，这里“重点数据”就是一个不具体的表述，可以根据需求修改为类似“单帧性能数据与本轮测试平均值差了50%以上的数据放在其他数据之前展示”。
结构层：经过了范围层，我们对工具具体要实现哪些功能已经很明确了。而结构层定义了整个工具的交互设计，确定各个将要呈现给用户的元素的模式和顺序。
交互设计：关注描述“可能的用户行为”，同时定义系统如何配合与之响应。它要求设计者从用户行为的角度出发去进行设计，而不是从适配计算机实现的角度去要求用户遵守我们的规则。
概念模型：定义交互组件如何工作。通俗来说，就是“不要违反用户长久以来形成的直觉”。比如我们对电商网站中的“购物车”概念已经根深蒂固，以至于如果我们要新开发一个电商平台，只要把一个购物车按钮放在界面上，用户就能立马明白这个按钮的作用。
错误处理：定义了当用户犯错误的时候系统应该如何反应，且当错误发生时，系统如何防止用户继续或重复犯错，或是用户在后续意识到自己出错的时候，是否能恢复之前的状态。
框架层：结构层决定了产品运作的方式，而框架层则确定了功能实现的形式。对于工具而言，它主要包含了界面设计和信息设计两个要素。框架层的具体内容设计到界面设计方面，这方面我不是专家，就不误人子弟了。
表现层：框架层主要考虑界面排布的问题，而表现层的作用是解决并弥补“产品框架层的逻辑排布”的感知呈现问题。例如产品的配色方案和排版、风格设计等要素。通常情况下，工具设计需要注意内部和外部的一致性，内部的一致性指在同一个产品中，不同的方面应该遵循同样的设计思路和方法；外部的一致性指在一个部门或组织的不同产品中，也应该使用相同或类似的设计框架和元素，以提高用户的感知度并塑造整体品牌的统一性。
当我们试图去解决一个问题或者去进行一项调整时，我们应该先理清楚，这个需求对应在上述的哪个层级。比如当我们要调整一个按钮的时候，是觉得它颜色不协调，影响了整体的美观性（表现层），还是按钮在工具中的位置不太对（框架层），还是说按钮本身并没有实现用户的预期期望（结构层）？当你修改某个层级的时候，需要关注一下其对上下游层级的影响。
这五个层级中，越抽象、越底层的层级重要性越强。如果工具在战略层就出现问题，即使表现层做得再出色，也无法改变工具无法满足用户可用性需求的事实，成为“漂亮的垃圾”。因此，我们需要确保在每个层级上都下足功夫，确保产品的质量和用户体验。
2.
用户体验=可用性+易用性+稳定性
从用户角度而言，用户体验可以被简单定义为用户使用工具时的感受。但大部分情况下，我们不能也不应事无巨细地关注用户的所有触点，我们的时间和资源有限，好钢应该用在刀刃上。而从用户体验的角度出发，有几个维度是我们在进行考虑时应该重点关注的。
可用性：指让用户通过产品能达成其预期目的，是产品的核心价值。比如launcher的基本作用就是下包、开包，如果连基本的功能都无法满足，那么再多其他功能也没有意义。
易用性：指用户达成其目标的成本和对成本的感受。如果用户通过你的工具能够达成其目标，但是会发自肺腑地痛骂“这什么XX设计”，或者是晕晕绕绕了半天才知道他想要的功能在哪里，那么工具的易用性就存在问题。
稳定性：在计算机行业中也叫鲁棒性，稳定性包含两个方面：系统异常的概率及异常发生后的解决成本。
如果要按优先级给这些用户体验的层次排个序的话，那么我认为，在测开岗工具而言，可用性>稳定性>易用性。
可用性其实不用说太多，这是一个工具的基础。而稳定性，对我们测开岗业务而言非常重要，某些时候它和可用性是绑定在一起的，因为很多时候一旦我们的工具出现bug，整个产品的生产流程都会受到影响，并最终造成非常严重的事故。举个例子，前段时间平台部的机器出现问题，导致了权限平台受到影响，而我们的launcher登录认证是基于权限平台的，认证失败后将无法使用工具，所以那段时间，其他职能无法使用launcher获取最新版本的编辑器和包体，并导致了项目整体进度停滞。事后，我们梳理了与第三方合作的功能，并对对应功能都做了保底手段，比如我们除了权限平台外，自己项目还维护了一个定时从易协作、权限平台同步和手动维护的项目组人员数据库，但因为这个数据库的信息存在一小段时间的滞后性，因此之前并没有作为我们的首选项。Launcher修改后，当launcher启动时从权限平台获取数据失败时，会转向查询此数据库是否存在目标人员的信息，这样至少能够保证大部分时间系统的稳定性。总之，稳定性就是要求测开做好QA本职，在保证产品bug尽可能少的同时，尽可能去构思工具的容错手段，把异常所造成的损失最小化。
易用性排在第三并不代表易用性不重要，相反，在一个存在竞争的环境里，在两个产品同时满足可用性需求的情况下，用户很容易因为易用性流失到另一个产品，而在生产环境中，易用性也直接影响着用户使用产品的效率，进而影响项目的整体效率。但绝对不能因为易用性的需求去牺牲产品的可用性和稳定性。
用户体验最重要的事情在于做出分层，区分出哪些是可用性，哪些是易用性，哪些又是用户的稳定性需求。对用户不同程度的体验需求，我们要区分满足，而不是”事无巨细地进行极致体验“。
1.
产品价值=(新体验-旧体验)-迁移成本
这个标题是俞军的一个非常经典的产品公式。我们把工具做出来以后，即便产品的新体验足够，用户也可能会因为迁移成本过大而放弃使用，因此，对我们而言，光把工具功能本身做好还不一定足够，如何降低用户迁移成本也是一门重要课题。
对于需要推广的平台工具而言，优化迁移成本的途径一般来说是优化接入成本（打通接入流程，确保中间不存在任何高门槛、难理解的步骤，尽可能多地自动化接入流程）、定制化配置项（因为各个项目的习惯不同，工具需要尽可能满足不同用户合理的个性化需求）等。对于项目组测开工具，情况会有些不同，这里分享一下我的一些经验：
1）尊重已经形成的项目习惯。项目的效率很大一部分来源于惯性，当我们尝试以“让界面变得更友好”为由去迭代工具交互时，尽量以细节调整为主，不要改变工具的大体布局和效果，确保用户还能下意识地找到曾经用过的功能。如果工具布局变化过大，哪怕从设计上比之前合理很多，用户也会非常抗拒。
2）工具特征适合web化的，尽可能web化。客户端工具在更新方面存在天然的劣势，无法做到无感更新，天然就有较高的迁移成本。为了控制更新频率，避免对用户造成过频的骚扰，我们必须得控制更新频率（想想每天打开软件的时候都要看到更新弹窗是一种多痛苦的体验）。
另外，客户端更新今年在我的项目还出现过两个坑，一次是我们launcher的更新功能本身出了bug，导致用户更新到最新版本的launcher后无法再通过自动检查更新功能升级到后续版本的launcher，我们也没有专门做过类似hotfix的功能，因此只能在大群@所有人让大家手动去下载最新安装包进行客户端升级。这个其实是一个挺大的事故了，放在产品上妥妥是一个会造成大量用户流失的一级事故，因此客户端工具这类涉及版本更新的功能迭代一定要慎之又慎。另一次因为项目上线的安全性需求，我们需要更新某个功能的权限设定，但是客户端并没有强制更新，导致不主动更新客户端的用户不会受到我们新权限策略的约束，最后还是通过在服务端添加了一些限制才曲线达成了这一目标。
在做客户端工具的时候，上述类似情况可能造成的后果也希望能给大家一个警示吧。
2.
从数据与沟通感知工具效果
游戏内有哪些数据分类，针对不同的游戏类型可能会不太一样，大家需要了解自家游戏的数据类型，这能够帮助我们更好的考虑到一个功能有哪些数据，然后分析出这些数据是如何在客户端与服务器之间流转的，进而覆盖到这些数据的存档测试，同时基于数据流转逻辑挖掘出更深入的功能测试点。
工具效果的评估，一方面是通过使用情况来看，另一方面是通过定期的访谈来获取用户的主观反馈。数据方面，我们之前会使用平台部提供的数据报表平台，通过对工具的各个功能入口插入对应的记录接口调用来实现工具及各功能使用率的统计，对各工具的使用情况做定期的汇总统计，以此来鉴定工具的使用状态：
对各工具的使用情况做定期的汇总统计
通过对这些数据的分析，我们可以更方便地了解到工具各个功能的使用情况，并根据使用情况进行有针对性的回访和完善以及安排下一阶段的任务。但不同的工具根据其所面向的用户群体和作用不同，使用频率和考量方法也不能一概而论，因此数据最终只是分析时候一个客观的参考维度。
除了数据以外，直接与用户交流，获得反馈也是非常重要的一环。测试中心社恐分布率已经很高了，我们的用户也更是如此。碰到用得不顺心的，通常忍忍就过去了，或者悄无声息就流失了，会主动寻找开发者帮助提意见的人少之又少，所以我们也不能指望靠用户主动反馈来获取工具的真实使用状态，也因此我们组的测开有4个月对用户抽样进行一次整体访谈的规则。面对面的沟通往往能牵出很多我们平时没有注意的地方。
提前一周左右告知用户访谈计划，并告知可能会询问的问题，以便让用户更有心地注意一下近期工具的使用情况，避免访谈时因为平时对工具关注度不高导致无话可说的场面。
如果涉及到打分环节，避免毫无参照的打分设置，比如直接让用户对交互体验打分1-10分，但是不说明评分标准，这样不同用户打分的衡量尺度差异可能较大，影响最终统计。可以的话加点描述，会直观很多。
用户打分选项设计
尽量避免“如果我做一个xxx功能，你觉得怎么样？”这种问题，用户大概率会回答“我觉得挺好的”，但这个回答只能代表他们觉得存在这个功能是好事，并不代表这个功能的重要性和必要性，也不代表他们真的会认可并使用这个功能。
可以说，从去年年底到今年几十份的用户访谈报告帮助我们发现了不少因为视野局限而没有认识到的问题（比如前面提到的launcher性能问题），还能让我们对其他职能的工作流程有更加准确的感知，对我们后续工作规划的指导意义重大。
3.
用户感知
记得去年年底在组内盘点OKR的时候，提到一点是制作人对测开工作不够了解，不是很清楚我们产出的具体效果。这个其实我还挺理解，毕竟制作人一般不经常涉及前线工作，对工具的感知力度较弱是在预期内的。但后来跟主程访谈的时候，主程给我提了一个log分析页面的需求，关键是这个需求之前有其他程序给我们提过，其实我们其实早就已经实现并放在项目工具集页面上了，但是主程却完全不知情。这下确实是有点戳到我的痛处了，我开始认真思考推广工具的方式，做出来的工具让存在相关需求的人感知不到是不应该的。
在这个问题上，我主要采取的是几种措施：
1）强化工具更新提示。在我们的工具集功能更新发布时，给对应的功能页打上new标签，并在进入后显示更新内容，吸引用户主动点击了解。
强化工具更新提示
2）在日常沟通中更多宣传我们的工具，比如季度进行的访谈环节，我们会主动向受访者介绍可能与他们相关的工具产出，鼓励他们试用并宣传给身边的其他同事。
3）面向项目组发送定期的推广邮件，用简单的描述介绍本周期新上线或有迭代的工具，吸引用户了解。
但其实，通过推式宣传的方式不一定能够有效触达用户，这个邮件可能刚开始还有人关注一下，但时间一长或者邮件一多可能也就放着不管了。所以现阶段的推广还是以第二点的地推为主。但长远来看，我从去年到今年在主推的“产品化”工具建设，本质上是为了把测开工具的品牌效应打出去，希望借此让其他职能更了解我们的工作，能够更频繁主动地和我们沟通他们的诉求，并最终实现项目整体效率的提高。
因此，我们不应满足于仅仅将工具制作出来，更要追求其作为产品的卓越品质。我们需要深入了解和关注我们的核心用户，从他们的需求和期望出发，为他们打造出最合适的工具设计。在不断修炼产品内功的过程中，我们将逐渐领悟到，产品思维不仅是一种工作方法，更是一种以人为本的态度。让我们怀揣着对产品的热爱和对用户的尊重，继续前行，创造出更多更优秀的产品。
推荐阅读
【雷火UX体验设计】“原来还可以这样？”——游戏体验设计的再语境化
都看到这里了，点个赞再走吧~
