好文拾遗:跳出自己的舒适区

流苏    点击:    日期:2017-10-10    资讯分享

ROC平台作为小二搭建无线页面所需要的工具,从冬至春也完成了一轮优化改造。众所周知,前台的导购页面负责和用户进行最直接的沟通,所拥有的优化资源也更多,而这种幕后有着配置逻辑的工具页面所拥有的资源是非常缺乏的,项目过程中需要打破UED本来的角色设定,成为半个PD、半个交互、半个运营,这其中每一步的转变,都在和自己的舒适区告别,作为初入职场不久的新人,很愿意和大家分享过程中的一些小心得。


最初ROC项目优化需求推到手边的时候,觉得无从下手,因为平时做需求,总是先有PRD,再进行用户调研等设计工作;在这个项目中,遇到很大的困难就是前期没有相关的分析资料,因为最初平台是由前端开发自己搭建的页面,没有任何资料可参考,但如果不了解产品的定位、目标以及整个产品架构,直接着手做一些设计上的优化,无异于盲人摸象,对产品毫无帮助,在这种情况下介入项目,就需要先“向前看”,主动向之前的项目成员了解以前制定好的战略、产品定位等,并把目标人群、功能、特色这些内容都整理出来,这时候产品的整个面貌就在心里变的越来越清晰,过程中也慢慢对这个产品开始有感觉,这时候就是“往后想”的好时机,当思维还没固化的时候,基于已经收集的资料,往后想想未来可以如何发展;基于效率方面,在原来的功能上,通过流程和体验的优化,是不是就能提高运营的使用效率;基于产品特色,如果要成为很多小二工作中都离不开的工具,还可以做什么让它变的更好,总之要充分打开自己的脑洞,多思考。


当很难有一个人在有限的时间内把所有的功能、业务讲清楚的时候,要学会自己动手解决问题,其实有时候只要踏出一小步就好,而这一小步可能会带自己走得很远。



ROC平台是一个运营搭建活动页面的后台系统,最初自己是作为一个小白用户,通过最原始的办法,逐一的去使用里头每一个功能,去了解它的流程和构架,过程中常常感觉有些地方很迷惑,有些功能又过于晦涩,但自己永远不能代替用户的声音,还是要通过问卷和访谈的形式,了解运营集中的痛点是什么,锁定其中最主要的几大因素,提出自己的洞见,可能以往就只是做到这一步,但从一个项目的推动来讲,对于问题需要非常细致的拆解和分析,并且对产品要有清晰的全局认知,整合各个方面(技术、产品、运营等)的力量,找到最为合理有效的解决方式。 其中沟通以及清楚的表达想法是非常重要的一步,换句话讲就是,从用户体验的角度出发,用产品思维和业务方对接,其中这2点是需要注意的:


1.一开始先对焦方向,不要太细致的着眼于某个具体的实施策略,尽量把自己的思考路径展示给大家(精确的问题/策略/目标描述),这样只要大家对大方向表示认可,后续具体方案在团队火花的碰撞下可以做的更好;


2.不仅提供方案,还需要结合当前的状况以及可以争取的资源,按照资源投入产出比排出可行性计划,下表的价值评估模型可以作为参考;


以前听过很多分享,例如UED如何做提案,但实践起来它真的不是一个轻松的过程,是一个重重突围的过程,不仅仅是对外,更是对内的一种修炼,需要竭尽所能的坚持和学习。



在各方对优化的大方向达成了初步的一致后,就需要进一步把需求进行细化,最初为了解决运营小二对组件使用不熟悉的问题,UED整理出了一份详细的组件使用说明文档,来帮助他们了解使用方法快速上手,但在编辑的过程中就发现,组件库时常更新日后维护成本较大,另一方面线下文档的方式运营无法快速的找到对应组件进行查看。在这个过程中发现自己的问题,还是想事情的角度过于单一,陷入一种狭窄的思维当中,面对这种情况师傅就建议我,做事情不要仅仅在自己的专业领域打转,多和项目中的其他成员沟通。这时候我开始转变思路,把自己当作是项目owner,开始留意周围有没有可以整合的技术、运营或产品的资源,合力完成这件事情,于是找到技术PM沟通组件文档的落地方案,经过分析和讨论,文档的最终形式可以像iOS设计规范一样,做成可交互的线上网页形式,由多人维护,UED只要输出文档的主要框架(是什么、用来做什么、规范是什么、哪些可以配置)及模版样式,并且后来还讨论到,不同场景下文档的应用,譬如可以接入到钉钉答疑群中,以智能机器人的方式回答运营的问题… 设计师倾向于聚焦,深入细节、提升品质,但如果能照顾到大局观,先整体后局部的思路,事情也许会做的更好,也会越做越宽;另外一方面,在开会的时候多听多思考技术/产品/业务不同的视角和思路,常常能让自己学到很多。


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



作为一个运营页面搭建工具,产品初期是由技术同学自己搭建完成的,伴随的易用性问题还是比较明显,信息分层不够明确、操作流程复杂缺乏引导等,从体验的角度出发,我一直坚持觉得应该UI重构,一并解决运营吐槽的问题,而不是在老UI的基础上进行东拼西凑的改造,没有办法从根本上解决问题,但面临的现实情况却是一方面时间非常紧迫,另一方面,前端资源既要进行后面页面的改造又要支持大促,面对这样的情况,作为对体验负责的设计师来说一度非常的纠结,但退后一步,客观的从整个产品的角度来看这件事情,通过一次次的培训与宣讲,已经帮助用户养成了比较稳定的使用习惯,新系统势必会带来新的理解和学习成本,站在PD的角度,衡量最后的投入产出比,迭代开发的方式确实更可取。



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


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


设计师和美工的区别应该是设计师具有“解决问题”的能力,而想要解决问题并不是单纯的站在某个角度提出自己的见解,需要拥有更多交叉行业的知识,提高自己的眼界和格局,而这种跨界的能力是需要自己不断努力不断摸索慢慢成长起来的,而坚持这个过程是很不容易的,“不舒适”的感觉会越来越强,但做过力量训练的人都知道,肌肉的撕裂和重生来自于“不舒适”。当自己能很舒适地做好多组数的时候,说明拿的重量太轻了,或者每组数量太少了,只有在最后做不下去,非常“不舒适”地坚持的时候,才有机会提高成绩,变成更好的自己