![](\"https://main.qcloudimg.com/raw/7e025d0cc8ff62168ad0914d825bea1f.png\")
我们所说的设计思维，是指由 IDEO 公司的 Tim Brown 提出，并且正在改变全世界组织的设计思维，简称 DT。
\n\n\n译者注：IDDO，当代最具影响力的设计公司之一
\n
该理念承诺带来更高的生产效率和创新，促进与用户建立更好的联系。
\n听起来很不错，对吧？所以我们亲自尝试了一下。
\n在这个过程中，我们取得了一些进展，也经历了一些挫折，还遇到了一些其他事情。\n如果您正在考虑采用设计思维，或者只是大体上考虑您的产品流程，不妨继续阅读本文，了解下我们的尝试。
\n简而言之，设计思维流程针对的并非如何执行，而是如何在一开始决定应该构建什么内容。
\n它以一个紧密的用户驱动型反馈环路为中心。理论上，这个闭环可使您在开始写产品代码前尽可能迅速地验证新的功能想法：
\n
对于我们这样的科技公司，设计思维意味着：
\n其结果是新功能首先在小范围的产品中提供，然后由用户验证，最后才进行实际的开发工作。
\n这个过程中还有一个关键点：公司的所有部门之间会一直沟通。销售部门不会在几次交谈后就告诉工程部门应该构建什么产品，产品部门也不会告诉销售部门直接卖我们想做的产品。
\n每个部门都会和用户沟通，然后共同提出产品战略。
\n敏捷的好处在于您可以将项目细化，以便确定更合理的优先级。设计思维可同时在微观和宏观层面上支持实现敏捷。
\n微观层面上，设计思维可用于验证各项功能。它符合敏捷框架，可帮助我们在迭代计划时始终专注于优先级最高的项目。
\n宏观层面上，设计思维使一切工作回归于公司的愿景，提醒我们不断重新评估当前工作，以长期为我们的用户提供更好的服务。
\n设计思维似乎天生适合我们公司。
\n现在介绍我们在 Serverless 公司内部是如何开展设计思维这六个步骤的。
\n共鸣：\n我们在 Confluence (Atlassian) 上设置了一个产品类别板，公司的任何人员均可提交用户问题。这些问题来源于任何真正可以发现实际用户问题的地方，包括直接的用户访谈、文章、论坛话题、漏洞报告和个人经历等。
\n设想：\n任何人员还可以提交如何解决已确定用户问题的想法。我们的提交指南明确规定了所有解决方案均应从用户的角度进行阐述。有什么作用？要执行什么操作？期望产生什么结果？
\n定义：\n产品团队每周审查类别版块，对需要进一步验证或需要进一步发现的内容加以标注。\n在审查的基础上，我们会对每个项目分配以下一个优先级：
\n原型：\n产品团队查看待办事项列表，并共同拟定我们接下来要关注的原型。工程团队接收原型，并将它们纳入敏捷规划管道。
\n测试：\n如果一切符合要求，并且该想法可以很好地解决实际的用户问题，我们会将其转换成提案，纳入到中期路线图中。
\n实施：\n这些提案阐述了我们接下来 3-6 个月之内要在生产环境中实际构建的最佳构想产品。此外，我们还会进一步围绕每个提案定义 KPI，以便可以不断地衡量所取得的成功。
\n设计思维目前的确给我们带来了不少积极影响：相比于我们想一次性执行的大项目，我们的工作更专注于组成整体的细小部分；通过论坛、Slack 或者访谈，我们能与用户不断沟通，有助于我们保持坦诚相待；我们充分利用设计思维来确保一组经过验证的功能得到实施。
\n尽管一些旧习惯仍然在无形之中影响着我们，到这我们目前的执行还不是很完美，但我们比较乐观，也取得了一些进展。
\n不过，我们也发现了一些不足之处，至少对我们的团队来说确实如此：
\n此外，您可能时不时会看到 设计思维会抹杀创意 这样的观点，导致您不由地怀疑所作的努力。这时，您需要自行决定是否放弃。😉
\n如此看来，设计思维并非十全十美。但老实说，我们也很难想象出其他替代办法。
\n我们可以基本上舍弃流程，而是每月将所有人集中到办公室，让他们发表各自的看法。或者我们可以走另一个方向：始终让一个开发组长决定所有开发人员应该做什么，但如果这样做，对产品流程提供想法和意见的人将少之又少。
\n我们或许可以采取 Google 的方法，让团队中每个成员各自分配出 10% 的时间来做用户调查和调整新的想法（事实上，这主意听起来还不错）。
\n这又归结到一个经典问题 —— 任何体系都存在缺点。但至少，我们已经有一个可用的体系。
\n我们可能会继续采用设计思维，也会在此基础上做些试验和调整。
\n您对此有什么看法？您觉得怎样改善设计思维会让其更加适合初创公司？我们很期待了解别人是如何运用设计思维的！
","tableOfContents":"