很多设计师认为拿不到结果的问题出在方案评估与确认环节上。其实不然,任何一个环节处理不好,都会拿不到结果,或者拿不到想要的结果。
01.发现问题阶段找准问题:
能力要求:
对特定用户群特点和需求的了解。电子商务的用户与游戏网站的用户心理、生理特点是不一样的。若站在自己的角度而不是用户的角度去使用网站,发现问题,往往会有偏差。自己觉得好用的,用户真的会感觉非常无辜地不会用。同时,要细心,体贴入微,有时,解决问题的可能不需要大量的设计和开发,也许仅仅改一句文案就可以了。
对优先级排序的敏感性。有的时候,发现问题太容易了。没有完美的无懈可击的网站,没有完美的用户体验。真的存心找碴的话,放眼望去,网站都是问题。选择哪个问题首先出击?那些问题稍稍放后?那些问题暂不考虑?设计师心里要有个数,在资源有限的情况下,挑选最亟待解决,解决后最有价值的问题,提供优化方案。
挑选维度,可以有解决难度系数,解决后带来的价值,不解决的风险,损失等。
02. 提供方案阶段提供好的设计:
能力要求:
商业意识的敏感性,知道每次的改进不仅仅是感性的更加好用,用户更加喜欢,而是能够预知因此能够带来一些可量化的变化。即使是拍脑袋,也尽量训练自己慢慢拍得更加准确。
另外,对于好的设计的理解,更加透彻。
在提供方案前,除了要了解这个项目的需求(自己提出的,别人回馈的等),若是改进型的项目,更需要明了现有方案的问题,好对症下药。通过沟通和探求,要知晓其他人,尤其是重要人士对这个项目的期望。当然,在资源比较紧张的情况下,一定要事先了解限制。哪些功能虽然好,但是确实是做不了或者需要花很大成本才能够做的。否则提出一个自己认为很perfect但是在现有的架构和技术能力限制下,等同于空中楼阁的方案,是不可能拿到结果的。
盗用一张 design thinking 上的图片:
说的大概是同一意思。
但是,作为设计师,提出一个虽然很容易实现但是看起来有点没有水准的设计,也是丢face的。会不会被很多人挑战设计能力?
解决方法:同时提供两种方案,即,心目中理想的方案是什么样子,我们称之为蓝图,提供未来可能性的美好框架,给人们畅想的快感和希望。但是一定要同时提供这个蓝图的精简版可实施的方案。笔锋一转,由于目前受到什么什么的限制,我们无法做到什么什么,保留了什么什么功能,去掉了什么什么功能。所以提供一个可实施的方案如下,已经得到了评估,需要多少个人日开发量等等。
这样,既有设计师的面子,又有希望拿到结果了。
03.提案确认、评估阶段意愿驱动,结果导向
好,现在我们手中有了一个上述的好的设计方案了。接下来的主要任务就是让这个方案得到相关人士的认可,这些人包括:
老板,他有生杀予夺的大权,他说好,可以做,那么这个项目的阻力就小很多。
同部门同事,他们会从专业水平来对这个设计进行评审,到底好用不好用,有没有更好的办法这个时候可能会被信息轰炸掉,要注意鉴别,并非所有的意见都要参考的,毕竟每个人的立场不同,思考问题的角度和深入程度不同。。
需求分析(RA),前端人员和工程师:他们是要负责实现的,虽然在出最终的方案前已经让需求人员介入进行可行性分析,但是最终方案出了以后,一样要再次进行评估,此时不仅仅是可行性,也要评估具体的工作量,要实现这些设计功能和效果,前端需要多少人日,工程师需要多少人日等。
相关部门同事,如这条产品线的产品经理,毕竟是动了人家的土,也许某种情况下涉及到的产品线不止一方,可能同时需要和几个产品经理进行沟通协调,还有客服部同事,网站一经改动,他们就必须要通知到,不然怎么教客户用啊。所以,在没有正式上线前就应该让他们知道,另外作为一个与客户亲密接触的部门,他们也能够提供一些有用的信息,帮助我们进行改进。
记得王石在武大的一场讲座上回答登雪山难还是管理企业难还是做慈善事业难的问题时,他的答案是:登雪山最容易,因为只是在和自己与雪山打交道。管理企业次之,涉及到的人很多,做慈善最难,涉及到的人更多。
所以,与人打交道和协调本身就是不容易的事情。很多时候,用心力交瘁,劳而无功来形容一点都不为过。但是(对不起,又一个但是),不这么做,又怎么能够拿到结果呢?自己发起和主导的项目,是不能依赖产品经理的,要自己主动出击。
缠,磨,黏,死缠烂打种种招数,会哭的孩子有奶喝,这是老话。
出了意愿驱使去争取资源和认可外,当然也要对好的建议进行采纳吸收,踏踏实实进行方案的妥协和调整。
反正最终目的仍是得到认可,多方认可,直到把这个项目排在日程表上。
当然,我们还要求设计师是有大局观的,根据自己项目和别的项目对比得出的优先级排日程和资源就好了,不要太过了。。
能力要求:
多方沟通与协调能力还要求多语言能力,怎么说呢:
与工程师要用工程师的话语沟通,与数据分析人员要用数据平台的语言沟通,与设计同仁们则用设计的语言沟通,与老板们要以产品经理的语言沟通。与copy writer则要用英文沟通,设计师,尤其是新人,要主动地多和同事、别的部门的同学沟通,以掌握其语言特点。
承受挫折,卷土重来的心理素质
不可避免会碰很多钉子,可能你的改进虽然整体效果不错,但是可能会触及到某个产品经理的利益,可能影响到他的考核(比如流量的下降)。要说服他讲究大局观而放弃掉这些流量损失,是看似不可能的任务。所以在挫折下屡败屡战,绝对是心理素质,当然,也可以曲线救国,争取重要人士的支持。
理性预估项目风险与价值
设计师当然是感性的。但是现实是,你纵使拍疼了大腿给你的老板说:这个设计真的很好很好啊,用户一定会多么多么喜欢用的啊没用的。老板和别的贡献资源的同事们都眼巴巴问你要证据,你能拍着胸口承诺说:我保证用户一定会更喜欢用。那么,怎么保证?所以感性的设计师也要有预估项目收益的能力,当然,是量化的。比如,数据。改进前后流量的前后对比等。对着空气去预计当然有很大的风险,不过既然不做不行,就逐渐锻炼自己拍脑袋也越拍越准确。刚开始当然从最底线开始预估,最低达到多少,希望的结果是达到多少。不要过于保守不然大家没兴趣,不要过于冒进不然自己压力大。如何刚刚挠到痒处,着实还需要考虑考虑学习学习。
04.项目推进阶段团队协调与时间管理
我很崇拜古代的大将军。我为数不多的偶像级的人物里面有几位大将军,比如卫青,比如赵云,比如霍去病等。为什么呢,《明朝那些事儿》的作者讲得通俗易懂,打仗不是斗殴,是有很多技术含量的。比如,给我们10万人,让我们带着去西湖溜达一圈,能保证一个不少带回来就了不起了。更何况要完成一些非正常环境下的冲锋杀人的任务。所以,多方沟通很重要,带领团队更加重要。
作为发起人的用户体验设计师,有时为了拿到结果,不得已就要充当这样一个团队带领者的角色。管理的四大职能看起来是书本上的理论,但是若在实际情况下一一去对照,发现说得都是经典:
计划我们是planner,需要确定非常smart的项目目标,以及为了达到这个目标我们需要采取的行动(作业计划),还应该让每个人都清晰了解自己的角色和职责,最后让他们知道应该在什么时间完成这些工作。关键词:项目定义、目标、角色及职责、时间点。
组织我一直觉得自己组织能力欠缺。有些人从小就喜欢参加组织性的工作,比如文体委员,班长等,连居委会大妈都不是轻松的活,不是谁都干得来的。想想,要把性格各异,语言不同,思维方式和思考侧重点都不一样的人组织在一起完成共同的目标?天呢,对于很多设计师来将,真是恨不得自己撸了袖子单干!可是,逃避不是解决问题的办法。所以,对于像我一样本身有点内秀的设计师来讲,不妨开始硬着头皮尝试一下,从主动承担一些小的组织项目开始。
领导领导在这里我理解为主要是以身作则,以自己的形象、专业性去影响别人,让团队信服而不是去说服。同时,要有激励团队、鼓舞士气的能力,很多项目不可能顺风顺水,中途或许会遇到很多挫折,若遇到一点小意外,自己都乱了阵脚:发牢骚,烦死了这可怎么办,若想要拿到结果,这些字眼最好不要提。而且,要以更加积极的心态去应对,去鼓舞大家继续努力,宁可一条道走到黑
控制我以前经常抱怨我的老板控制欲很强,他恨不得我上班的8个小时完全是属于他的,他想知道我的项目进展,想知道任何细微的变化,直到有一天他对我更加信任了。有效的控制是促使团队更加有效达到目标的手段,而且能够控制在基本正确的道路和方向上。
关于这个阶段的管理能力(主要是团队管理和时间管理),偶也不是很擅长,也正在学习中,这里就不展开说了,免得贻笑大方。欢迎有兴趣的诸位多多探讨。《卓有成效的管理者》这本书,可以读读。
05.项目跟踪与总结阶段理性,数据分析
设计师已经拿到结果了,可以长吁一口气了,但是别忘了最后一个阶段,项目到底好还是不好,有没有达到事先设定的目标?毕竟我们的目标是拿到好的结果。这也关系到你的下一个项目能不能继续顺利立项和推进的重要因素。
要进行数据的跟踪,要具备数据分析能力。设计师在设计初期定了设计目标时,就应该有意识去考虑将来用什么样的方式验证设计的成败,是流量的增长还是黏度的增高?或者是其他?
也应该提前与数据分析人员沟通以确定你要的数据能不能取到,若不能,还要在开发过程中考虑如何布点以方便数据提取。
最后,来一份比较漂亮的总结报告,总结项目的得与失,总结下一步的改进建议。
(本文来源于图老师网站,更多请访问http://m.tulaoshi.com/pmsj/)这才是真正的完整的项目结果。恭喜你终于拿到了!
最后一句话:万事都是说着容易做着难。以上文章观点并非原创,而是来自国际站UED会议精华总结。
所以,看似简单的道理,人人都懂,看似简单的逻辑,实际上在实行中总是会有不可预见的障碍与困难。别看我写了这么多,现实情况中却做得提高的空间非常之大,无论是时间管理或者是主动沟通 以此文,希望与各位设计师共勉,一起进步。