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

2020-01-31 本文已影响0人彭旭锐

前言

去年年底我们公司进行了项目主路径的改版，整体的进展比较顺利，但是还是暴露了产研侧存在的一些问题，其中就包括令人“奔溃”的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）（一个设计师社区）