2016 年 5 月
第 31 卷，第 5 期
Visual Studio - 培养精益 UX 做法
作者 Karl Melder | 2016 年 5 月
在 Visual Studio 2015 中，Microsoft 提供了多种新的调试和诊断功能，Andrew Hall 在 2016 年 3 月的 MSDN 杂志文章“Visual Studio 2015 中的调试改进”(msdn.com/magazine/mt683794) 中进行了详述。对于涉及 UX 的重大变化的功能，Microsoft 采用了使用迭代实验（包括直接用户反馈）的“精益 UX”方法来告知设计。
我想与大家分享用于设计众多功能之一 - PerfTips 的过程，以及在此过程中的最佳实践、提示和技巧。目的是为你和你的团队提供启发，让你可以将客户反馈直接有效地融入开发过程。
精益 UX
精益 UX 是对精益开发实践的补充，这已经成为了行业中的趋势。在 Eric Ries 于 2011 年出版的“精益创业”(Crown Business) 一书中，他将精益定义为“构建、评估和学习”的做法，并在书中描述了一种“经营假设推动实验”方法。同理，精益 UX 是一套注重早期和持续的客户验证的原则和进程，你可以在其中进行实验，以很短的周期验证用户和产品设计假设。以注重解决实际客户问题为前提，就能快速地完成设计迭代。Jeff Gothelf 于 2013 年出版的“精益 UX”(O’Reilly Media) 一书是很好的参考材料，他在书中提供了指导和工作表，可帮助团队了解他们相信或希望实现的结果。
对于提供 Visual Studio 中的调试体验的团队而言，精益 UX 是一种高度协作的方法，它使整个团队（包括项目经理、UX 研究人员、开发人员和 UX 设计人员）都可以提出想法、提出假设并对客户的所见所闻作出解释。
本文的主要内容是，在产品开发过程中接纳客户反馈。本文涉及到如何更快地转败为胜。还涉及到无需费劲就能获得有关你的想法的反馈。本文探讨的不止是一个在开发人员工具部门进行此项工作的团队，而是多个团队从根本上改变在精简开发过程中功能的设计方法。
设计挑战
Microsoft 技术有丰富的数据源，可以为开发人员提供便利的问题诊断方式。但是，在 UX 实验室中，用户通常会退回到手动执行代码，尽管工具（例如，分析器）提供了很多优势。检测数据显现了 Visual Studio 分析器的低使用率，尽管人们确信，它会使查找性能问题的过程更加高效。对于 Visual Studio 这类工具（人们会花八小时甚至更长时间工作）而言，让用户改变工作风格是一件非常麻烦的事。所以，团队希望在调试性能问题和提供环境体验时利用用户的自然工作风格。
如果采取更传统的瀑布式方法，则团队可能会采用焦点群组来获取早期反馈并写入细则，当代码即将完成时，团队可能已经安排了可用性研究。团队可能会安排用户进行练习新功能，以及使用错误对发现的问题进行会审的任务。Visual Studio 2015 中采用了一种截然不同的方法。
研究过程
预先安排两位用户在每周五完成产品周期的大部分任务，而不是在工作位可用时再安排可用性研究。这些日子被俗称为“促脉星期五”。 用户参与约两小时，这段时间通常被拆分为两到四次实验。在每次实验中，对应该使用的时间进行最佳猜测。每次实验的内容均与帮助 Microsoft 更了解它的用户和工作方式，或者尝试想法有关。设计理念必须至少存活三周时间并获得正面结果，才能将其向前推进。正面结果是指，用户强烈地感觉到该设计对其具有价值、增加可发现性、让其更易于使用，或者能够演示对关键方案的改进。
UX 研究通常分为定量和定性两类，它是检测/分析和客户反馈指导业务与产品开发的组合。在早期的定性研究中，反馈是指获得用户对想法的反应。团队不仅要考虑客户的反馈，还要考虑客户的生理反应、面部表情和音调。用户还需要完成实际任务，例如，在接受观察时，不接受团队的协助，修复应用程序中的性能错误，如图 1 中的照片所示。这意味着让用户付出努力。团队将会为用户拍摄视频供将来回顾，或将所见所闻记录下来。观察用户帮助团队了解其工作方式和确定未阐明的内容，不需要用户了解要求的内容，但能为产品提供重大的改进。
.png "与用户的研究会话")
图 1 与用户的研究会话
团队成功的关键并不在于花时间试着说服用户喜欢一个想法。团队只是从用户使用的角度来展示想法。然后，团队会回过头，倾听、观察并提出能帮助团队了解用户观点的问题。团队成功的关键在于将其与可能产生强烈感觉的想法或设计分离的能力。
团队每周会招募不同的参与者，提供稳定数量的新观点。既有内部团队，也有负责招聘、筛选和安排用户的供应商。团队寻找的并不是具备专业的诊断知识的用户；而只是寻找活跃的 Visual Studio 用户。这就意味着，每周的用户都具备不同的技能、经验和工作环境。这就为团队提供了每周学习新内容和确定一致性的机会。团队还可以改进其想法，以在更大范围的受众中取得成功。
平衡团队与用户的交互方式与之同等重要。提问方式会大大地影响结果，并使对话发生偏差。团队形成了始终询问开放性问题的习惯—这意味着，问题均由用户的所说和所做衍生而来。例如，如果用户告诉团队他们不喜欢的内容，那团队只会简单地询问：“请说得具体一些。” 团队试着不对任意内容做出假设，并抓紧每次机会对假定和假设进行挑战。这些技能是 UX 领域的基础，并为团队中的每个人所接受。如果你想了解更多有关这些面谈技巧的内容，我向你推荐 Cindy Alvarez 于 2014 年出版的“精益客户开发”(O’Reilly Media) 一书。
早期促脉会话和不可动摇的工作方式
在产品周期早期，团队以帮助用户监视其代码的性能这一想法作为出发点。团队创建一个模型，并呈现在促脉星期五的用户面前。团队会一直听到（即使是在设计更换的三个星期后）用户不确定模型的作用，并且他们“很可能会关闭它！” 这并不一定是团队想要听到的内容，但却是团队需要听到的内容。
但是，在同时观察用户诊断应用程序问题时，有一点变得明确起来，那就是，团队需要一个 UX，而且它是代码导航体验的更直接的部分。即使有多个提供其他信息的调试程序窗口，但用户难以同时专注于多个窗口。团队会对多位专注于代码，并通常在想象中执行“代码作业”的用户进行观察。这对于正在阅读本文的开发人员而言可能非常明显，但引人注目的是，工作方式是如此不可动摇，不管用于使任务更高效的其他工具是否可用。
团队一开始使用 Photoshop 构想想法，一位经验丰富的设计人员需要花费一天以上的时间才能创造一个可用于反馈的模型。Photoshop 的高保真度往往有助于创建 UI。团队开始改为使用 Microsoft PowerPoint 和情节提要插件 (aka.ms/jz35cp)，这使团队中的每个人都能快速创建对其想法具有中等保真度的表示法。情节提要让用户对可能的形式具备了一定概念，但它们十分粗糙，因此用户可以看出这是一款正在进行中的设计，并且其输入对设计有直接影响。实际效果是，当实验失败时，放弃 30 分钟的投资要简单得多了。另外，可对团队知道无法在实际中运用的想法进行测试，但用户的反馈有助于产生新的想法。
为获取对用户交互模式的反馈，PowerPoint 幻灯片中的每一页都表示用户操作或系统对该操作的响应。起草交互时，将包括显示用户点击位置的光标图标图像。这在共享想法和处理细节时非常重要。但是，在为用户展示之前会删除光标图标。这就使团队可以询问用户的下一步操作，并为确定可能的发现性问题提供一种简单的方式。对于每一张系统响应幻灯片，团队都会询问用户是否觉得有进步，这让团队可以了解客户是否提供了足够的反馈。这种反馈技术在 UX 研究中被称为“认知演练过程”，能帮助你在交互设计的早期阶段确定部分问题，并让你能在早期了解需要关注的领域，这些领域需要进一步集成和实验以正确执行。
为了评估某一想法的潜在影响，团队依靠用户的能力来具体描述他在日常工作环境中对这一想法的使用，以及他认为可能的直接优点和缺点。用户必须为团队提供详细且可信的示例，以确定这一想法值得着手。团队还会进行观察，确定用户是否开始进行额外的关注、是否更加热情并表达激动之情。团队正在寻求会让用户激动，并可能对其诊断体验产生积极影响的想法。
“哇，这真是太棒了！”
团队需要一种展示代码中的性能信息的方式，它既不能影响代码的可读性，还要为用户提供一种环境代码中调试体验。Visual Studio 中的 Code Lens这一功能让你可以查看有关编辑历史、错误、单元测试和引用的信息，这些都为潜在的交互模式和视觉设计提供了启发。团队用多个想法的模型进行实验，在开发人员逐步介绍代码时向客户展示如何在数毫秒中展示性能数字（参见图 2）。
.png "展示调试会话中的性能数据的早期模型")
图 2 展示调试会话中的性能数据的早期模型
对团队注重于某件事的最早的迹象是，参与者（其身份为开发经理）在介绍体验时变得非常兴奋。我应该强调一点，他只是在展示建议的体验，而没有任何背景信息。当他意识到所见的内容后，他开始提出详细的问题，并且在发言时变得异常热情。他声称，这对于他和初级开发人员在做出不佳的编码决定（这会导致应用程序性能不佳）时遇到的问题而言，这将是一个解决方案。在当前进程中，他通过劳动密集型代码审阅流程解决性能问题，这对于他和他的团队都是一个沉重的负担。他认为，这可以帮助新手开发人员在首次起草代码时学会如何编写性能代码。他进行了诸如“该 [PerfTip] 能否成为 [in Visual Studio] 中的策略？”等评论 在意识到其价值后，另一位用户说道：“正是代码行功能让 Visual Studio 变得非凡！”
这种早期反馈还会让团队对于成为诊断工具的入口点，并解决部分可发现性问题的潜在功能变得兴奋。团队假设，这些 PerfTips 会成为用户冒险涉及更丰富的工具集的触发器。
设计详情
到目前为止已完成的所有操作只涉及模型—不涉及对代码的投资。如果想法受到欢迎，则“点选”PowerPoint 中会创建更高级别的详情以及多种设计替代方案，以进行每周实验。但是，当保留了数个研究问题时，可能会达到模型的可操作上限：
- 经验证，在调试常见逻辑问题时，PerfTips 的设计不会成为干扰，而会在处理性能问题时被发现。
- 团队希望用户能够正确解释性能数字，这从最后一次执行中断开始计时。
- 用户曾建议仅在性能令人担忧时展示值，但没人能充满信心地建议一个默认阈值。
- 有人担心，调试程序的开销（按毫秒增加）可能会降低它对于客户的价值。
团队已实现了最基本的功能版本，可以在特定条件下工作。这样就能创建兼具性能和供用户诊断的逻辑问题的应用程序。团队要求用户确定问题的具体原因。如果不成功，团队可以根据其所见所闻确定用户不成功的原因。可能会在下一周对设计进行更改和重试。另外，在此期间，可能会提供经过检测的外部 CTP 版本，其中，PerfTip 被链接到属性窗口，以便用户可以轻松地按需更改阈值。团队结论：
- 当用户修复逻辑问题时，PerfTips 不构成干扰。实际上，在用户处理性能问题时，需要使用微动画对 PerfTips 进行微调，使其更引人注意。
- 部分措辞更改（例如，添加“已用”一词）可澄清用户有关解释计时数据方面的所有困惑。
- 阈值只有在不连贯显示时才会对用户造成困惑，在大部分环境中都能使用的简单值不会被识别。部分用户声称，他们对代码了解地最彻底，所以，他们是判断合理性能时间的最佳裁判。
- 用户意识到，由于调试程序的开销，值不会是精确的，但他们反复说明，他们对此没有意见，因为他们关注的是总差异。
总之，在过去的几个迭代周，团队在让用户确定性能问题原因方面获得了一致的正面结果。用户还会用“好棒”和“哇，太棒了！”之类的评论提供热情的反馈，无需任何提示。
记录
记录时，团队学会了一点，如果有时间坐在一起进行讨论，就要避免在讨论之前得出任何结论。更有用的是，即时进行原始记录，并尝试逐字记录用户所做和所说的。不必考虑语法和拼写。当重新了解所发生的操作并从数周的观察中得出的模式提取观点时，这些笔记就成为了团队的参考。
当跟踪团队的测试计划、捕获原始笔记和起草快速总结时，Microsoft OneNote 成为了一款非常便捷的工具。总是有一位指定的记录人在捕捉其所见和所闻。这为其他团队成员提供了喘息的空间，以便能完全专注于用户。对于无法参与的人而言，团队会使用 Skype 共享实时会话；团队中的每个人都会收到观看和学习邀请。另外，团队还会为与会议有冲突但想稍后观看的成员录制会话。视频录制还会让团队审查需要额外关注的领域。团队会就每周的结果进行讨论，并通知下周的工作内容，此时，写正式报告完全没有必要，只会拖慢进度。
总结
PerfTips 的设计和开发仅仅是每周实验内容的一部分。每个用户每周有多达四个实验，这探索出了很多想法。对断点设置的重新设计是另一个实验示例，团队会每周运行以进行迭代，以提供更有用和可用性更高的体验。通过应用精益 UX，团队得以转移风险，并在实验的过程中通过所见所闻获得启发。设计功能时，这些实验消除了方程中的主观臆测。想法有多种来源，并通过观看开发人员的工作方式获得启发。
如果用户觉得这个想法没有价值，那么低成本使得这个模型可以很容易地重新启动。另外，失败也能迸发出新的想法。我希望精益 UX 的示例和提示可以给你启示，让你愿意尝试。本文中引用的“精益”系列丛书会为你提供采用这一方法的良好指导和框架。
参加计划
Microsoft UX 研究团队正在寻找各种类型的开发人员提供直接反馈，以及参与这项持续的实验。要进行注册，请在 aka.ms/VSUxResearch 中描述你的技术背景和联系方式。
我想特别感谢以各种方式参与该项目的各位。你只能把促脉星期五描述为“拥挤”，因为团队在观察、学习并努力思考如何为 Visual Studio 提供深思熟虑且有目的性的添加项。特别感谢 Dan Taylor，他一直走在开发团队的前面，并沉着冷静地面对各种技术挑战。Andrew Hall，他用扎实的技术知识和实用的方法带领团队前进。Frank Wu，他使团队不断产生新的想法，并用其不可思议的能力将其简化，找出使其简单化的方法。
Karl Melder担任高级 UX 研究员，他一直将所学知识和经验应用于 UX 研究、计算机科学、UI 和人为因素中，为 UX 设计提供帮助。在过去的 15 年里，他始终致力于为各种各样的客户加强 Visual Studio 的开发体验。
衷心感谢以下 Microsoft 技术专家对本文的审阅： Andrew Hall、Dan Taylor 和 Frank Wu
Andrew Hall 是 Visual Studio 调试程序团队的高级项目经理。大学毕业后，他编写了业务线应用程序，并返回学校考取计算机科学专业的硕士学位。获得硕士学位后，他加入了 Visual Studio 的诊断工具团队。加入 Microsoft 以来，他一直从事 Visual Studio 中的调试器、探查器和代码分析工具方面的工作。
Dan Taylor 是 Visual Studio 诊断团队的项目经理，他在过去两年一直从事分析和诊断工具方面的工作。在加入 Visual Studio 诊断团队之前，Taylor 曾担任 .NET Framework 团队的项目经理，并为 .NET Framework 和 CLR 提供了大量性能改进。
Frank Wu 是高级用户体验设计师，目前主要为所有的开发人员设计和提供最佳的编辑和诊断体验。他拥有 HCI 的硕士学位，在过去 10 年间从事过安全软件、Windows Server 产品和开发人员工具方面的工作。