加入收藏 | 设为首页 | 会员中心 | 我要投稿 PHP编程网 - 黄冈站长网 (http://www.0713zz.com/)- 数据应用、建站、人体识别、智能机器人、语音技术!
当前位置: 首页 > 运营中心 > 交互 > 正文

阿里专业干货!用户体验设计进阶修炼的思考总结 交互设计

发布时间:2016-10-20 13:04:54 所属栏目:交互 来源:产品壹佰
导读:副标题#e# 注:如何形成自己的设计方法,建立交付物的衡量标准,优化协同模式。在这篇文章里,你可以看到一个阿里专业设计师是如何进行自我提升的。 鸿影:如果2015对我来说尚处于用户体验设计的职场入门阶段,2016的核心则是开始撕下初级与新人标签的进阶
副标题[/!--empirenews.page--]

注:如何形成自己的设计方法,建立交付物的衡量标准,优化协同模式。在这篇文章里,你可以看到一个阿里专业设计师是如何进行自我提升的。

鸿影:如果2015对我来说尚处于用户体验设计的职场入门阶段,2016的核心则是开始撕下初级与新人标签的进阶修炼。4月份的2016 S1开始的时候,我给自己设定了包括形成个人设计方法论与应用案例等一系列目标,如今S1结束,也是时候对这段时间的进阶修炼来一个总结回顾了。

形成自己的设计方法

在公司内部经常会有一些跨部门的UED分享活动,听下来个人最明显的一点感触就是,这些来分享的设计师普遍有着一套自己思考总结出来的设计方法论,并且有成功应用案例支撑。

也许有人会有疑惑,现在关于设计方法的轮子到处都是,网上随便一搜就能找到某某大厂某某大牛的设计方法分享,直接拿来用就好了,为什么还要费心费力自己造轮子呢?

在我自己的设计方法还没有完全成型时,我一度很迷信于网上别人的各种设计方法的分享,并试图在自己的项目里加以运用,但结果却差强人意:设计推导的过程看似洋洋洒洒专业性十足,拿出来给别人一看一讲就发现漏洞百出;有时为了套方法而套方法,体验地图一类的输出物看似有模有样,最后项目做完了才发现设计方案时基本没用到……虽然自己用的都是别人经过验证的设计方法,但却没有理解透这些方法的应用场景与局限所在,也不清楚哪些环节其实并非必要存在,自然也让实际的应用效果大打折扣。而靠自己思考、沉淀和交流改进出来的设计方法,理解和运用起来则要透彻顺手很多。

如何形成自己的设计方法?最好的途径是跟着项目走,尤其是要主动去争取那些介入节点早、体验驱动强、完整性高的项目机会(我自己的设计方法就是在一个UX作为Owner驱动的网站改版项目中形成的,这个项目中的Owner角色争取也是主动向PD提出,然后得到对方放权的),作为设计师,从最开始的业务问题分析与用户调研,到最后的系统设计方案产出,每个环节都深度参与,对一些前期的工作要摒除掉「这是用研干的」、「这是PD干的」的思维局限,而采用和专业人士共创输出的方式;因为设计方法是一个很完整的发现问题-分析问题-解决问题-验证效果的过程,如果总是让产品经理把用户痛点和解决方案全部梳理好给你,自己满足于做一些交互细节的优化与补全(这也是我觉得大公司的大型设计团队不一定那么好的重要原因,想接触高完整性、高自由度的项目偏难,虽然也会羡慕他们能花很多心思去打磨动效等体验细节),而不是主动争取更早的介入时机与更多的项目话语权的话,是很难在项目里建立起全链路的思维方式,进而提炼总结出自己的设计方法的。

在建立设计方法的过程中,除了从项目的每个环节中思考提炼以外,也要多吸收前人的经验(不是无脑照搬,而是有意识去找业务背景、产品类型相通的应用案例),多和经验比自己丰富的同事请教交流,不断修正优化自己的设计方法,而不是幻想着一劳永逸。

uisdc-hy20161016-3

建立交付物衡量标准

大厂的实习生/校招生入职后基本都会有Mentor(我厂内部的叫法是师兄)带着,设计交付物往往都是先经过Mentor的一轮Review,再正式拿去和大家评审,Mentor们能发现很多我们自己没注意到的问题,指导我们做出改进。

但对于Mentor的过于依赖(无论项目大小都要找Mentor看一遍,遇到问题直接问Mentor解决方案而不是自己先想出方案再请教),则会让我们丧失独立思考与判断方案好坏的能力(两年前我曾被一位Mentor这么批评过),我是很难相信一个独立思考能力弱的设计师可以做到真正的「独当一面」,而「独当一面」的能力正是初级设计师与高级设计师的重要分水岭之一。

怎么更准确全面地思考和判断自己的设计方案的好坏呢?我的应对策略是给自己建立一套完整的交互设计方案衡量标准,再用这套标准去要求和驱动自己做出更好的设计。我的这套衡量标准建立也不是一朝一夕,而是在项目中不断总结沉淀自己踩过的坑,再结合网上前辈们的一些分享而成,涉及到目标相关性、流程完整性、整体美观性、易理解性、易操作性、技术可行性、分支与边界状态、情感趣味性、品牌调性传达、业务创新性、社会责任感等多个方面,具体大家可以参考我的这篇文章:交互设计方案衡量标准的五层总结。

uisdc-hy20161016

驱动协同模式的优化

一些交互设计师喜欢抱怨自己的岗位在上下游协同中效率低下、话语权低、可有可无等,然后产生转产品转视觉转前端等念头,我也承认和其他岗位相比,交互设计的话语权与不可替代性确实有一些先天劣势,但我不认为这就足以构成我们抱怨和转岗的理由,相比坐以待毙式的消极对待,我更倾向主动去争取和驱动交互设计师与上下游协作模式的优化,从项目组的角度是去提高协作效率与产品最终体验,从交互设计师个人的角度则是去争取更大的思考发挥空间与话语权。

在和上游(产品经理、业务方)的协同模式改进中,我争取的是更早的项目介入时机与全流程的跟进参与,从传统的Prd评审完成(这个时候PD基本都梳理得差不多了,在时间有限的情况下设计师很多时候就只能做细节优化补全了)再介入,到亲身参与和用户的接触访谈、从用户反馈中获取最原始、第一手的需求,然后和用研、PD共同完成一系列的场景梳理和需求分析工作,PD的输出物从传统的Prd转变成聚焦在内容底层逻辑梳理的新Prd,设计师对界面布局有充分的思考发挥空间。不过需要指出的是,这样做容易造成时间周期拖长,不是对每种项目都适用,比如一些强业务需求、上线时间紧急的的项目,还是传统的合作方式效率更高。

在和下游(视觉设计、前端开发)的协同模式改进中,我争取的是重复性工作(对设计专业提升意义不大, 还对设计思考的时间造成挤压)的减少,主要是设计规范的沉淀(这类分享网上有很多,就不赘述了)、以及和视觉更交叉性的合作方式(不是所有项目都要过一遍交互再过一遍视觉,可以视对交互/视觉的要求程度由其中一个人全包,规范的沉淀也能促进这一进程)。

我羡慕过友部门的大型设计团队有自己专业成熟的设计流程和设计规范沉淀,新人也能很快上手,但当在没有这些的情况下,自己亲手去按自己的想法把流程优化和规范沉淀这些事情做起来,而不是当一个只会用别人的流程别人的规范的螺丝钉(以前实习时跟过有成熟设计规范的项目,对比下来那段时间的成长速度也是相对最慢的)后,成就感其实要强烈很多。

uisdc-hy20161016-2

提升软技能

(编辑:PHP编程网 - 黄冈站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读