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