译者记：随着设计深入越来越对用户抱有敬畏之心，用户研究是可以极敏捷也可以极复杂的事，讲用户研究的书很多，偶然通过DesignerNews发现这个UXR-flied-guide网站，对用研尺度把握的很好，语言精准又不死板，偏实践偏项目用研，目前该网站还在连载中，通过同步翻译这些资料完成一些自我学习。
前言：用户研究现场指南
用户研究是一件神奇的事情，它不但能够帮你解决产品、市场、设计、神奇企业文化方面的问题，还能辅助睡眠，改善与同事的关系，并将你从烦恼的长夜中解脱出来。
然而这种研究又是十分困难的，尤其是设计迭代越来越快，“敏捷研发环境”中的产品设计简直就是一架边飞行边修理的飞机，犯错误是难免的而且很可能以《空难调查》来结束这个飞机的修理工作。从经验主义的角度讲，如果团队有了用研的声音，他们将很大程度上保证为合适的人做合适的服务，成功的概率将大大提升。
我在各个创业公司做产品设计的这些年，从隔壁高中楼到香港小仓库，在世界各地花了数千个小时做用户调研。这份用研指南试图解决如何做好一个有理有据真实可信的用户研究，这些研究将会帮助你的团队更自信的解决问题并带领产品走向证被验证有效的方向。
就像我的口头禅：我们没有时间不做调研，我们没有时间重来一次，我们没有时间犯一个灾难性的错误。
现在，到用户那边去吧！
—— Quintin Carlson @quintincarlson
译者记：开篇这封序写的很好，我发现国内外的技术书籍有个至大的差距就是“修辞”的应用，修辞在技术性书籍中不是一种文学技巧，而是你有没有试图让别人听懂你的话，我们的专业文章写成了专业人觉得是废话，而非专业人觉得很深奥，更深层次是作者的共情能力到底深不深。
第一章：为什么用户研究很重要？
我敢打赌已经发生或者即将发生有一个同事站出来和你说：“你为什么要花时间做这些事情，我很清楚我们要做什么。” 已经有很多书籍和文章解释这个问题了，我发现有三个解决这些问题的最佳途径。
1、我们设计的每个界面都是基于一系列决策。
我们凭借“假设”和“感觉”进行了许多工作，调研是一道光，照亮正在黑暗中造物的我们，它将告诉我们需要解决什么问题，如何解决，以及最终是否有效。“全靠猜”的设计之路是不回把产品推向成功的，无视用户将导致糟糕的产品，失败的功能和愚蠢的设计。
2、用户研究帮助我们更快更自信的将产品推进到一个验证过的方向。
用户研究帮助我们在项目启动之前更了解产品的方方面面，避免了重构大部分的客户体验。就像荒野求生要通过各种方式确立行军方向，用户为中心的调研可以帮助大型项目变得简单可控。我们最缺的就是时间，时间就是金钱、力量、食物、知识，停止浪费自己的时间和团队的时间必须从用户研究开始。
3、不参与其中我们永远不可能假装自己了解用户，毕竟我们服务的“用户“并不是完全是我们自己。
无论是为是为内部成员、外部伙伴还是客户设计，没有一个设计师和产品经历可以完全代表用户的观点和需求。我不会视自己为一个典型的用户，企业软件的设计师更容易在这个过程中感觉到自己之前的“最佳实践”被颠覆。如果你是在服务一个社交软件或者一个大型公司，有可能会使用自己设计的产品，但是不要让这种物理上的“亲近”影响你自己的判断，还是会有大部分的用户和你不一样。
第二章：用户研究的基本原则
开始介绍用户研究的方法之前，我们先后退一步谈一下做这些工作的基本指导原则。
1、用户导向
并非老生常谈，当设计复杂系统的时候，我们必须持续关注自己并非用户这个事实。在说用户导向的意义之前，我想说一下这个词“User”，这个词承载了太多东西，我个人还是很讨厌的。
只有毒贩和软件公司称他们的消费者(Customers)为“用户（Users） ”—— Edward Tufte
在这篇指南和设计团队内，当我们提到“用户”这个词时，应到意识到自己在说的是位于软件终端的一群复杂的人。因此没有任何一个设计师、经理或是工程师可以说自己是用户。在大多数情况下，团队里没有人是用户所在领域的专家。
设计应该是始于尊重，这意味着在和用户共同要创造一个开放的，包容的，易于共情的平台。我们应当时刻警惕偏见，用户为中心的设计在商业上获得成功证实因为我们持续关注用户体验，倾听用户反馈并与用户的情绪模型高效协同。
另一方面用户导向意味着为不同的用户去做针对性设计，在Flexport我们定义了56个不同的用户画像，并伴随着产品成长不断丰富，在Inkling有超过15个用户画像，一般来讲企业级软件可能会有较多的用户角色和较高的用户复杂度，然而无论你有多少用户类型，当我们谈用户导向的设计需要聚焦到那个类型的用户，为这些不同类型的用户设计产品，需要清晰的、坚定的去理解你服务的核心用户。
2、迭代
唯一在过程中的就是过程本身，设计和研究的进程都会不断变化，每个项目都需要不同的工具、技术和资源。我们在与用户、伙伴和各种利益方共同协作的时间越长，我们的过程便会不断需要不断改进，需要牢记这份指南中的任何过程和方法都要在你的实践中即时评估和调整，探索新的方法和技术并在进行中组织自己的观点和沉淀。
3、基于证据
请使用具体的证据来指导你的决策，这包括案例，用户观点的引用，实验记录和其他的实物证据。使用快速原型的方法我们可以不断改进用户画像和验证设计决策，这些证据会随着设计语言和系统的拓展越来越重要。
4、平衡
不要做的太多也不要太少，用户研究往往被当作敏捷迭代的敌人，其实不是的，设计研究可以优先处理那些关键的空白领域，并行于快速的研发工作，我们可以用简单的技术去了解核心的用户心智并在初始化版本发布的时候快速验证，设计调研是快速行动的好朋友不是敌人。
5、全面性
设计研究能够帮助我们不会为了一棵树而错过一片森林，我们日复一日的访谈用户，做可用性测试，发现新的机会，这帮助我们后退一步发现产品的方方面面，而不仅仅是那些成功的上线的战报。用户研究是长期战略中的核心组成部分，帮助我们将定量数据，定性调查和团队内外各种声音整合到一起，目标一致。
第三章：调研的六个篇章
调研可以分成两个类型，一个是“去探索”，一个是“去验证”。探索性研究是去识别有效的需求和产品机会，验证性研究是去与用户对焦我们的理解和潜在解决方案是否会被接受。
我们经常感觉设计调研在项目开始时进行会比较舒适，其实在任何阶段都可以开始，当我们在用户测试时发现一些问题，也可以回到探索性研究和验证性研究中去。
1、概要研究
“让子弹飞一会～”
这种研究主要是帮助我们决定接下来的工作内容，目标在于发现商业机会和回答各种各样“假如”的问题。
常用方法
User Interviews —— 用户访谈
Contextual Inquiries —— 情景调查
Ethnographic studies —— 民族志研究
Competitive Analysis —— 竞品分析
Review user analytics —— 用户评论分析
Surveys —— 问卷调研
2、产品洞察
这一部分主要聚焦在识别和定义用户的根源问题，由此我们可以定义产品需要解决哪些痛点，在这个研究过程中我们用最大的努力去勾勒出用户的心智模型。
常用方法
User Interviews —— 用户访谈
Card Sort —— 卡片分析法
Process mapping —— 流程图
User journeys —— 用户体验地图
3、产品验证
在这里我们验证各种产品假说来尝试解决前面发现的问题，这里重点不是具体的设计细节，而是产品整体是否满足用户的预期，在这个过程中我们还应该发现最小化的可行方案来为后续的功能推进排好优先级。
常用方法
Low-Fi Prototypes —— 低保真原型
User Tests —— 用户测试
4、设计探索与迭代
此时我们会进行一些低保真的设计，并依赖持续的反馈循环做信息架构的确立，在设计－测试的每一次循环中提高设计的保真度。
常用方法
Co-creative exercises (like RITE sessions) —— 联合实践
Card sorting —— 卡片分析法
Usability Tests —— 可用性测试
5、设计验证
保证这个产品解决了根源性问题，在这个阶段我们验证即将上线的功能是否完全解决了初始化研究时定义的问题，切流测试或者使用高保真测试，这些测试同样定义了一些待优化点来管理后续产品迭代。
常用方法
High-Fidelity Usability Tests —— 高保真可用性测试
Pilot Tests with a small group of users —— 分桶测试
6、发布与后期
产品发布前，我们将定义这次设计的产出和目标。通过指标定义即将与这个世界见面的方案、工具、特性表现究竟如何。在接下来的两三周内关注数据变化并抽访一些用户，确认目标的完成度。
常用方法
Review instrumented analytics (Google Analytics, FullStory, etc) —— 数据检测
Contextual inquiries/user shadowing —— 情景调查
User Interviews —— 用户访谈
第五章：如何问问题
做正确的事还是做自以为正确的事？是否会问问题决定了最终结果。
提问的基本方针
当和用户面对面的时候，请一定要做开放式问题的提问，千万不要问那些可以用简短的语言给予明确的回复的问题。
你可以这样问：你的问题应该给参与者留有拓展和持续回答的空间。
1）一般你是如何与同事和客户分享文件的？
2）能不能介绍一下你是如何把这些变化通知到团队的？
但不要这样问：你的问题能用一两个词回答，参与者无法补充什么内容。
1）你经常使用这些功能吗？
2）你之前这样分享过文件吗？
小技巧：在会话时应当保持积极倾听，正向而强烈的眼神交流并适时的点头以鼓励参与者贡献更多的内容，留出较长沉默又略显尴尬的时间帮助参与者持续思考，使用一些断句如“继续”“这个可以深入谈一下”来微调参与者的阐述。
译者记：这点技巧看似简单其实很难，“尴尬”是感性的极致，各种情绪都会在这个时刻爆发，“沉默”是理性的极致，只有对行动和结果在认知上高度统一的人才能用持续沉默去面对尴尬，上升一点其实是能否有极大的理性来控制自己容忍极大的感性，这在洪尚秀的电影中可见一斑。生活中热衷于急于打破尴尬的做法用在调研中很容易错失重要的信息。
OKFRI提问法
OKFRI可以简单的记忆为”OKay Friday”，其实是一些问问题的基本方法的短语集合。
开放式答案，Open Ended：
不要问是否的问题，不要有倾向性的答案。
让受访者说的更多，Keep participants talking：
常用“告诉为更多”和“没事再想想”来鼓励用户阐述更多信息。
具体的频率，Frequency:
边缘用例的频率经常会帮助到设计，需要了解量化的结果，比如这个事情具体发生过多少次？
最近的发生时间，Recency:
最近一次是什么时候发生往往也能确认这个任务的权重，可以经常问问上次发生是什么时候？
详细的影响，Impact：
当用户描述一件发生错误的事情时，可以多探索这个错误所带来的影响，通过多问“为什么”来扩充内容。
控制好边缘用例
研究对象很容易陷入对边缘状况纠结之中，很可能带你一起专注于那些奔来很少发生的情况，作为设计师或研究者我们经常听到用户说“有时候……”
正确的做法是：
问一些最近最近的情况并得到量化的证据证明这些案例或者特殊的解决方案发生的概率。
1）上次发生是什么时候？上上次呢？
2）一般发生频率是什么？每周？每月？每年？
3）问题发生的时候你们如何处理？使用什么措施避免？
不正确的做法是：
把边缘情况当作重要的情况，贩卖只有定性了解的边缘案例解决方案。
小技巧：让用户带你实际复现这些问题的发生并仔细观察，暂缓不易复现的情况直到能够实际观察。
一般都会有的偏见
我们都在努力做用户喜爱的设计，设计师尤其如此，正因为如此不要去问用户是否喜欢某个具体的功能，这是浪费时间。
格式化你的问题
引导性问题是最广泛存在的偏见，这种问题不能帮助产品设计，只会污染调研数据，就像《法律与秩序》里法官将会拒绝辩方律师带有引导性提问所获得的证人证词。
当准备好一个问卷时，可以请你的设计师同事帮忙质疑是否带有引导性，最终才能获得正确的结论。
三列提问法
在准备一个问题提纲的时候你可以使用这种方法获得没有偏见和引导性的问题，在纸上画出三列。
第一列：假设
像所有科学实验一样，假说是我们测试的基础，举例如下：
这个设计减少了用户在该流程中困惑。 新版的APP会减少用户的开发票的时间至少3天。 这个功能会提升网站注册率15% 用户会因为不能及时联系到现场员工而焦虑。
如果可以你应当写上这个假说成立所依赖的［独立性变量］——我们要监控的结果；［依赖性变量］——我们改变了那些因子导致这种结果的发生；［衡量因素］——证明这个结果有效的量化指标是什么。
第二列：问题草稿
这里我们可以写下我们想了解的内容，这里难免对带一些偏见和引导性，但这不是传递到用户耳中的问题，所以也不要太在意语气或者格式，例如：
新的设计比当前的系统要好用多少？ 这个App是如何减少周转时间的？ 和员工的沟通当前有那些痛点？
第三列：优化问题
这个时候要梳理最终问题了，试着用最合适的语气和格式去问：
这次设计的那些改变最令你印象深刻？为什么？ 这个APP对你的工作流程的产生哪些影响？ 能否详细描述一下你和员工沟通时候的情况？ 考虑一次沟通不畅的情况，能否详细描述有哪些不同？
第四章：认知偏差
无论你是坐在用户的办公室还是用微信了解一些用户反馈，甚至和潜在伙伴在谈笑风生，目标都是创造一个好的产品和服务解决用户的核心问题，要做好这一点需要厘清自己的认知偏好和预设主张。
认知偏好定义了你的底层认知模型，我们对于同一件事的判断不同基于每个人都有不同的经历、社会关系和人际关系。这一章我会介绍一下影响用户和研究者自身的认知偏差。
影响用户的偏差
权威影响：人们倾向于认为权威认识有着更正确的建议。
比如：人们倾向于认为加州州长对医疗系统的看法是正确的，即便他也没有任何医疗领域的经验。
在实践中：因为我们为他们设计这个产品，用户经常带着我们想法去描述自己的工作，他们一般不会打断或者纠正我们的一些说法。
缓解的办法：一是增强信任，主要是提醒自己我们不是专家，而是希望用户作为专家来带给我们行业见识和指导意见。二是尽力去适应对方的身份和环境，从着装到谈吐尽量拉近与受访者的距离。
启发性偏差：人们往往认为自己容易记起来的东西十分重要。
比如：如果你和用户讨论一阵子AppleCare对iCloud账户的影响之后，再说到苹果和安卓手机的问题，往往会听到用户说：“苹果手机总出问题……”
在实践中：用户会说边缘状态市场发生，他们要求你完美处理掉这些问题，这些建议其实是基于用户的特定场景在过去一个月里产生了三次。
缓解的办法：我们应当问清楚具体的频率，数字，关注实际再现的案例。
另一方面我们也应当做更广泛的调查，对各种类型的用户进行研究能帮助我们更真实的了解到这些意见是否有偏差，这种真实性验证也是十分必要的。
花车效应：用户容易受到主流观念的影响，“大部分人”的所做所言会影响他们的见解。
比如：在某个时代人们往往穿同一个风格的衣服。
在实践中：我的客户告诉我他要花8个小时格式化（美化）自己的报告因为人人都那么做，尽管这完全没必要。这是个真实的故事，我打电话给他的经理礼貌的告诉他这实在没啥必要。
缓解的办法：我们可以多问一些为什么，顺着线索揪出真实的原因，探索事件的现实作用，往往因为我们知识服务者不是用户共同的雇佣方更容易得到一些真实的原因。
基本率谬误：人们一般比较喜欢特定时间或者奇闻逸事。
比如：许多人认为螺旋桨飞机（事故率12/万）比喷气式飞机（1/万）要安全，其实是因为喷气式飞机伴随着媒体发达在新闻中出现的概率高了。
在实践中：有的用户觉得云存储文件很容易损坏因为他听说过朋友发生了这种情况，所以他把所有的文件都同事进行了打印存储和本地存储，其实概率学上他的电脑损坏、文件丢失的概率比云服务损坏文件的概率高多了。
缓解的办法：还是要更广范围的闻讯比揪出最终原因，看看是不是个体的原因。
礼貌影响：人们避免自己真实的意见冲撞到他人。
比如：女孩子Gregory不喜欢男朋友的新夹克，但她还是会对他说“挺好的”。
在实践中：一个新的流程测试用户并不满意但是他没有说出来因为他觉得我们的工作十分辛苦。
缓解的办法：这个需要提醒自己和受访者并不是个人完成的设计，注意自己是个研究者，不是设计师。
框架效应：人们会因为对事情的不同陈述方式而产生不同的看法。
比如：比如航空公司介绍新航线会对价格敏感的客户叫“经济舱”，对穷人叫“放牛（cattle）舱”。
在实践中：比如我们隐藏了某个功能，当你说“我们在主界面中移除了这个功能因为使用率很低”，那么用户反馈会很不好。但你说“我们简化了界面想让首页使用起来更简单”，用户感觉贼好。
缓解的办法：使用上文提到的“三列提问法”来将最终问题“去情绪化”，形容词在市场营销中很有用，但是在设计研究中会影响用户的感受。
功能固着：人们倾向于认为特定的对象的作用应该像他过去使用时一样。
比如：有的人使用q-tip去清理耳廓，有的人用q-tip去做一个DNA的3D模型。
在实践中：让非技术人员适应智能手机工作，将他们从纸质流程带到移动设备上来，导出都是“你不能用这个做xxx”这样的声音。
缓解的办法：持续的用“为什么”去疑问，探究它就是是个情绪问题还是个逻辑问题。
影响力偏差：人们会放大某些变化所带来的影响。
比如：我们会认为改了办公室电话可能好几月都没人能联系到我们吧！
在实践中：有情绪认为我们用上传pdf代替文件传真可能用户无法切换，事实证明这些苦难只存在了两个星期。
缓解的办法：我们可以设定一个时间点来检查这些问题产生的影响有多大。
现状偏见：人们一般会去避免任何改变现状的事。
比如：许多人还是不离开Yahoo和Alta Vista，尽管知道Gmail和Google有许多优点。
在实践中：我们经常遇到不愿意离开纸质系统的用户尽管数字服务更快、高效和可信赖。
缓解的办法：我们需要了解的是用户不愿意做出改变的原因和克服这些原因的办法，并非仅仅了解用户意愿本身。
影响我们自身的偏差
锚定偏见：我们接触到的第一个信息往往会极大影响自己的认知，尽管没有更多的信息呈现出来。
比如：我们认为卡车司机都很懒且不会讲英语，尽管我们并没有确认过到底有多少能说英语，只是因为第一印象而已。
在实践中：我们访谈的第一个用户往往会极大的影响我们的设计判断，即便没有和更大部分的用户对焦过。
缓解的方法：除了扩大样本量，在研究开始阶段也要做好笔记，需要时不时的回到初始信息纠正自己的偏差。
证实偏差：我们潜意识喜欢去寻找证明自己的判断正确的证据，甚至有意忽略证伪，强调能够支持自己的数据。
比如：如果你想得到更正向的结果你就回去问“你对社交生活感到高兴吗？”。如果你想得到负面的结果就会去问“你的社交生活有什么不愉快吗？”
再比如：一个坚信自由市场经济学的人如果被要求解读一个金融新闻，他的个人感受一般会影响到最后的数据结论。
在实践中：我们经常会问那些希望听到特定答案的问题，或者找到某个被是正确的设计细节去延伸。比如一个用户觉得新产品视觉不错但是比老版本慢了，许多人便去忽略这些“慢”，而去谈如何改进当前的版本了。
缓解的方法：确认问题的中立性，并让其他人和你一起审阅笔记。
期望效应：我们实施研究的时候有很强的期待要发现什么内容，因此也更倾向于忽略许多内容。
比如：某些政府官员能够从歌词听到反对他们的声音，而一般听众却察觉不到，因为他们已经认定有人通过歌词在书写反对言论。
在实践中：我们倾向于看到用户在某些设定的缓解受阻，而忽略那些“一定会顺利进行”的环节。
缓解的办法：双盲测试可以很好的缓解这个问题，有时我们需要其他非项目中的设计师加入去审阅完整的记录，也可以请非设计师的伙伴去参与到测试中去。
用户并非总是正确
当和用户的观点产生偏差的时候，担当好设计者的工作，做好设计你的决策，科学分析测试数据，做你认为正确事。
证实你的工作
待续……
