1.3 设计的“推力”

设计过程的推力，其实可以简单地理解为协同其他的资源和角色，并纳入你的设计实现过程中。这样，有助于设计从被理解到被增益，方案实现从不被埋坑到日臻完美。

设计师在职业生涯中或多或少会遇到自己熬夜赶出的方案在项目团队评审中遇到很大挑战和阻力；更严重的情况是执行团队准备好向上汇报的设计方案屡遭否决；抑或是即便在需求评审、设计评审、系统分析评审环节全程不落地跟进，但到验收测试环节仍然发现设计定义传递存在大打折扣的情形。这往往是由于整个项目团队没有或无法获得设计共识的结果。这样的设计结果很容易得不到认可和信服。

设计只是产品的关键组成部分，但不是全部。设计的结果是团队各方角色传接配合的结果。

项目推动初期，设计师应该在核心数据指标、产品价值、阶段目标、设计概念、体验问题范围等方面达成项目团队的共识。当然，依据不同的团队文化及产品阶段，设计师可能是部分内容的定义者，也可能是被告知者。但共识是一定要确保的。通过产品数据分析定位问题示例如图1-1-3所示。

图1-1-3 通过产品数据分析定位问题示例

一个成熟的设计师，在对产品现阶段目标及体验问题有了清晰的定位后，分别与产品负责人、搭档设计师，乃至核心开发同学达成共识，并有理有据地阐释出产品在体验上应该规划若干个迭代分别完成的产品体验改进内容。甚至，成为一个项目牵头人，担当为资源协调和目标推进负责的角色。

关于一个产品的设计改版，设计师发挥价值的空间可以很大。设计师首先应该定义问题并与团队达成共识，达成共识前需要你了解产品的关键业务指标，并利用好客观的数据分析（示例模拟了一个产品基础数据的分析，供参考）。接下来，规划体验改进的计划，策略上可以以重要性、整体与局部关系、达成难易程度以及实现周期来梳理你的规划。

达成共识，可能需要经历好几轮的沟通，尤其当你需要自下而上形成共识时。讲究基本的沟通技巧是必要的，例如先倾听后表达、先当面口头表达再书面阐述、先影响身边的第一层关系再逐渐扩大沟通范围，等等。当然，最好的沟通基础就是客观“真相”，你需要做好桌面工作，掌握足够的依据来佐证你的结论。

关于“推力”，另一个关键控制点是注重设计交付文档的完善程度。一定有设计师认为设计只要服务于产品的真实用户就足够了。其实具备“服务体验意识”的设计师，会很认同他同样要服务于自己的上游和下游的项目伙伴。受感性、自由意志主导的设计师们，通常会非常不愿意将自己的设计产出扣入严谨的框架中。所以为什么说，意识决定行动，关键看自己是不是认为重要和值得。

事实上，顾全设计交付物所面向的“用户”需求，会令你的设计离成功更近一些。一份文档设计可能会面对全新搭档，一个不明项目背景的视觉设计师；可能面对临时调入项目组增援的开发人员；可能面对需要编写测试用例的测试人员；可能面对希望了解产品功能细节的客户服务人员（他需要处理客户咨询和投诉）；也可能在几个月后的一次重要迭代中重新被调出查看，等等。体验迭代规划示例如图1-1-4所示。

图1-1-4 体验迭代规划示例

将设计交付物视为串联整个项目成员高效协同的工具，可以承接诸多阅读角色的需求并呈现特定阶段产品的发展状态。一份优秀的文档要求设计师要照顾到产品经理、开发人员、测试人员等所有角色视角并满足其工作需求，还必须具备完善清晰的信息框架，符合阅读者的常规浏览预期，在不依赖于其他文档铺垫的情况下能完成对设计方案全貌和细节的学习。做到此，应该是一件难度非常高的事情了，这会要求你对各个配合角色的工作内容和思维要点有一定深入的理解。

设计交付文档一般建议包含图1-1-5中的内容，以便指导文档的组织，帮助你的设计思路被更高效地传递。让一份好读的文档替你说话，甚至为你的专业度加分。

图1-1-5 推荐的设计文档结构