以用户为中心的设计 |
这是UCDChina提前预览网页留下的存档,不包括作者可能更新过的内容。 推荐您进入文章源地址阅读和发布评论:http://heidixie.blog.sohu......19556358.html |
||
记得入职不久时,受会议讨论启发,写过一篇长文《设计师如何有效拿到结果?》,主要是说设计师如何发起项目,并有效进行推动,还是在执行力层面上吧。 后来,设计师在发起项目中,以及参与项目提供方案中,发现说服力变得越来越重要。 凭什么让合作方相信,你发起的项目是有价值,让他们愿意把资源投入到你的项目里? 凭什么让需求方采纳你提供的设计方案?让他们相信是最合适的解决方案? 所以说,由于设计师是需要靠别人的认同最终落实设计方案,完美的执行力上面有重要的一个环节就是:说服力。 其实,作为设计师,我们不想要“说服”别人。理想中的状态是,一个好的方案摆出来,大家自然都接受,产生共鸣,轻而易举得到一致通过。 但是,现实的问题: 1. 大家没有一致通过的原因可能不是出在方案本身,而是涉众的利益没有得到平衡。
2. 涉众越多,喜好偏向越多,很难得到统一的意见——在团队里讨论一下吃饭问题就可以知道。 说服力从哪里来? 说服力这个词语很容易联想到“说”的技巧。 可是我观察那些容易拿到结果的设计师,观察那些有说服力的非设计师同事们。我发现有些说话结结巴巴,看似也有点木讷的同事,通常在讨论中发言很少,在别人发言的时候总是安安静静但是只要说话,大家都很认同并表示尊敬。甚至,他不用提供什么“证据”比如数据、引用材料等。 好的说服力绝对不是靠一张口若悬河的嘴,靠三寸不烂之舌——我承认,有这个条件,能够给说服力加分。 令人信服的说服力背后有着其他的更加重要的因素——是它们在背后默默支持着说服力的呈现。
做有说服力的设计师!加油! 现在有两个设计师,小A和小B。他们同时接手到一个项目,他们分别展开行动。 小A是一个非常有创意的设计师,想法非常多,行动也很快。小A在接到需求后,二话不说,就啪啪啪做了好几个不同的方案。 而小B在接手后的第一天,完全就没展开“任何”行动。他反而拉着需求方讨论个不停,问他们想在什么时候发布,对他手里拿到的需求文档进行了详细的阅读,有一些问题反复去找需求方确认并讨论。他甚至还跑到技术部去讨论,问一些“和设计无关”的问题,问这样做可不可以,那样做可不可以,问得人很烦。然后,他还是没展开“行动”,他花费了一个下午的时间去“浏览”网站,看起来很悠闲。 而小A在第二天已经召集大家过来看方案了。小B才开始动工。 小A提供了5套不同的方案供大家选择。 小B只提供了2套。 可是,小A在评审会上,被大家问得很狼狈:
而,小B的评审会进行得很顺利,他上来展示了两套方案,各自展示了优缺点后,讲述了一下为什么要设计成这样。大家问到为什么不设计成“那样”时,小B说他很想设计成那样,但是由于咨询时发现技术有限制,目前实现的成本非常大,如果项目经理愿意让项目发布日推迟,我们会非常乐意的。在现场的技术评估方和项目经理经过讨论,达成共识,就先设计成这样。 有同事提出为什么不采用别的网站的做法?他们印象中好像那样更好。 小B事先就已经准备好了他们提出的网站的截图,拿出来说目前的设计方案已经采用了对方的一些优点,同时对对手的缺点进行了一些优化。 评审会顺利结束。采用了小B主推的那个方案——小B说其实另外一套就是个陪衬。 小B说:只所以有说服力,是因为在设计之前,已经综合考虑了各种会影响设计方案的因素:老板的期望、需求方的期望,技术的可行性,时间的限制,以及竞争对手的研究。如果时间允许能够做一些用户调研和访谈就好了,那样会让设计“更靠谱” 你愿意做小A还是小B? 做小B,你不仅能够拥有日渐顺利的评审会,也会逐渐建立起个人影响力,也会逐渐积累成功经验——当然,这样的前提是:你对方案本身是有信心的。自信心是有说服力的前提。做正确的事情,是说服别人的原则。 好吧,任何道理都要落实到行动计划上才算靠谱。谁不想让自己具有说服力呢?观察一下你身边的小B设计师,他们是如何有说服力的?在设计之前,他们都做了哪些事情?问对了哪些问题?还是用图形化的语言来表达一下: 在做设计之前,不妨磨磨刀。 1. 了解期望:需求方的需求和期望?他们想做成啥样?别说别人不专业。举个例子,某次我们有个大项目要发布上线了,项目组负责人让设计师帮忙做个很炫的发布通知——用来群发邮件用的——某某项目发布了!设计师做了一个很神秘很美丽很个性以蓝色星空和火箭为背景的发布页面,到了deadline交付的时候,对方不满意,原来他们心目中的发布通知是“热闹、喜庆、胜利”的感觉。 了解期望不一定非要按期望去做,但是不了解期望就是不好的开始,对后期的说服力挑战更大,对方即使接受了心也有不甘。 2. 了解需求:需求方的需求、其他涉众的需求(比如销售、客服等),了解外部的需求(用户等)。这些需求需要被平衡。 3. 了解限制:给你10天的时间和只有1天,做出来的方案肯定是有区别的。任何商业环境下的项目都有一定的预算(时间、人力和资金),你需要了解你拥有哪些限制。这些限制有——时间的deadline:你需要在哪天交付出什么东西?不同阶段的交付物是不同的。技术的可行性如何?你需要事先带着想法咨询有关专家。 4. 了解风险:上面说的发布通知的案例同样可以使用在这里——项目负责人经过修改,终于群发了邮件。大家松了一口气。可是却没有任何反响。这不对劲,因为从我们的经验来讲,如此重要的项目一旦发了发布通知,就会有很多的“顶贴”:太好了,太激动了!为项目组喝彩之类的。可是那天犹如石沉大海。我们几个人去看邮箱时才发现没有收到,再一看,原来被自动归类到了垃圾箱里。原因是邮件里的图片太大了...如果事先考虑到这一点,是可以避免这种情况出现的。 5. proof:为你的设计方案提供足够的证据,你可以通过数据、案例、第三方或者自己执行的调研报告…… 最后明确一个提高说服力的正确前提:不可滥用说服力哦,问问自己的动机,想树立个人的威信?是要一时的说服人带来的成就感?是不是维护自己的面子?确保你是确实想让事情变得更好。有时做正确妥协比说服别人更加难,更加重要。 |