跳出自己的舒适区
经过一个漫长的冬天，终于迎来四月的微风拂面，ROC平台作为小二搭建无线页面所需要的工具，从冬至春也完成了一轮优化改造。众所周知，前台的导购页面负责和用户进行最直接的沟通，所拥有的优化资源也更多，而这种幕后有着配置逻辑的工具页面所拥有的资源是非常缺乏的，项目过程中需要打破UED本来的角色设定，成为半个PD、半个交互、半个运营，这其中每一步的转变，都在和自己的舒适区告别，作为初入职场不久的新人，很愿意和大家分享过程中的一些小心得。
最初ROC项目优化需求推到手边的时候，觉得无从下手，因为平时做需求，总是先有PRD，再进行用户调研等设计工作；在这个项目中，遇到很大的困难就是前期没有相关的分析资料，因为最初平台是由前端开发自己搭建的页面，没有任何资料可参考，但如果不了解产品的定位、目标以及整个产品架构，直接着手做一些设计上的优化，无异于盲人摸象，对产品毫无帮助，在这种情况下介入项目，就需要先“向前看”，主动向之前的项目成员了解以前制定好的战略、产品定位等，并把目标人群、功能、特色这些内容都整理出来，这时候产品的整个面貌就在心里变的越来越清晰，过程中也慢慢对这个产品开始有感觉，这时候就是“往后想”的好时机，当思维还没固化的时候，基于已经收集的资料，往后想想未来可以如何发展；基于效率方面，在原来的功能上，通过流程和体验的优化，是不是就能提高运营的使用效率；基于产品特色，如果要成为很多小二工作中都离不开的工具，还可以做什么让它变的更好，总之要充分打开自己的脑洞，多思考。
当很难有一个人在有限的时间内把所有的功能、业务讲清楚的时候，要学会自己动手解决问题，其实有时候只要踏出一小步就好，而这一小步可能会带自己走得很远。
ROC平台是一个运营搭建活动页面的后台系统，最初自己是作为一个小白用户，通过最原始的办法，逐一的去使用里头每一个功能，去了解它的流程和构架，过程中常常感觉有些地方很迷惑，有些功能又过于晦涩，但自己永远不能代替用户的声音，还是要通过问卷和访谈的形式，了解运营集中的痛点是什么，锁定其中最主要的几大因素，提出自己的洞见，可能以往就只是做到这一步，但从一个项目的推动来讲，对于问题需要非常细致的拆解和分析，并且对产品要有清晰的全局认知，整合各个方面（技术、产品、运营等）的力量，找到最为合理有效的解决方式。 其中沟通以及清楚的表达想法是非常重要的一步，换句话讲就是，从用户体验的角度出发，用产品思维和业务方对接，其中这2点是非常重要的：
1.一开始先对焦方向，不要太细致的着眼于某个具体的实施策略，尽量把自己的思考路径展示给大家（精确的问题/策略/目标描述），这样只要大家对大方向表示认可，后续具体方案在团队火花的碰撞下可以做的更好；
2.不仅提供方案，还需要结合当前的状况以及可以争取的资源，按照资源投入产出比排出可行性计划，下表的价值评估模型可以作为参考；
以前听过很多分享，例如UED如何做提案，但实践起来它真的不是一个轻松的过程，是一个重重突围的过程，不仅仅是对外，更是对内的一种修炼，需要竭尽所能的坚持和学习。
在各方对优化的大方向达成了初步的一致后，就需要进一步把需求进行细化，最初为了解决运营小二对组件使用不熟悉的问题，UED整理出了一份详细的组件使用说明文档，来帮助他们了解使用方法快速上手，但在编辑的过程中就发现，组件库时常更新日后维护成本较大，另一方面线下文档的方式运营无法快速的找到对应组件进行查看。在这个过程中发现自己的问题，还是想事情的角度过于单一，陷入一种狭窄的思维当中，面对这种情况师傅就建议我，做事情不要仅仅在自己的专业领域打转，多和项目中的其他成员沟通。这时候我开始转变思路，把自己当作是项目owner，开始留意周围有没有可以整合的技术、运营或产品的资源，合力完成这件事情，于是找到技术PM沟通组件文档的落地方案，经过分析和讨论，文档的最终形式可以像iOS设计规范一样，做成可交互的线上网页形式，由多人维护，UED只要输出文档的主要框架（是什么、用来做什么、规范是什么、哪些可以配置）及模版样式，并且后来还讨论到，不同场景下文档的应用，譬如可以接入到钉钉答疑群中，以智能机器人的方式回答运营的问题… 设计师倾向于聚焦，深入细节、提升品质，但如果能照顾到大局观，先整体后局部的思路，事情也许会做的更好，也会越做越宽；另外一方面，在开会的时候多听多思考技术/产品/业务不同的视角和思路，常常能让自己学到很多。
如果只固守自己是UED的角色从专业角度思考问题，而不是从整个产品和团队出发，事情进展常常会停滞不前，但过程中如果懂得跨越和打破自己，迅速补位，主动承担责任，不仅能帮助项目拿到预期的结果，还会发现团队其他人更愿意支持你。
作为一个运营页面搭建工具，产品初期是由技术同学自己搭建完成的，伴随的易用性问题还是比较明显，信息分层不够明确、操作流程复杂缺乏引导等，从体验的角度出发，我一直坚持觉得应该UI重构，一并解决运营吐槽的问题，而不是在老UI的基础上进行东拼西凑的改造，没有办法从根本上解决问题，但面临的现实情况却是一方面时间非常紧迫，另一方面，前端资源既要进行后面页面的改造又要支持大促，面对这样的情况，作为对体验负责的设计师来说一度非常的纠结，但退后一步，客观的从整个产品的角度来看这件事情，通过一次次的培训与宣讲，已经帮助用户养成了比较稳定的使用习惯，新系统势必会带来新的理解和学习成本，站在PD的角度，衡量最后的投入产出比，迭代开发的方式确实更可取。
迭代开发，就如第二幅画中，我们的目标是造一辆车，帮助用户解决出行更快更方便的问题，在时间等外力的影响下虽然不能一次完成，但每一次的交付物都是完整、用户可用的。而增量开发中，每一次的交付物虽然精细，但对用户来说不可用，必须全部完成才能拼成一个完整的、可用的产品。
产品每阶段都有每阶段的目标，对于设计师来讲需要明确阶段问题，为了一个共同的使命和目标，适当调整设计节奏，充分考虑设计的阶段性计划，努力思考做什么样的事情更有价值，利用UED的优势，更好的帮助产品成功。
设计师和美工的区别应该是设计师具有“解决问题”的能力，而想要解决问题并不是单纯的站在某个角度提出自己的见解，需要拥有更多交叉行业的知识，提高自己的眼界和格局，而这种跨界的能力是需要自己不断努力不断摸索慢慢成长起来的，而坚持这个过程是很不容易的，“不舒适”的感觉会越来越强，但做过力量训练的人都知道，肌肉的撕裂和重生来自于“不舒适”。当自己能很舒适地做好多组数的时候，说明拿的重量太轻了，或者每组数量太少了，只有在最后做不下去，非常“不舒适”地坚持的时候，才有机会提高成绩，变成更好的自己。
来源：有一点
关键字：产品经理, ued
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
