对设计师来说，用户研究非常重要，但是如何确保自己的用户研究是有用，有效的呢？当我们在进行小型可用性测试时需要有哪些步骤，哪些注意事项呢？怎么找到适合的人选来进行研究？通过这篇文章，作者将解答我们的这些疑惑，并通过实操案例为我们讲述一些细节之处。
有时候设计师自认为比较好的方案，到了评审会上，会被各种似懂非懂的人提出各种问题。
为什么说似懂非懂，因为评审人里面有产品、研发、业务方等，这些人在自己专业领域都很优秀，但大多数并不太了解交互（设计心理学、交互原则、设计系统等）是什么，都是凭自己的感觉去说，这个时候很多设计师就没招了，只能听着各种 “我感觉”来给你提意见，为什么会这样？
因为他们知道你也是“我感觉”，你能感觉，为什么他们不能感觉。
设计师觉得自己像个改图的机器，应该就是这么来的。感觉这个东西是不确定的，也许下次评审他们感觉又变了…
解决这个问题的方法之一就是去做用户研究，要知道是谁在使用你的产品。确定用户，了解他们的期望，调查他们的需求，这些都是设计任何一个产品的起点。
因为你的用户不是你，他们的思考方式和你不一样，做事情的方式不像你，也没有你有的期望和假设。如果他们和你一样，他们就不是你的用户，而是你的竞争对手。
这个时候做B端的小伙伴就要问了，我们都接触不到真实用户。确实，B端相对C端比较难，但也不是不行，要看你所属行业。比如像钉钉（面向制造业），顺丰（仓储物流）这种B端产品还是相对比较容易的，只要公司支持，可以去企业工厂或者仓库看终端用户是怎么工作的。B端重业务和提效，去实地考察就可以触达这两块。
不过也要看领导层对设计（用户体验）这个部门的认可度，如果领导层觉得设计就是美工，基本就真的只能这样了，这也是很多大佬说的环境和领导很重要的原因。
进入正题……
基础的用户研究简单、快速而且高效，对任何产品都能进行实施，关键是你是否愿意动手去做。通过观看、聆听、记录，你就能更好地了解你的用户（客户），更清楚产品哪些地方不好用。
可用性测试能说明受众是否能使用产品。它有助于确定人们在使用产品时存在的问题，暴露出不好用的界面和容易混淆的语言。可用性测试通常作为大型研究系列的一部分，涉及准备和分析工作。
但从快速展示产品和经济的角度而言，邀请朋友、同事、家人进行小型可用性测试（以下简称：可用性测试）最合适。这样做，可以用最小预算获得产品的直接反馈。
如果你是第一次进行用户研究，还是先给自己一点时间准备一下。可用性测试过程可以分为四个主要步骤：
评估总是始于“为什么要有这个东西?”—华盛顿大学
出于某种原因，你正在设计某个产品。你觉得你的想法能让世界上部分人过得更好。也许能帮他们买到更便宜的东西。也许能帮他们获得其他途径得不到的信息，也许能帮他们联系到其他人，也许能让他们感到开心。
不管什么原因，你都在设计自己觉得会给特定人群带来价值的东西。要能获得这些价值，他们必须做点事情。
因此，对于可用性测试，首先要搞清楚产品的使用对象。对于你预期的、使用产品最多的用户，如何描述他们？他们和其他人有什么区别？区别在于他们的年龄、兴趣和问题吗？实际可能包含前面所有情况，可能还有更多情况。
但这不够具体，年纪大的老人也会购买餐具，但不会从网上购买。所以受众定义范围要稍微广泛一点。目标用户受众如下:
接下来，要找出关键产品功能特性，把产品内容写下来。为什么人们要使用它？为什么它对用户有价值？
现在把网站五个最重要功能写下来。在购物网站上，人们显然要能买东西。但不管是否准确清楚自己要买什么，他们都应该能买到东西。此外，也许他们还要能发现促销商品和超值商品。列份清单，用一两句话描述一下每个功能。
从使用者角度出发，用两三句话描述一下用户使用某项功能的情况，即所谓任务。如果“通过风格找到特定刀叉”属于功能之一，其任务描述如下:
最后，根据难易程度，按照从最简单到最困难的顺序排列任务。从执行简单任务入手，人们会对产品和任务过程有好感。
现在，找一些符合步骤1所创建的特征的人。找五六个人，这些人要与你预期对产品有兴趣的人相似，像这样快速运用可用性测试，就可以更充分地认识真实用户使用产品时发生的问题和误解。
从身边的人中物色合适人选是最快的方法。如果身处大公司，可以从与产品没有任何关系的部门找些同事。如果是在小公司，可以找朋友、家人以及同事的朋友和家人；可以找在办公室的人；可以找街头的行人。还可以找一些不熟悉产品的人、无论喜欢者或不喜欢，对产品都没有偏见的人，只要这些人和你期望访问网站的人有点相似就行。除非产品专为开发人员而设计，否则就不要找靠开发网站谋生的人，因为他们懂的东西太多。
首先，写一个剧本（测试任务），受邀的用户会根据剧本进行。
例如：用户现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。
你也可以在测试任务上介绍一下产品是做什么的，让所有参与测试的人都知道这是一个什么产品。
接下来找一台电脑，一个安静的房间。一般情况下，找个小会议室即可。确保房间里没有任何与产品有关的东西，以免分散用户的注意力。
测试前需要告知用户，他们受邀到此，是为了帮助你了解产品哪些地方有用，哪些地方让他们感到困惑。
虽然称为测试，但不是要对他们进行测试，而是邀请他们来评估产品，谈谈他们对产品的看法，所以他们怎样做都无所谓对错。
要强调一点：如果不能完成任务，也不是他们的错；如果他们说出对产品的负面看法，也不会伤害到任何人。他们要大声说出所有想法，这一点很重要。建议他们详细叙述在做什么，以及为什么这么做。
你会留在同一房间里，一边倾听他们发言，一边做笔记。这个过程不要打扰到用户，要让用户专心执行任务和详细叙述。
如果测试过程中他们被问题卡住了，不要告诉他们应该单击哪里或者看什么。不管什么情况，都不要告诉他们应该怎么做。如果他们看上去特别沮丧，就告诉他们有些事情无法完成不是他们的错，请他们执行下一任务即可。
如果所有任务都完成了，或者半小时时间已到，就可以请他们停止。请用户向自己谈谈他们的总体印象，他们是否会“在现实生活中”使用该网站。
然后送份礼物谢谢他们为测试所花的时间(吉祥物、小礼品、餐饮券…只要适合受众就行),向他们表示谢意，并送他们离开。
最后，重启电脑（恢复初始状态），清除缓存和浏览历史，为下一位用户测试做好准备。
可用性测试一结束，马上问自己下面几个问题。
到这里，你应该知道产品哪些地方存在问题。
你可能看到有几件事情一而再，再而三地发生。也许用户并不理解你为某项功能指定的名称。也许他们没看到关键功能。也许他们对所提供的功能不感兴趣。也许，他们喜欢这个产品，它能满足他们想要的一切。
知道所有这些情况是好事，因为能揭示问题出在哪里，而且同样重要的是能说明哪些地方没有问题。
这里的案例是一个面向制造业的产品，解决制造业多系统中数据的统一、维护、共享。
产品面向的受众人群主要是业务与技术人员，对数据库等知识有一定的了解。
任务：现在需要通过主数据产品，新建一条主数据编码规则，需要带上审批流程。
Nielsen 提出的一个法则：有 5 人参加的用户可用性测试，即可发现 85% 的产品可用性问题，而且通常最严重的问题都是前几名用户发现的，随着用户数量的增多， 发现的问题逐渐减少，被发现问题的数量与测试用户数量的关系如下图所示。
这次测试参与人员共6人，普通用户3名，技术人员1名，产品经理1名，项目经理1名，都是公司内部人员。
从执行任务可以发现，普通用户问题是最多的，但这个产品定位是技术人员，所以我们可以先不关注普通用户诉求，后面三类用户虽然都懂技术，还是存在很多使用上的问题。
原型如下：
例如：第一条不知道新建规则流程，设计的人会认为大家和他一样会使用，其它并不是，上面的产品经理不负责这个产品，所以他也不知道怎么使用，这也是b端产品的特点，c端玩玩就会了，但b端你不懂业务就真的无从下手。
基于这一点我们可以给一个功能引导页面，如下：
剩下问题的这里就不举例了，只想说明用户分析很重要。
谢谢大家观看！
作者：夜莺YEAH；公众号：夜莺B端UX设计
本文由 @夜莺YEAH 原创发布于人人都是产品经理，未经作者许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。