大家好啊，这周在汇报中连轴转，关于设计师的设计过程上有了新的工作心得，就是以结果推动设计过程，我觉得可以就此分享一下。
我们通常做的是以原因推导出结果
在日常工作中，从大老板提出一个产品的愿景开始，直到抵达设计师手上，可能已经变成了一个具体的设计需求，有大量关于产品愿景的信息在传达过程中，因为不同岗位的人理解偏差，逐渐被定义到具体的执行任务。这个过程本身没有问题，但是对设计师或者任何一个执行岗位来说，长期做一些执行任务，是难以清楚地了解产品全貌的。
这个时候，我们作为设计师，可以使用 IDEO 提出的设计思维，按照"理解——定义——创意——原型——测试——实施"这样的环节去推动设计落地。这个过程，也没有问题，过去五六年间有大量的实践证明这样的流程是可行的。但是，我发现，这个过程是正向的，也就是说，在理解、探索、实施之前，我们对结果是未知的。
结合图例来讲解可能会比较好理解一些，请看下图，整个设计过程分为了"理解"、"探索"、"实现"三个大的阶段，在"实现"，也就是 todo 之前，我们需要完成"why"、"how"的探索和定义。那么，如果在前期对愿景模糊的情况下，极有可能从"理解"阶段就出现了偏差，那么，落地后的设计成果，也许只能让少数人满意。我认为这个是设计师在进行做目标推导时，非常值得关注的一点，需要给自己问一个问题：我做的设计，结果真的会让老板（提出愿景的人）满意吗？
如果用结果倒推，会怎么样？
既然从目标推动设计落地，可能会出现目标偏差问题，那么，我们能不能倒推一下，先确定结果，然后来推动设计实施？
打个比方。
大老板提出了一个3-5年的产品愿景，他想要的结果是：做出一个行业内拥有优秀用户体验的产品；
往下是产品总监，他想要的结果是：先上线一个功能虽少，但是用户体验足够好的 MVP 版本；
接着是产品经理，他负责单个功能的规划，需要和多位产品经理共同协作，制定一份功能清单，他想要的结果是：做出一个用户体验优秀的功能；
然后是设计师，对产品经理想要的结果进行访谈、定义，逐步明确目标，一步步完成设计实施。到设计师这一层，也许想要的结果已经是一个体验设计规范，一个动效体系等等，为了达到这个结果，付出相应的努力。
以上过程当然省略掉不少真实信息，但是这个流程我们在工作上非常常见，我们尝试在这个过程中加入对"结果"的提问和阐述：对待上游的同事，可以提问他想要的结果；对待自己的产出，可以向上游的同事，阐述自己想要的结果。
总结起来就是，我们在对齐需求信息时，与其用"Wish"来对齐，不如用"Result"。比起"我希望这个产品会怎么样"，不如试着说出"我想要一个什么样的结果"。
OK，以上就是我个人对我们在设计过程中，遇到目标偏差问题时，试着用结果来推导过程的一点见解。如果你阅读完之后，有什么想跟我继续讨论的，欢迎到即刻上找我，我的ID是： 显济Jeffery ，感谢你的阅读。
查看往期可以访问这个语雀知识库： https://www.yuque.com/hexianjijeffery/va5umz
