开发者 | 那些令人“奔溃”的 UI 验收

前言

去年年底我们公司进行了项目主路径的改版，整体的进展比较顺利，但是还是暴露了产研侧存在的一些问题，其中就包括令人“奔溃”的UI验收环节。
这篇文章将以UI验收为出发点，尽可能客观地复盘整个改版过程。

1、吐槽大会 —— 问题是什么？

首先整理出遇到的几个主要的问题：

这些问题不是一种角色的问题，单独站在其中一个角色的角度去看待，或者单独归因到其中某个角色上，都是不全面的。必须把视角拔高，从更高的层次去看待整体，才能更好地理解这个问题。

2、设计稿审核不全面

2.1 描述

设计稿审核是一个需要考虑很多因素的环节，正如软件质量保证从来都不是测试同学一方的责任一样，设计稿的审核也从来不只是设计同学一方的责任，而是整个产研团队的责任：

从产品侧，既有考虑正常 / 异常流程完整性，也有整体美观性和品牌调性传达；
从设计侧，既有信息架构与流程合理性，也有UI细节标注到位；
从研发侧，既有设备 / 多平台适配，也有技术实现预判。

如果前期未（尽可能）全面地审核设计稿，将存在以下问题，最终在验收时出现各种各样的问题：

设计稿内容缺失
边界情况 / 异常流程未确认
技术同学对设计图的理解不够 / 不统一
开发中 / 上线后暴露问题，造成延期 / 效果打折

2.2 解决方案

随着团队的成长，工作流程应该朝着流水化、可复制、工具化的方向演进，形成一套方法论。对于设计稿审核，可以是用建立UI审核表，在设计稿交付前，设计同学先自查一遍，在研发开始之前，产品同学和研发同学根据自己的侧重点再二次审核，例如：

参考自海盐社@阿肆Stella

2.3 推荐文献

3、通用样式未形成规范

3.1 描述

每一张设计稿都不是独立存在的（除了一些活动页 / 个性化页，确实可以独立设计），如果没有将一些通用的样式进行组件化整理，存在以下问题：

增加重复研发成本，研发工作量增大
增加新样式验收成本，验收工作量增大
有的模块使用旧样式，有的模块使用新样式，整体体验不一致
重复的样式一定程度上增大了应用包体积

3.2 解决方案

随着业务功能的叠加，项目中肯定会存在一些通用的，可以复用的样式，主要可以划分三个纬度：

通用的颜色与尺寸
例如：主颜色、价格文本颜色、列表多级文本颜色、分割线宽度、界面边距
通用的组件
例如：圆角按钮、标签、对话框、Toast、抽屉菜单。通常，需要从颜色和尺寸两个角度定一个组件。
通用的交互
例如：下拉加载、上拉更多、顶部折叠交互效果

将通用样式组件化整理并形成规范的过程，需要设计和开发协同进行，在初期会加大工作量，但是从长远看，消耗这部分工作成本是值得的。

例如：建立通用调色板与通用元素颜色，避免色彩滥用：

    <!-- - - - - - - - - - - - - - - - 调色板 - - - - - - - - - - - - - - - -->

    <color name="white">#FFFFFFFF</color>
    <color name="greenLight">#FFD5E8D4</color>
    <color name="orangeLight">#FFFFB366</color>
    <color name="redLight">#FFFF6666</color>
    <color name="gray1">#FF333333</color>
    <color name="gray2">#FF666666</color>
    <color name="gray3">#FF999999</color>
    以下省略...
    <!-- - - - - - - - - - - - - - - - 主题 - - - - - - - - - - - - - - - -->

    <!-- 主色调 -->
    <color name="colorAccent">@color/greenLight</color>
    <!-- 列表的三级颜色 -->
    <color name="colorOnPrimary">@color/gray1</color>
    <color name="colorSecondary">@color/gray2</color>
    <color name="colorSecondaryVariant">@color/gray3</color>
    <!-- 表示金钱有关的颜色 -->
    <color name="colorPrice">@color/orangeLight</color>
    <!-- 表示热卖的颜色 -->
    <color name="colorHot">@color/redLight</color>
    以下省略...

例如：定义标签（Tag）组件样式：

两个角度：颜色与尺寸
两个层次：基准标准与产品标准

标签是进行标记和分类的小标签，是常见的信息元素。定义一个标签，需要考虑文本、填充、内边距、边线与圆角几个纬度，先定义基准标准，例如：

基准标准	文本	填充	内边距	边线	圆角
全填充标签	10px、白色	3px	`主颜色`	_	4px
透明填充标签	10px、`主颜色`	3px	`主颜色`+20%透明度	`主颜色`+40%透明度	4px

全填充标签

透明填充标签

在基准标准的基础上，再根据标签具体使用场景、业务、上下文等特异性需求，基准标准与特异性需求组合，就是完整的产品标准啦，例如：

场景	文本	填充	内边距	边线	圆角
小标签	_	3px	_	_	_
大标签	_	5px	_	_	_
圆角标签	_	_	_	_	4px
椭圆标签	_	_	_	_	100px

3.3 推荐研发资源

4、验收过程反复、低效

4.1 描述

在笔者经验里，如果不需要二次UI验收，真的是值得开香槟庆祝的时刻呢！有很多原因导致了往往不能在一次返工后解决全部错误。

4.2 问题与办法

口头说明
口头说明很容易出现遗漏，比如设计同学指出了10个，但是开发同学只改了6个。而且当设计需要对接多个开发时，很难将问题指向到对应的开发人员，造成重复沟通和重复返工。时间允许的情况下，尽可能使用文档 / 截图的形式。

口头说明容易遗漏
“参见设计稿”
有些设计同学喜欢指出一个位置，然后标注“参见设计稿”，相当于指出了有问题，但是没有指出是什么问题，有可能出现一轮验收后还是有问题的情况。开发没办法像设计师一样，对每一个像素 / 颜色能一眼看出问题，相比与“参见设计稿”，具体标注“增大多少px，改为什么颜色”是更高效的做法，慎用“参见设计稿”。

慎用“参见设计稿”

一轮验收后还是有问题

UI 验收问题没有开发修改
这个属于开发同学的失误了，因为通常界面是多名同学协作完成的，所有有些UI验收问题就不能直接指向到某一名开发身上。为了避免出现遗漏，收到UI验收问题时，开发同学应该提前就做好分工，做到事事有着落。

4.3 推荐文献

《让人"崩溃"的设计验收》 —— Wendy_小火焰
《如何高效的进行设计验收？》 —— 橙子的橙子

5、沟通乏力，同学间有脾气

5.1 描述

每个人都希望自己的合作伙伴是一个经验丰富、热心团结、既开得起玩笑又扛得起通宵的完美伙伴，但现实中一个人不可能在每个方面 / 每个时候都做到尽如人意。

5.2 团队建设

如果一个团队能做到边界清晰、职责明确，那么就不会有那么多委屈或者冲突吧。就好像下棋一样，黑先白后，轮流落子，你一步我一步，没有任何争议。

5.3 自我调整

我们无法左右他人的行为，感觉沟通有困难，希望一些小经验能帮到你：

尽早抛出问题，不要等到验收时发现问题，返工时间太紧
根据问题大小，大问题在大群里指出，细节问题私聊解决
口头问题 / 需求改动在大群确认
如果确定是对方的问题但不配合的，可以考虑上升推动。通常来说，领导是乐于帮下属解决问题的，因为上线后如果出问题，领导也有一定责任的。

6、写在最后

经常看到身边同学对一些问题“妥协了”，其中部分原因是赶工的无奈吧。有这样一个问题，我们遇到的问题是错误和失败呢？看到一个答案是：我们遇到的是错误还是失败，完全取决于我们的自我选择。遇到问题的下一个选择是新决策的产出，新的决策能够尽量减弱过去问题的影响，那么这个问题就只是错误；如果遇到问题的下一个选择是妥协，那么离失败就不远了。

参考资源

《设计与质量》
Material Design 官网
站酷（一个设计师社区）
微信公众号：海盐社（haiyans7）（一个设计师社区）

开发者 | 那些令人“奔溃”的 UI 验收

开发者 | 那些令人“奔溃”的 UI 验收

前言

1、吐槽大会 —— 问题是什么？

2、设计稿审核不全面

2.1 描述

2.2 解决方案

2.3 推荐文献

3、通用样式未形成规范

3.1 描述

3.2 解决方案

3.3 推荐研发资源

4、验收过程反复、低效

4.1 描述

4.2 问题与办法

4.3 推荐文献

5、沟通乏力，同学间有脾气

5.1 描述

5.2 团队建设

5.3 自我调整

6、写在最后

参考资源

推荐阅读

2020 永远不要放弃希望，祝愿大家都能够平安健康！武汉加油！

推荐阅读更多精彩内容