本文作者Tony Russell-Rose是致力于复合搜索和信息访问App公司UXLabs的一名主管。在这里主要是分享UX设计程序里的几个需要避免的谬论观点。

自UXLabs建立以来我参与过各种各样的设计项目：不管项目大小、简单还是复杂、初创企业或者是大公司。在那段时间里，我已经注意到一部分实践看上去运作的很不错，可是大部分的实践结果则不尽人意。在这下面我主要是针对用户体验设计流程的一些谬论进行总结。

1. 需求分析最好是留给专家去做

收集和管理用户需求的技术有很多种，只不过程序不同而已。通常这些需求都是由业务分析师在利益相关者的研讨会上进行收集，随后在一个不断扩大的项目列表里将其记录为一个线下项目。这仅仅是一个开始，但是在很多时候，掌握“投入水平”（在设计和开发两个方面）和“敏捷交付”的评估也是一项很重要的能力。虽然前者比较简单完成，但是后者可能会涉及到数据、资源和技能等方面的可用性；还关系到企业的战略发展；符合正在进行的项目/工作流的分配协作原则。也就是说，只要任何一个和特殊需求有关的可行性建议都是有效地，不管它是否具有优先权或者易于实现。这些评估能力是很难获得的，但是它能和上面的项目列表产生同样的作用，具有优先权、敏捷交付，能够生成更让人信得过的项目，用于后续的冲刺计划。

2. 设计是一个纯粹的创造性活动

如果在设计上给出无限的时间的话，原则上，可以找出所有解决问题的优化方案。可是在实践中，时间是有限的，所以，应该重视在设计上的研究探索，给用户体验这一项目更多的优先权。分享对设计空间维度的理解也是很有必要的。在相关搜索设计项目里，维度通常相当于：

• 用户：我们替什么样的用户群设计，他们具有哪些相应的优先权？
• 任务：我们支持什么类型的搜索任务……项目类，探究类等等。
• 环境：有很多方面的环境都是很重要的，但是这里比较适当的是数据环境….我们所关心的信息资产，通过这些信息怎么映射出用户的心理模式呢？
• 复杂度：在不同的场景下我们支持什么样的复杂度呢？一个简单的、有限的互动，或者是更多的要求？许多设计项目偏重了简单的可寻性任务，而忽视了更复杂的信息行为类型。

3. 不能用数字跟踪设计探索

传统的用户需求分析技术存在一个明显的缺陷，那就是那些技术知识简化论，在那种技术下的需求最终可能被表示为一个支离破碎的形式。如果缺少环境这个要素的话，他们所提供的任何将数值传递给用户端的经历也将是毫无意义的。强调这一点的方法就是通过将需求组结合到一个单一的、连贯的场景里。方式有很多种，从一个简单句子到一个高架构的对话，但是这样就可以将聚合需求分享到有意义的、目标明确的故事里。

一旦你从场景映射到需求，您可以把映射作为审计工具使用来评估每个需求的状态。这种类型的审计跟踪在一定程度上提供了透明性和追究性，这样就确保了在分析阶段所做的评论在设计探索阶段具有责任性。

4. 专注于一个最佳的设计方案

以用户为中心的设计，其核心准则就是技术原型应该与终端用户相结合进行反复测试，并在用户反馈的基础上进行升级更新。但是并不建议用户测试建立在一套可以相互转换的备选设计上：这使得在不同的备选设计上存在直接的定量比较，而且定性的用户反馈通常情况下更有效用。此外，对于和搜索相关的项目，备选方案的选项应该建立在对不同阶段的信息旅程的了解基础上。

5. 分面和数值都属于环境

人们认为一旦交互设计在完成之后并交付，例如，作为一组线框图，设计工作基本上已经完场。但这种情况并不是搜索项目相关的，特别是那些使用某种形式的分面搜索技术。在这些情况下，需要有一个单独的交付记录形式和个人方面的内容，以及项目是如何运行的。这包括以下的一些问题：

• 转换逻辑——例如，在游戏开始阶段用户的选择是如何影响中期阶段的。
• 有限规则——例如，这一规则可以管理什么时候、如何展现一个特殊的面。

线框图并不是记录这些关系和约束的合适工具，但这些细节在搜索体验的质量上发挥了关键作用，应该在设计活动里进行定义并作为关键部分记录下来。