如何用两个简单问题推动UX研究
你是否曾在设计界面时，对屏幕上元素与系统其他部分的关系只有模糊概念？是否在 stakeholder 会议后带着不明确且常与之前讨论矛盾的指令离开？你知道更好地理解用户需求能帮助团队明确目标，但研究时间和预算紧张。在请求更多直接接触用户时，你可能会像可怜的Oliver Twist一样怯生生地问：“先生，我能再要一点吗？”
技巧在于让stakeholder自己发现风险
你需要让stakeholder自己识别高风险假设和隐藏复杂性，使他们像你一样渴望从用户那里获得答案。本质上，你需要让他们觉得这是他们的主意。
本文将展示如何通过两个简单问题，协作暴露团队共享理解中的不一致和空白：
- 对象是什么？
- 对象之间的关系是什么？
研究与屏幕设计之间的考验
这两个问题对应ORCA流程的前两步，ORCA代表Objects（对象）、Relationships（关系）、CTAs（行动号召）和Attributes（属性），它概述了创建坚实面向对象用户体验的过程。面向对象UX是我的设计哲学，ORCA是一种将用户研究综合为优雅结构基础以支持屏幕和交互设计的迭代方法。
ORCA流程有四轮迭代和15个步骤，每轮我们都更清晰地定义O、R、C和A。ORCA就像“垃圾进，垃圾出”的过程：要确保最终轮产生的可测试原型测试良好，流程需要由优质研究滋养。但如果你没有大量研究，ORCA流程的开始阶段另有用途：它帮助你推销研究需求。
ORCA通过帮助将研究提炼为坚实信息架构——屏幕设计和交互设计的支架——来加强研究与设计之间的薄弱环节。换句话说，ORCA流程充当研究与设计之间的考验。有好的研究，你可以优雅地从研究骑虎鲸进入设计；但没有好研究，流程会有效地将你吐回研究，并带有一堆特定开放问题。
进入同一艘好奇之船
让我们陷入麻烦的不是我们不知道的东西，而是我们确信正确实则不然的东西。——马克·吐温
ORCA流程的前两步——对象发现和关系发现——照亮团队不一致的黑暗 dusty 角落以及被扫在地毯下的任何固有复杂性。它开始暴露这经典漫画所精美说明的内容：
这是许多UX设计师在工作中受挫且许多项目失败的一个原因，也是我们经常无法推销研究的原因：每个决策者都对自己的心理图景自信。
一旦我们暴露每个图景中隐藏的模糊点及它们之间的差异，用户研究的理由就不言自明了。但如何做很重要。我们不能直接告诉每个人“你错了！”，而需要促进和指导团队成员自我识别其图景中的漏洞。当stakeholder承担起假设和理解空白的 ownership 时，砰！突然，UX研究不再难卖，每个人都登上了同一艘好奇之船。
假设你的用户是医生，而你完全不知道医生如何使用你负责重设计的系统。你可能会诚实地说：“我们需要更好地理解医生！他们的痛点是什么？他们如何使用当前应用？”但问题在于这些问题模糊，且答案感觉不够 actionable。
相反，你希望stakeholder自己提出超级具体的问题。这更像是你需要促进的对话类型。让我们听听：
“等等，医生多久共享一次患者？这个系统中的患者有 primary 和 secondary 医生吗？” “一个患者能有多个 primary 医生吗？” “是‘primary doctor’还是‘primary caregiver’… 那个角色可以是执业护士吗？” “不，caregiver是别的东西… 那是患者的家庭联系人，对吧？” “那么caregiver在这次重设计范围内吗？” “是的，因为如果caregiver在场，医生需要记录。比如，在笔记上标记caregiver… 还是在预约上？”
现在我们有所进展。你看到让stakeholder自己辩论这些问题的力量了吗？这里的 diabolical 目标是动摇他们的信心——温和而外交地。
当这类问题协作性地冒泡并直接来自stakeholder和决策者之口时，突然，在不了解这些问题答案的情况下设计界面显得极其风险，甚至愚蠢。如果我们不理解用户真实世界信息环境就创建软件，我们很可能创建出与用户真实世界信息环境不符的软件，这无疑会导致更困惑、更复杂、更不直观的软件产品。
两个问题
但我们如何外交、高效、协作且可靠地达到这类有料问题？我们可以从对应ORCA流程前两步的两个大问题开始：
- 对象是什么？
- 对象之间的关系是什么？
实践中，得到这些答案说起来容易做起来难。我将展示这两个简单问题如何为对象定义工作坊提供大纲。在这个工作坊中，这些“种子”问题将绽放成 dozens 具体问题，并照亮对更多用户研究的需求。
准备工作：名词采集
在下一部分，我将展示如何与stakeholder（希望还有整个跨职能团队）运行对象定义工作坊。但首先，你需要做些准备工作。
基本上，寻找特定于项目业务或行业的名词，并在至少几个来源中这样做。我称之为名词采集。
以下是一些伟大的名词采集来源：
- 产品的营销网站
- 产品竞争对手的营销网站（竞争分析，有人吗？）
- 现有产品（看标签！）
- 用户访谈记录
- stakeholder访谈笔记或愿景文档
戴上你的侦探帽，我亲爱的Watson。发挥创意，利用你已有的东西。如果你只有营销网站、现有遗留系统的一些截图和客户服务聊天日志访问权，那就用那些。
当你浏览这些来源时，注意反复使用的名词，并开始列出它们（如果之后要创建对象图，最好用蓝色便利贴！）。
你要关注可能代表系统中对象的名词。如果你难以确定一个名词是否值得作为对象，记住首字母缩略词SIP并测试：
- 结构（Structure）
- 实例（Instances）
- 目的（Purpose）
以图书馆应用为例。“书”是对象吗？
- 结构：你能想到这个潜在对象的几个属性吗？标题、作者、出版日期… 是的，它有结构。检查！
- 实例：这个潜在“书”对象的一些例子是什么？你能说出几个吗？《炼金术士》、《玩家一号》、《每个人都 poop》… 好，检查！
- 目的：这个对象对用户和业务为什么重要？嗯，“书”是我们的图书馆客户提供给人们的东西，书是人们来图书馆的原因… 检查，检查，检查！
SIP：结构、实例和目的！（这里有一个流程图，我详细阐述了SIP。）
在名词采集时，专注于捕获有SIP的名词。避免捕获如下拉菜单、复选框和日历选择器等组件——你的UX系统不是你的设计系统！组件只是对象的包装——它们是达到目的的手段。没有人来你的数字地方玩你的下拉菜单！他们是为了有价值的东西和他们能用它们做什么而来。那些东西，或对象，才是我们试图识别的。
假设我们为一家颠覆电子邮件体验的初创公司工作。我会这样开始我的名词采集。
首先我会看自己的电子邮件客户端，碰巧是Gmail。然后我会看Outlook和新的HEY电子邮件。我会看Yahoo、Hotmail…我甚至会看Slack和Basecamp等所谓的“电子邮件替代品”。我会读一些人们抱怨电子邮件的文章、评论和论坛帖子。做所有这些时，我会寻找并写下名词。
（在继续之前，随意为这个假设产品也做名词采集，然后向下滚动看我们的列表有多匹配。只是不要迷失在自己的电子邮件中！回到我身边！）
鼓声请…
以下是我在名词采集过程中想出的一些名词：
- 电子邮件消息
- 线程
- 联系人
- 客户端
- 规则/自动化
- 不是联系人的电子邮件地址？
- 联系人群组
- 附件
- Google文档文件/其他集成文件
- 新闻通讯？（HEY以不同方式处理）
- 保存的回复和模板
在OOUX世界，我们喜欢颜色编码。蓝色保留给对象！（黄色用于核心内容，粉色用于元数据，绿色用于行动号召。了解更多关于颜色编码对象图和将CTA连接到对象。）
扫描你的名词列表，挑出你完全一无所知的词。在我们的电子邮件例子中，可能是客户端或自动化。在与stakeholder会面前尽可能多做功课：谷歌能谷歌的。但其他术语可能特定于产品或领域，你需要就它们进行对话。
- 记录定位器
- 激励主页
- 增强行项目
- 基于课程的测量探针
这真的是你为工作坊会议需要准备的全部：一个代表潜在对象的名词列表和一个需要进一步定义的短名词列表。
促进对象定义工作坊
你实际上可以从名词采集开始你的工作坊——这个活动可以协作完成。如果房间里有五个人，挑五个来源，分配给每个人，给每个人十分钟时间在其来源中查找对象。时间到后，聚在一起找重叠。亲和映射是你的朋友 here！
如果你的团队时间紧张，可能不愿做这种苦工（通常情况），事先自己做名词采集，但准备好展示你的工作。我喜欢呈现文档和屏幕的截图，所有名词都已高亮。带来你过程的工件，并以五分钟概述你的名词采集之旅开始工作坊。
热提示：在跳入工作坊之前，将对话框架为需求收集会议，以帮助你更好地理解系统的范围和细节。你不需要让他们知道你在寻找团队理解中的空白，以证明需要更多用户研究——那将是我们的小秘密。相反，乐观地进入会议，好像你知识渊博的stakeholder、PM和业务人员已经拥有所有答案。
然后，让问题打地鼠开始。
1. 这是什么？
想找点真乐子？在会议开始时，让stakeholder私下为你可能不确定的几个晦涩名词写定义。然后，让每个人同时亮牌，看是否得到不同的定义（你会）。这是暴露不一致和开始伟大对话的黄金机会。
随着讨论展开，捕获任何商定的定义。当不确定性出现时，安静地（但可见地）启动一个“开放问题”停车场。
定义 solidify 后，这是一个很好的后续：
2. 我们的用户知道这些是什么吗？用户怎么称呼这个东西？
Stakeholder 1：他们可能称电子邮件客户端为“应用”。但我不确定。 Stakeholder 2：自动化通常被称为“工作流”，我认为。或者，也许用户认为工作流是别的东西。
如果出现更用户友好的术语，问小组是否可以同意以后只使用那个术语。这样，团队可以更好地与用户的语言和心态对齐。
好，继续。
如果你有两个或更多对象在目的上似乎重叠，问其中一个问题：
3. 这些是同一个东西吗？还是不同的？如果不同，它们如何不同？
你：保存的回复和模板是同一个东西吗？ Stakeholder 1：是的！绝对是。 Stakeholder 2：我不认为… 保存的回复是带链接和变量的文本，但模板更多关于外观和感觉，如默认字体、颜色和占位符图像。
继续构建你不断增长的对象词汇表。并继续在“开放问题”停车场捕获不确定性领域。
如果你成功确定两个相似事物事实上不同，这是你的下一个后续问题：
4. 这些对象之间的关系是什么？
你：保存的回复和模板有任何关系吗？ Stakeholder 3：是的，模板可以应用于保存的回复。 你，总是有后续：模板何时应用于保存的回复？那发生在用户构建保存的回复时？还是当他们将保存的回复应用于电子邮件时？那实际上如何工作？
倾听。捕获不确定性。一旦“开放问题”列表增长到临界质量，暂停开始将问题分配给组或个人。有些问题可能给开发团队（希望至少有一个开发者在房间与你一起）。一个问题可能专门给无法参加 workshop 的人。许多问题需要标记为“用户”。
你看到我们如何构建到UXR销售 pitch 了吗？
5. 这个对象在范围内吗？
你的下一个问题将团队的焦点缩小到对用户最重要的东西。你可以简单地问，“保存的回复在我们第一次发布范围内吗？”，但我有一个更好、更 devious 的策略。
到现在，你应该有一个明确定义的对象列表。让参与者将这些对象按从最重要到最不重要的顺序排序，可以在小 breakout 组或 individually。然后，像你处理定义一样，让每个人同时揭示他们的排序顺序。令人惊讶——或不那么令人惊讶——VP将像“保存的回复”这样的东西排名第2而其他人都把它放在列表底部并不罕见。当你不可避免地暴露更多不一致时，尽量别看起来太 smug。
几年前我为一家初创公司做过这个。我们将三组 wildly 不同的排序顺序贴在白板上。
这是这次会议非常混乱中间的一个片段：三列对象卡片，显示相同的卡片被三个不同组完全不同地优先排序。
CEO退后，看着它，说：“这就是为什么我们两年无法前进。”
admittedly，听到那个是悲剧，但作为专业人士，成为促进分水岭 realization 的人感觉相当棒。
一旦你对范围内、明确定义的事物有 good idea，这是你继续做更多关系映射的时候。
6. 创建对象关系的视觉表示
我们在试图确定两个事物是否不同时已经做了一点这个，但这次，问团队每个潜在关系。对每个对象，问它如何与所有其他对象相关。对象以什么方式连接？为了可视化所有连接，拿出你信赖的盒子和箭头技术。这里，我们用动词连接我们的对象。我喜欢将我的动词保持为简单的“有一个”和“有许多”陈述。
我们新电子邮件解决方案的进行中系统模型。
这个系统建模活动带来各种新问题：
- 保存的回复可以有附件吗？
- 保存的回复可以使用模板吗？如果是，如果电子邮件使用带模板的保存的回复，用户可以覆盖那个模板吗？
- 用户想看到他们发送的所有包含特定附件的电子邮件吗？例如，“显示我发送的所有带有 ProfessionalImage.jpg 附件的电子邮件。我换了专业照片，我想提醒每个人更新它。”
固体答案可能直接来自工作坊参与者。伟大！捕获那新的共享理解。但当不确定性浮出水面时，继续添加问题到你不断增长的停车场。
点燃导火索
你已沿水闸 positioning 炸药。现在你只需点燃导火索和砰。看着对用户研究的认同流 flow。
在你工作坊结束前，让小组反思开放问题列表。制定内部获取答案的计划，然后专注于需要带给用户的问题。
这是你的最后一步。拿那些你为用户研究编译的问题，讨论与不回答它们相关的风险水平。问，“如果我们设计时没有这个问题的答案，如果我们编造自己的答案而我们错了，那可能有多糟？”
用这种方法，我们将决策者逼入倡导用户研究的角落，因为他们自己将问题标记为高风险。抱歉，不抱歉。
现在是你真理时刻。与房间里的每个人一起，请求合理的时间和金钱预算，进行6-8次用户访谈，专门关注这些问题。
热提示：如果你对UX研究新手，请注意你可能需要重新表述工作坊中出现的问题，然后再呈现给用户。确保你的问题是开放式的，不引导用户进入任何默认答案。
最后的话：暂停屏幕设计！
严肃地，如果可能，不要再在没有首先回答这些基本问题的情况下设计屏幕：对象是什么以及它们如何相关？
我向你 promise：如果你能在开始设计屏幕之前确保业务、设计和开发团队之间的共享理解，你将减少心痛，节省更多时间和金钱，并且（在这一点上几乎感觉像奖金！）用户将更接受你发布到世界的东西。
我真诚希望这帮助你赢得时间和预算去与你的用户交谈，并在开始构建屏幕之前获得对你设计内容的清晰度。如果你使用名词采集和对象定义工作坊取得成功，ORCA流程的其余部分还有更多，这将帮助防止更多游戏后期的范围拉锯战和策略支点。
祝最好运气！现在去推销研究！