作为一枚去年毕业的交互设计新人，我过去的设计工作流绝大部分是「等Prd评审 - 确认Prd疑问 - 提炼目标梳理架构 - 出交互方案 - 评审 - 跟进上线」这种，虽然从0到1做了不少大大小小的项目，也会去主动思考完善PD需求中的不少细节，但基本都是被动模式而缺少主动提案：被动接受来自PD或运营的完整需求描述，然后在对方给定的具体框架内进行交互设计。
后来随着对业务熟悉程度加深，我开始有意识尝试去主动做一些事情、进行一些改变，比如整理已有用户反馈、制作体验地图、搜集竞品、撰写体验分析报告等，这一部分起初因为经验不足等原因踩过一些坑（参见《回归本质：我的平台型产品设计分析缺了什么》），修改后给PD看后得到的反馈还算积极；而在开始尝试将「体验问题分析」转化为「具体解决方案」的过程中，也深感设计提案的不易之处，直到这周才真正把第一批具体的产品设计方案初稿交付PD、提上评审开发的议程。这次产品设计提案的正式评审修改、排期实现、数据反馈验证环节尚未进行，本文就先总结一下自己前半部分工作中从公司前辈处学到的经验与自己的心得吧（对于未上线或非对外公开项目不会有具体的项目细节配图描述，所以可能会写得比较虚，还请大家理解）。
核心目标的认知统一
设计师们多多少少有一些强迫症，看到某个细节有瑕疵就会吐槽「体验不好」，但要想拿一些所谓的「完美像素」、「遵循规范」、「可用性好」等去说服需求方与项目组，对设计细节本身不是那么敏感的他们却可能不那么在意，或者换句话说，相比「更好的用户体验」本身，大多数人更在意的是「更好的用户体验能否为当前的核心业务目标带来贡献」，和核心业务目标关联不大的设计优化提案，也更容易被划入「优先级低」的范围然后一再拖延。
如果想让自己的设计提案更好更快地得到大家的认同与推进落地，就要在设计方案所促成的问题解决上保持与项目组的核心业务目标同步，而忌自己闷头搜集思考、不主动和项目组沟通确认清楚各阶段业务目标，导致解决方案虽然有利于小环节用户体验提升，却对业务全局无关痛痒、甚至产生负面影响，而难以得到重视推进。
1. 不只关注Prd，主动了解更多业务相关资料信息
虽然最直接的资料Prd可以给我们提供很多业务目标与方向上的信息描述参考，但想要对此有更深入全面的理解的话，则需在平时更主动积极去关注更多相关资料信息，而不是等到Prd评审时才开始一切。
只要稍微留心一下项目组的邮件，不难得到来自运营、PD的各种Mrd、阶段总结报告、上线数据反馈等资料，这些都可以帮我们了解更完整的项目需求、项目现状、发展方向等的来龙去脉，知道最初的问题和用户痛点所在、业务现状不足与未来改进方向等，对Prd中加工后传达的概念有更接近本质的准确理解，减少只看Prd造成的信息传达损耗、引发的设计方向偏差。在更早的阶段（早于Prd评审）就参与到项目组的需求讨论会议（头脑风暴、故事会、Mrd评审等）也是同理，虽然在不是很了解业务时可能没多少发言的空间，但可以倾听获取来自不同业务方的更多信息反馈（他们本身就是核心用户或者对用户的接触了解程度非常深入，对B端产品来说这点尤其明显），帮助在头脑中建立起对业务更完整的印象。
2. 关注项目动态，多次沟通确认，减少信息滞后
因为战略调整、市场变化之类的因素，项目的业务目标不会是一成不变的，所以这就需要我们更多关注项目动态，反复多次和需求方沟通确认清楚各时间段项目的核心目标所在，并根据变化及时调整设计提案，减少信息获取滞后导致的无效设计工作增多。
孤立解决到整合延伸
在搜集分析了一些项目业务背景信息、市场竞品资料、用户调研数据反馈之后，我通过产品设计分析报告（涉及环节有多角色任务流程梳理、用户体验地图、用户诊断、用户目标分析、设计目标提炼、竞品分析等）的形式汇总提炼出了一批体验改进点，并撰写了初步的解决方案思路。
这样的好处是我可以对已有的体验问题有一个更完整全局的印象，将部分同一场景下的体验问题统一考虑整合到一个解决方案中去（碎片式解决视角有限，而且分次开发可能带来更多限制和复杂度提升），也可以在某个体验优化需求的基础上延伸出更多场景（比如用户反馈某个问题描述不清需要退回，我可以基于之前了解的其他信息迅速联想到除了描述不清，还可能有选错分类、选错人等情况出现，也同样适用于需要退回的场景），让解决方案覆盖到更大的范围中去。
虽然体验问题的分布本身很碎片化，但最终的解决方案却相对整体、考虑角度相对全面，用一套交互设计稿同时解决多个体验问题，而不是每个碎片的体验问题都单独出一遍交互，这样在交付和评审时也更加方便。
优先级与排期的划分
虽然经过了整合处理，但具体的解决方案点仍然有不少，一次性全完成交付显然不现实，这时就需要进行优先级与排期的划分了。
我目前的划分中主要考虑以下几个因素：和核心目标的相关程度、牵涉的待确认点多少、开发成本等。如果和当前阶段的核心目标关联不大、不是纯产品设计能解决的体验问题（如涉及业务逻辑变更）、实现成本大但收益比不高等，优先级就往后放，反之则前置。然后分批制定具体的设计、评审、交付上线时间等，这一块也需要多和项目组确认，减少和其他需求的冲突。
对于优先级与排期，我还没有多少实践经验，相信有很多产品经理和用户体验设计同学都要比我熟悉、专业得多，所以这块不谈太多，仅供参考，也欢迎经验更丰富的同学指教。
