让互联网更好的为企业服务

       全国热线:400-800-4964

       合  作  伙  伴

首页 >> 行业资讯 >>行业动态 >> 面对让人“崩溃”的设计验收,我们要如何解决?
详细内容

面对让人“崩溃”的设计验收,我们要如何解决?

时间:2020-11-07        阅读

我们公司前段时间进行了3.0项目的开发,本次项目的进展整体上还是比较顺利的,但是还是遇到了很多小插曲,其中最让人崩溃的就是验收环节,简直就是跟技术的一场拉锯战。当然这场战争的始作俑者并不是某一方,而是每个角色身上都有各种各样的问题。今天就想来客观的陈述一下整个过程,希望在下次进行项目推进的时候可以有所改进。

目录:

  1. 我们遇到的问题及解决方案;

  2. 提升技术更改Bug的要点;

  3. 那些容易出错的地方。

一、我们遇到的问题及解决方案

前提:之前我们公司对设计还原度要求很低,且技术有较高的话语权,他们就觉得UI界面不重要,所以之前我们是没有设计验收环节的,界面的问题提上去也是石沉大海,我们每次进行设计验收都很沮丧,也不会特别抠细节。

但是最近公司高管有了很大的变动,新来的CEO、CTO和产品总监都对设计要求特别高,当然也就特别看重线上效果,所以就有了这次正式的设计验收环节。

首先,我想总结一下我们在这次验收中遇到的几个主要问题:

1. 技术同学对设计稿的理解度不够

首先检讨一下设计同学的问题,为了图自己省事,直接用Sketch Measure 导出标注文件给到技术了,对于有适配需要的地方也没有进行单独的标记和说明。所以技术同学就会按照自己对页面的理解进行布局,到验收的时候设计同学才发现不是自己想要的结果,这个时候要改动的话就会比较困难。因为一开始的框架就不对,技术也没有时间重新写一遍,所以就会有很多问题被搁置。

直接导出的标注对界面的准确性要求也特别高,你必须保证所有的界面都准确无误,不然就会遇到开发者提出的来自灵魂的质问:“为什么这里是15px,那里是16px,两边不一样,究竟让我们怎么写?”

听到这句话是不是有点不服,但是就是你错了呀。所以时间允许时还是要手动标注,不但可以减少这种质疑,在标注的时候还会对页面的细节进行盘查,会发现一些遗漏的状态和缺失的细节,这样下来最终提交给技术的设计稿会更加完善。

再者,缺少设计稿评审的环节,这个环节主要给技术讲述一些适配要求、交互状态及动效(我们公司近期撤了交互岗位,所以交互的相关工作需要设计同学进行考虑);同时解答技术同学的一些疑问,这样就能将一些可预见的问题解决掉,解决后期的沟通成本。

解决方案:

  1. 时间允许,尽量进行手动标注/时间紧张需要适配的地方单独标记;

  2. 技术开发前进行设计稿评审。

2. 设计稿的缺失

这个首先当然是设计师的失责,因为我们提交给技术的设计稿的第一要素就是完整度,到开发进入尾声才发现缺失,那技术同学只有说“对不起,排期吧”。然后设计同学还一肚子委屈,觉得开发不配合。

下面是设计稿中常见的缺失内容:

  1. 页面极限状态:无内容、无网络、加载中;

  2. 页面交互状态:上滑导航栏固定的样式、社交操作的交互状态、下拉刷新样式、按压状态等;

  3. 页面适配:文字的极限情况、屏幕横向竖向的适配、X和Android等各种极限机型的适配。

这些都应该是在出设计稿的时候就考虑清楚的问题,因为技术是根据你的设计稿进行技术排期的,如果你的页面不完整,后期再增补导致项目延期,这个责任在谁呢?

3. 技术同学的“不配合”

这里的不配合不是说技术同学偷懒不想干活,原因是多方面的:

  1. 设计审核时间太靠后,结果就是在我们提交UI问题的时候,产品也在提交功能型的bug,那技术同学同时拿到这两个问题,按照问题的优先级来说肯定是先改功能性问题,然后你的问题就被搁置了。

  2. 技术没有完美还原设计稿的意识,还是觉得这件事情没有那么重要,所以觉得设计师抠像素就是跟他们过不去一样,其实我们也很无奈,因为设计稿就是一个像素一个像素抠起来的呀。

  3. 设计的时候没有考虑开发的可实现性和实现成本,所以就觉得开发应该完全按照自己的设计稿做出来,做不出来就是不配合,设计师尤其爱说“你看XX大厂能写出来,你咋就写不出来呢”,这是极其自大且没有情商的一种表现。首先大厂的技术团队实力理论上是比小公司要强;另外我们也要倾听技术同学的声音,他们也许是因为排期紧张而做不到呢,所以在批判别人之前要首先想想自己的问题,看到客观存在的问题,然后一起寻找更好的解决方案。

解决方案:

  1. 提前进行设计验收,最好是提前知道模块的开发者,这样后期一对一进行模块的打版验收效率更高;

  2. 设计时考虑开发成本和可实现性。

4. 设计验收不完整

之前没有完整验收的经验,所以我们基本上是看到哪里是哪里,没有一个系统的验收框架,这样就会导致在验收的时候会有缺失,然后会被其他同事发现还挺尴尬的,测试是由测试用例的。所以我们也应该输出一份设计审核清单,对照表格进行验收,才能避免遗漏。

5. 通用样式未进行组件化开发

从源头来说这个是我们自己的问题,因为没有将通用模块进行组件化整理。同时技术同学也没有这个意识(或者是组内配合度不够),因为我们本次项目是视觉升级,所以有些模块的开发者会根据设计稿新出,有些是直接调用之前的样式,这样导致的结果就是不同模块的弹层样式不一致的尴尬结果。

解决方案:

通用模块样式进行组件化整理,比如Toast、对话框、错误提示等。协助技术进行组件化开发。

提升技术更改bug效率的要点

1. 不要只是告知技术错哪里了,而是直接告知技术更改的方案

比如说图片尺寸错了,有些设计师就直接标注出来说这里出错了,请参考设计标注重新调整。另一个设计师不仅标注哪里错了,还直接标出这个图片尺寸是多大。很明显技术看第二个设计师给的验收文档更改的效率更高。

城市选择

甘肃: