笑天涯说：做产品的过程中，不可避免经常遇到改交互的情况，设计师们，你们有没有遇到提需求相当随意的产品经理呢？
知乎提问：产品经理提需求太随意，老让设计试试怎么办？
问题补充：经常遇到一个这样的问题：
1，产品经理提出好几种交互方案，说要全部做出来放到线上快速测试看效果。
2，交互设计师和视觉设计师针对他的想法一一做了相关分析并且反馈最终建议的方案，但是产品凭借自己的主观感受坚持自己的方案，或者所有的都实现，找理由说要“小步快跑，快速试错，多做几种方案试试看”。
3，但是我觉得这样很浪费资源啊，而且觉得产品经理很不负责，我会让他们提供相关的数据和证据来支撑他们的需求，但是他们提供不了我也没办法否掉这个需求；
——————-
不要光评论对错或者只是喷PM，说说你觉得作为当事人应该怎么办？
知乎用户@吴亮的回答：
看了一下其他答案，好像都不太到点。题主的问题应该是在交互层面，对方案中的某些要点，产品经理和设计师都没有充分的客观依据去证明其合理性，而产品方面要求进行多方案的测试，这个时候应该怎么做？
恰好最近我也在思考这个问题，并提出了一种设计方法。虽然这是一个初步的想法，未通过实践验证。但我觉得它还是有一定可行性的，欢迎大家讨论。
在此把全文贴出来。有点长，凑合着看（原文链接：Test-driven Design）。
—————–我是分割线—————–
## 不要说「我觉得…」
很多设计师习惯用自己的经验和主观感觉去提出方案，但经验和主观感觉很可能是错误的。以用户为中心的设计，需要以用户心理、用户行为相关的客观事实为依据去执行，而非以设计师的「自我参考」去执行。
使用「自我参考」方式的设计师，经常会陷入多个选项的纠结中，这样会浪费大量的时间和精力。若以事实为依据去设计，我们应该收集足够的数据、用研和测试结论，并根据这些事实去进行决策。这么做能够让我们不浪费时间而做出正确的决定。
团队成员对设计的讨论和挑战，通常也是「自我参考」方式的。这个时候如果没有客观事实为依据，设计师很容易陷入被动的状态（这让很多设计师产生了「领地意识」的可笑观念），甚至与团队其他决策产生冲突，影响合作效率。而如果这个设计是依据某个事实结论得出的，那么这些质疑便也不足为惧了，设计师也能更好地与其他人协同工作。
所以，以事实为依据的设计是我们追求的目标。但是在实际执行中，我们会发现设计师获取事实依据的资源非常有限。已掌握的数据和信息很多时候并不足以对一个新的需求提供充分的依据，在前期进行严谨的用户研究和测试又会耗费过多的时间。
那么在整个过程中，我们如何高效地收集事实依据呢？
受软件开发中 Test-driven Development 的启发，我想到了一种激进的设计过程，叫做 Test-driven Design，可供尝试。
在传统的设计方法下，设计师会花很多的时间在自己的方案上。但 Test-driven Design（测试驱动的设计）需要我们逆转思路，将 90% 精力转到寻求事实依据的过程上，将剩下的 10% 用于快速迭代方案，做到零纠结、零争论，将时间省下来放到多方案、迭代和验证上。
## 用最短的时间做原型
我们的目标是用尽可能短的时间构建一个最小可用化原型（Minimal Viable Prototype，由精益创业的理念启发），以便在设计验证中使用。千万不要在这个阶段输出完整的、包含所有细节的文档性方案（即使这样看起来会比较「专业」）。
How to do?
首先要快。使用自己最擅长的工具，维护一个高复用性的个人模版库，建立效率最高的 workflow 和工具协作体系，保持设计文件内部的干净和组织性（例如：Visio 的元素分组、PS 和 Sketch 的层次和图层命名），以便后续的快速迭代修改。
遇到自己不能确定的设计点，或者与其他人有不同意见的设计点时，首先寻找是否有已有的数据和事实支持。若没有，则避免过多讨论，快速输出多个可行方案，然后准备投放到下一步骤的验证过程中。避免任何双方都无法被说服的争吵，事实依据才是解决一切的钥匙。
站在客观的角度，避免「自我参考」或者「老板参考」的设计。时刻提醒自己：「我所知道、所观察到的，并不一定是对的」。
避免过度深入地探究未确定的细节。要记住：现在需要的并不是一个完整的方案文档，而只是一个用于测试和验证的原型。过于精细可能是有害的，这点需要设计师通过主观的判断去平衡。
在我的经验中，通常交互设计可以在1-2小时内完成多方案原型的快速构建。对于小规模的需求，这个时间可以被缩短到分钟级别。对于视觉设计，耗费的时间会久一些，但最长不要超过一个工作日。
原型最好是动态的、可操作、高保真的。不过这也视具体的需求而定。
## 边做边验证
设计师需要接触数据、专家和用户，对多方案的质量进行验证和评估。设计验证需要穿插在方案过程中，作为对方案的即时的有力支持。
数据搜寻是最简单的获取事实依据的方法，能够解决很多纠结点。设计师应有一定的数据分析能力，熟悉自己产品的后台数据系统，并且经常去那里寻找有用的信息。
我们可以使用成本最低的启发式评估（Heuristic Evaluation），通过专家和设计 leader 对方案进行筛选和建议。启发式评估能给设计师一个公开解释和辨析方案的过程，并且能发现一些可能忽略掉的要素。
但启发式评估依然是主观的。在很多时候，我们依然需要客观的用户研究方法。这些用研方法之所以可行，是因为我们将原来用在纠结方案细节、进行无效讨论的时间节省了下来。
使用快速、低成本、易执行的用研方法，例如用户访谈、原型测试等。
需要以对比的方式去执行用研和测试，不仅可以对比设计师的多个方案，也可以对比竞品。
测试要围绕着有与需求目标紧密相关的针对性指标进行，例如：某个流程耗费的时间、某个分支的短时间PV统计等等。方案在针对性指标的表现能够作为直接的决策依据。
在设计验证完成后，利用得到的事实依据修改、精化方案。如果方案内还有分歧点，那么就进行一轮小型迭代，准备下一次的设计验证。每次的设计验证应该越来越轻、越来越快，直到分歧点全部被消灭，我们就得出了理想的方案。这就是 Test-driven 的快速迭代过程。
Test-driven Design 与传统的设计方法不同的地方在于：方案不再是用研的目的，相反，用研是方案的目的，就像编程中的 Try & Catch。方案是工具，不是目标。目标是掌握事实，得到整个需求在用户体验层面的 insight，方案不过是在这个过程中的附属品。
## 长期研究
既然我们已经把眼界从方案的层面提升到 insight 的层面，那么我们就能看出：设计师的工作并不是一时的内容，而是贯穿在产品生命周期中持续的工作。
观察数据，看看之前得出的设计方案是否成功？如果没有成功，反思是哪些元素导致的？这些元素是产品上的，市场上的，还是其他方面的？
开始从各种渠道进行长期用户研究，如：A/B 测试、数据观察、路径分析、用户反馈、社交媒体舆情等等。
试着发现新的问题！
在整个过程中，我们所做事情的核心在于：对产品和用户形成越来越完善的 insight。每一个用研、每一次辨析，都会让我们对产品的 insight 加深一分，都会让我们对需求和方案的把握加强一分。
## 总结
我们发现：有了足够的事实依据和 insight，方案只是顺其自然的结果！这就是 Test-driven Design 最强大的一点：这不仅是一种设计方法，而是一套机制，让设计师产生 insight，让解决方案顺其自然出现的机制。所以我们也可以称其为 Insight-driven Design。
这是一个初步的、激进的想法，尚未通过实践验证。但现在的设计师们需要快速对陌生领域建立认识，需要边打边走、边做边学的自我更新和协同心态。传统的、以方案为核心的方法已经不再适用了。而 Test-driven Design，绝对是一种值得尝试的工作方式。
本文整理自：知乎问答，转载请注明原作者@吴亮
