这时候我开始转变思路，把自己当作是项目owner，开始留意周围有没有可以整合的技术、运营或产品的资源，合力完成这件事情，于是找到技术PM沟通组件文档的落地方案。经过分析和讨论，文档的最终形式可以像iOS设计规范一样，做成可交互的线上网页形式，由多人维护，UED只要输出文档的主要框架（是什么、用来做什么、规范是什么、哪些可以配置）及模版样式。

　　并且后来还讨论到，不同场景下文档的应用，譬如可以接入到钉钉答疑群中，以智能机器人的方式回答运营的问题… 设计师倾向于聚焦，深入细节、提升品质，但如果能照顾到大局观，先整体后局部的思路，事情也许会做的更好，也会越做越宽；另外一方面，在开会的时候多听多思考技术/产品/业务不同的视角和思路，常常能让自己学到很多。

　　如果只固守自己是UED的角色从专业角度思考问题，而不是从整个产品和团队出发，事情进展常常会停滞不前，但过程中如果懂得跨越和打破自己，迅速补位，主动承担责任，不仅能帮助项目拿到预期的结果，还会发现团队其他人更愿意支持你。

　　4.发挥专业优势和业务一起成长

　　作为一个运营页面搭建工具，产品初期是由技术同学自己搭建完成的，伴随的易用性问题还是比较明显，信息分层不够明确、操作流程复杂缺乏引导等。

　　从体验的角度出发，我一直坚持觉得应该UI重构，一并解决运营吐槽的问题，而不是在老UI的基础上进行东拼西凑的改造，没有办法从根本上解决问题，但面临的现实情况却是一方面时间非常紧迫。

　　另一方面，atv，前端资源既要进行后面页面的改造又要支持大促，面对这样的情况，作为对体验负责的设计师来说一度非常的纠结。但退后一步，客观的从整个产品的角度来看这件事情，通过一次次的培训与宣讲，已经帮助用户养成了比较稳定的使用习惯，新系统势必会带来新的理解和学习成本，站在PD的角度，衡量最后的投入产出比，迭代开发的方式确实更可取。

　　迭代开发，就如第二幅画中，我们的目标是造一辆车，帮助用户解决出行更快更方便的问题，在时间等外力的影响下虽然不能一次完成，但每一次的交付物都是完整、用户可用的。而增量开发中，每一次的交付物虽然精细，但对用户来说不可用，必须全部完成才能拼成一个完整的、可用的产品。

　　产品每阶段都有每阶段的目标，对于设计师来讲需要明确阶段问题，为了一个共同的使命和目标，适当调整设计节奏，充分考虑设计的阶段性计划，努力思考做什么样的事情更有价值，利用UED的优势，更好的帮助产品成功。

　　设计师和美工的区别应该是设计师具有“解决问题”的能力，而想要解决问题并不是单纯的站在某个角度提出自己的见解，需要拥有更多交叉行业的知识，提高自己的眼界和格局。

　　这种跨界的能力是需要自己不断努力不断摸索慢慢成长起来的，而坚持这个过程是很不容易的，“不舒适”的感觉会越来越强，但做过力量训练的人都知道，肌肉的撕裂和重生来自于“不舒适”。当自己能很舒适地做好多组数的时候，说明拿的重量太轻了，或者每组数量太少了，只有在最后做不下去，非常“不舒适”地坚持的时候，才有机会提高成绩，变成更好的自己。