开发者 | 那些令人“奔溃”的 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 推荐文献


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

5.1 描述

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

5.2 团队建设

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

5.3 自我调整

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

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

6、写在最后

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


参考资源


推荐阅读


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

推荐阅读更多精彩内容