过程质量和结果质量应该更关心哪个?

过程质量和结果质量应该更关心哪个?

李奇李奇

我们在评价一个作品的质量时评价的是它的结果质量,即视觉、交互、信息结构等等是不是足够好、传递的品牌感是不是这个产品想传递的、有没有帮助产品达到目标等等,这也是最能给自己带来兴奋感的地方,因此每一位设计师都在为了达到最好的结果质量而努力。但事实是我们通常无法直接控制结果质量(尤其在一个团队里),只能通过良好的设计过程以及一些基本共识来得到好的设计质量。

过程质量是什么?

在不同的角色下提到的「过程质量」都是不一样的。如下图:对于设计师 A 而言,过程质量指设计从开始到产出的质量,更多指的是设计过程质量;对于一个团队而言,过程质量是指如何让一堆设计师通过一个好的流程来更好的协作,更多指的是协作过程质量。

设计过程质量(个人)

对于单个设计师来说,高质量的设计过程可以带来很多好处:提升个人设计效率、获取更多信任等。对于设计过程质量,我比较关心的有下面几点:

沟通质量
对于设计师而言,沟通是一件无比重要的事情。从某个层面来看,设计师其实是一个把问题解决方案通过原型、文档翻译给工程师;通过界面、交互翻译给用户的角色(虽然这个角色在很多公司由产品经理承担),但「翻译」的过程中,为了保证所有的信息传递不失真,这需要设计师有着很强的沟通技巧:准确传递自己的设计意图、发生分歧时据理力争、与用户沟通的过程中理解他们真正想要的等等。

决策过程质量
经得住推敲的设计决策会给人安全感,这也是表现专业度和建立信任非常重要的方式之一。如果这是一个产品设计方案:这个方案是怎么得到的?这个方案相比那个方案好在哪?如果继续迭代还应该改哪里?如果这是一个平台设计方案:这个组件的扩展性是否足够好?能否满足当前所有的业务需求?不同平台的特性是否一致?这些决策过程在侧面反应了设计过程中设计师是怎么思考问题以及思考过程是否足够全面。

实现过程质量
这会落地到具体的设计实现上,重点是所有的落地方案是否严丝合缝的解决了所有问题,是否存在一些并不是设计意图但因为某些原因引入的其他东西?有没有别的方案可以满足这个需求。这里可以举个例子:在做某个 Button 时的 Disable 状态时会采用降低 Button 透明度的方式来得到更浅的效果,好处是可以非常直观的得到一个更浅的按钮并对其他按钮的选色给出参考,这个方案的问题是设计意图中并没有改变 Alpha 值的想法,但在实际操作中却引入了 Alpha 值。于是我们一起讨论了这个问题看看是否有其他的解决方案,比如能否采用 HSB 而不是 RGB 来实现这个需求,这样就可以不用引入 Alpha 值来解决这个问题(因为我们会希望前端的实现逻辑和设计意图一致,如果我们在设计阶段引入了 Alpha 值,那最终的 CSS 应该用到的就是 rgba(0,0,0,.2);,而不是 #000。至于我们为什么希望这么做可以日后写一篇文章来解释~)。这应该算是实现过程质量的一部分体现,即你的设计意图和最终落地方案是一致的,而不是出现一些不可控或预期之外的因素。

这三点是我觉得设计师个人可以控制质量的最重要的三个过程,当然除了上面这 3 点还有一些其他也很重要的过程,比如设计稿的交付、工程实现的跟进等等。

协作过程质量(团队)

一个团队只有一两名设计师时,个人质量就是团队质量,几乎不用考虑太多协作上的问题,但当团队成员越来越多,不可避免的会出现团队成员能力不一的情况,一般情况下没有办法直接控制产出质量(除非自己上手),能做的只是控制每一个环节的质量。当团队作业的时候每个人会得到自己的分工,在不同的分工下,我觉得比较重要的是下面几点:

共用组件管理质量
当设计团队需要维护一个功能、交互形态较多的复杂产品时,我们会慢慢发现一个问题:产品设计迭代往往会占用设计师更多的事情,而平台设计迭代会变慢,这时在原本的产品设计师中就会慢慢产生一个新的角色:平台设计师。这个角色需要思考的问题是:如何让产品设计迭代更加高效?有一个做法是将设计组件化,比如我们将 Dialog 拆分出来当做一个独立组件交给 A 负责,那 A 需要做的事情是定义 Dialog 的风格、不同组件在 Dialog 中的表现形式、不同设备的适配策略、不同业务的兼容性、支持的交互形式、呈现的内容结构等等,然后将这些内容规范化,其他产品设计师基于该规范设计。日后 A 就是该组件的负责人,他需要不断的迭代以便支持更多不同的业务类型。如果遇到组件本身无法满足的需求,该组件负责人需要做出迭代或采取折中方案来实现。这样可以使得一个组件有明确的负责人,同时保证平台设计在不断迭代。与之类似的还有 icon、Animation、Menu、Button 等各个组件,都可以采用这类方式进行管理和维护。

Design Review 质量
应该很多团队都会有 Design Review,好的设计反馈能帮助设计者更好的完善设计(关于设计反馈本身我之前写过一篇文章提到过),但 review 的执行质量很大程度上依赖主持人的控制,同时在团队越来越大的情况下,如何设计一个好的 review 流程是一个团队必经的过程。当我们提到 design review 的时候总会想到等到有完整的设计稿时再拿出来给大家看,但其实 review 可以在非常早期就开始进行,其实严格意义上来说这已经不算是「review」了,算是「联合设计」。因为当团队越来越大,通过反馈来收集意见效率非常低下,尤其是参与人数众多的 review,要么有一些人永远不说话,要么偏题一万公里,所以早期小规模人员参与的「联合设计」对改善设计质量的帮助会非常大,同时让其他设计师能够深度参与进另一个项目中,彻底了解设计背景和遇到的困难,这样也能够更大程度上帮助大家改善交流质量。

设计沉淀质量
我们会希望每一次迭代都是在前人的经验上进行,这样才会让整个团队有传承感(之前也有过文章说过这个事),每当有新人加入,他可以很快明白我们当时为什么做这个改动、改成了什么样、数据和用户反馈如何、解决和遗留了哪些问题等等。如果这些内容都在团队成员脑袋里没有落地成文字,那每当有人离职时,这些经验都会随着人员更迭而流失,就会很有可能出现一些之前是 A,后来被改成 B,再后来又被改成 A 这样的情况,设计的迭代效率变成了以设计师在职时间为坐标系,而不是团队和产品成立时间为坐标系,这对设计质量的提升不利(下图是知乎设计团队的一些设计记录)。

合作质量
设计师会和工程、产品等各个层面的伙伴合作一同完成设计的最终上线,在合作过程中一定会出现各种问题,比如需求频繁变更、产品层面没有思考全面却着急推动设计产出、工程认为实现设计成本过高不想实现等等,那采用什么样的流程来改善与各个角色合作就是一个需要花时间思考的问题。建立规范合理的需求提交模板(背景、问题、目标、数据、预期),项目上线后的及时复盘(记录合作中遇到的问题),最终的数据分析结果同步,当然还有最重要的 TB!

上面提到的这 4 点都会在各个层面影响到团队效率和质量,当然和个人一样,除此之外还有设计稿的版本控制流程、设计和工程的工作流优化等等。

设计过程的优化是为问题找到长期最优解,一般不会被短期目标所影响,设计过程相比业务本身的迭代速度会慢一些。随着团队越来越大,业务越来越复杂,为了达到更好的结果质量,过程质量的重要性也会慢慢显露出来,过去我们可能对结果和过程的关心比例不够对等,不论是设计师自己还是团队 leader 可能会需要慢慢调整自己对设计过程质量的关心程度。所以文章标题是个标题党啦啦啦~~

最后知乎设计团队在招人哟,实习全职均可!有兴趣的老师请快联系我!

当然我们超酷的前端团队也在招人,如果你是一个强而有力的前端工程师请火速发简历给我呀!今天投简历明天就上班儿!

「手留余香一下吧~」
还没有人赞赏,快来当第一个赞赏的人吧!
文章被以下专栏收录
8 条评论
推荐阅读