BACK >
app之ued的设计评审指南
作者:吾诺瀚卓    浏览次数:293    日期:2017-06-23

每一个APP研发出来都是客户因为知道了用户的需求所以就会特别了解在研发中自己需要重视的那一个板块,而我们的吾诺瀚卓做网络开发的就必须知道和客户积极地沟通是重点,只要完全的了解了客户的心思才会想办法去解决问题,而今天的这篇是经常参与设计评审,会观察到设计师在评审中常发生的问题,这些问题可能会导致评审人对设计稿产生另外的解读。

APP之UED的设计评审指南

进行一场有效的设计评审

设计师参加评审会的目的是「和评审者达成一致」,如果换位思考一下,作为评审者是怎么和你达成一致的?一份不加说明的设计稿投到屏幕上,短短几分钟内能否让评审者对设计稿有足够多的理解?感受到你可能花费好多天打磨出来的细节?如果想避免这类问题,可以在评审前先准备这四件事:

第一件事:找产品经理预沟通

产品经理产出设计需求,设计师在这基础上进行设计任务,所以不管有无评审会,产品经理是都会负责这个需求到底的人,也会是对设计稿最关注的人之一,在评审会之前和产品经理预沟通设计稿可以先让你和产品经理达成一致,会让评审会高效,同时其他参与评审的同事有问题时,还可以让产品经理来一起解答。

第二件事:编排评审顺序和整理设计思路

「编排评审顺序」相当于把评审节奏控制在你的手中,一切根据你制定的顺序进行,一般情况下,可以这样编排:

讲解「设计思路」,让大家先和你的思路对接起来,避免直接看到设计稿时每个人都从自己的角度出发。

展示「核心页面的设计稿」,因为评审人数众多,如果设计稿状态很多,涉及到设计稿比较多,可以先把「核心页面」贴出来,让大家理解后没有问题,再把余下状态作为补充展示出来,不要一上来就一股脑儿的全部一张张展示出来,评审者有很大的可能性并不知道你在说哪个状态,而让你失去控制和节奏。

「设计思路」在评审过程中会起到决定性的作用,有一个好思路可以给你的设计稿加分不少,因为评审者他理解你的设计思路后自然也能快速理解你的设计。「提高用户体验好」「看起来美观」「这样逼格高」这些并不是设计思路,也不能让大家和你达成一致,如果没有客观内容(数据,案例,理论等),凭什么说你认为的体验是最佳方案呢?设计思路是感性结合理性的,需要把设计过程中头脑中的各种点子(怎么去理解需求的,思考选择那个合适的设计方案,设计时发现的坑和限制,灵光一线的设计想法)总结出来,在评审时针对性的说出来。

第三件事:预先考虑评审者可能提出的问题

如果能预先知道评审者会问什么问题?是不是就有时间准备好然后胸有成竹的去评审了?我整理了一些评审者可能会提出的问题,评审之前,大家可以对照这些问题自问自答一番,看下哪里还可以再调整下:

最后为什么考虑使用这个设计方案?

这个需求要解决什么问题?能不能一句话说清楚

之前已有的功能的数据是什么样的?

我们的竞争对手是怎么做?有没有同类型的设计?

这个新设计和我们之前设计不一样,是怎么考虑的?能不能沿用之前的控件?

这些元素没有对齐?是故意的还是粗心?

设计稿上面的内容是接近于真实的内容吗?如果不是可以改成真实的看效果

为什么使用这些颜色,在平台规范中没有出现过?

第四件事:整理待评审资料

有了思路和编排,也尝试了自问自答,还可以准备一些能够作为你背书的资料,能够帮助你在评审时,作为资料背书给大家展示,也可以供你快速查阅信息,方便回答问题,以下是清单:

产品PRD:当有疑问时可以拿出来给评审者查看

设计分析文档:用来沟通关于行业内对于同类型功能的设计优缺点的分析

 数据分析文档:用来展示当前版本数据上的表现和问题,以及可以帮助进行下一步改善

 功能逻辑图:复杂功能可以使用图形化表现功能逻辑,便于评审者理解

 用户路径图:通过用户路径讲解全局性问题,结合交互设计稿进行具体说明

 交互动效演示文档:用来解释一些比较复杂的交互过程

 配色情绪版:用来解释如何选择当前配色的思路

最后,希望能帮助大家顺利完成评审,如果大家有什么关于设计上的问题,也欢迎留言,会尽可能进行分享解答。