设计的生产力

设计的生产力

李奇李奇

当一个产品的设计团队从早先的 1 到 2 个人的小作坊扩大到 10 到 20 个人的团队,产品线越来越多,需求越来越多,工作方式就会发生很大的变化,要考虑的事情也会越来越多。从不管复用不管协作,先把东西搞出来上线到关心设计稿如何管理,通过什么样的方式协作和传递设计意图,如何减少人多之后带来的设计效率降低和到最终落地的损耗,这些都是随着团队规模变大带来需要考虑的问题。在产品开发流程中,大部分人们只会关注开发成本有多大,开发效率有多高,很少有人关心设计成本有多大,设计效率有多高;我们总能听到开发小伙伴说「这套系统已经没法维护了」,但很少听到「这套设计系统已经没法维护了」,是设计师真的不会遇到这个问题么?我们真的不存在效率和成本问题么?

设计工具为谁设计?

从过去的 Photoshop 到现在的 Sketch,我们的设计从过去一个人撸一个全套设计到现在的团队协作产出设计,过去单兵作战的日子已经不复存在了,但一些重要的协作功能却很少在设计工具中被提上日程,设计师之间的设计稿和公共资源的使用上,也还只是在源文件管理和交换的级别上。当然这在小规模的设计团队中是没有问题的,但当团队变大,需要协作的部分越来越多,原始的协作方式效率会开始低下,大量不同版本和功能的设计稿也开始混乱。这个时候我们会基于现有的工具约定一些规则,比如文件命名、不同版本的设计稿如何存放、源文件的目录应该是什么样的等等。

做过效率工具的设计师一定知道,设计效率工具其实就是在设计工作方式,如何把你对这个问题的理解表现为工具,通过这个工具把你的思路传递给更多人。我们常用的设计工具也不例外。设计师应该如何工作、设计稿最终应该是什么样等等这些思路都会融入工具本身。也正因为有这样的问题,工具背后的团队所有的经验和试图解决的问题也变成了一个工具设计思路的前提:面向个人设计师还是面向设计团队?提高个人效率还是提高团队效率?甚至是面向个人收费还是面向团队收费?这样的选择会完全改变一个工具的设计意图和所需的功能。就目前面向个人设计师,Sketch 是目前业界做的最好的工具了,也正是因为这样,他在团队协作方面并没有更多的投入,只能依赖各种第三方开发者来扩展。而反观 Figma 则是提供了另一种思路:基于设计团队的角度出发设计工具,在团队协作中非常重要的 feature 它都有原生提供:版本控制、多用户在线预览/协作/评论、组件库共享、基于 Team 收费等。相比 Sketch,他们更有动力为团队协作做更多事情,因为团队是他们的根基。更重要的是一旦整个团队都进入了这个平台,就很难再迁移出去了,商业化上也会比较有潜力。建议小团队或者正在做新产品各位可以尝试一下 Figma,相信它一定会给你们带来不一样的感觉。有空了可以单独聊聊 Figma,这个工具真的是很有趣~

面向团队的设计工具真的可以达到面向个人设计师那样的规模么?至少从过去来看,主要的设计工具并没有出现面向团队方向的产品,我们的设计流程基本上都是通过已有的工具组合而成,在这个过程中也诞生了比如 Zeplin、Craft 这样的第三方工具。一个专为团队协作优化的产品未来是否会出现更多我还是持比较乐观的态度的,尤其是现在各个设计团队都开始更加重视协作、沉淀的今天。我们有了这么多的设计工具,但这也还只是设计流程中的一部分,把设计转化为落地的产品时,还有一个巨大的鸿沟需要跨越。

设计意图与工程实现间的损耗怎么弥补?

相信很多设计师都会遇到这样的问题:为什么最终的实现和我想要的效果不一样?为什么我只想改这里但最后另外一个地方也被改了?为什么不是改一下所有地方都生效?为什么改这么一个简单的东西要搞这么久……这一堆疑问的背后其实是设计和开发的沟通不在一个频道上:在设计心中这些地方应该是一致的,但在开发那里这并没有抽象成同一个东西;在设计心中一个很简单的改动,实际上需要改动某一个基础组件,这个基础组件还会影响到其他的复合组件等等。这一切都是因为设计和开发对功能和需要改动的部分理解不一致的问题,这也是带来沟通成本和最终效果和设计预期不符的地方。

为了减小这个沟通损耗,保证设计质量,我们在产出设计后,通常会再产出一份设计规范,统一所有的设计和开发实现。从我的观察中,这件事在不同的团队会做到下面的几个程度:

  1. 输出一份保持维护的 Guideline
  2. 输出一份保持维护的 Guideline 并跟进开发实现设计意图
  3. 输出一份保持维护的 Guideline 并跟进开发实现设计意图,推动开发建设前端组件库并完善开发文档
  4. 输出一份保持维护的 Guideline 并跟进开发实现设计意图,推动开发建设前端组件库并完善开发文档,关注 Guideline 在设计团队中的使用状况并保持优化使用体验
  5. 设计师、工程师协作产出设计系统,推动设计系统在公司内各业务线的落地,不断提升设计系统在各使用方的使用体验(设计、开发、产品)

《为工作流优化组件库应用》《设计的组件化》提到过很多关于 Guideline 和组件化的问题,大部分设计团队能做到第 2 步,但设计系统起码得做到第 3 步才可以算得上是在试图弥补设计意图和工程实现的损耗,再往后能做到什么程度得看设计团队本身在这家公司的定位是什么了。

设计团队的定位

当公司处于不同阶段是,对设计团队的需求也会有变化,简单的例子:

  • 产品 MVP 阶段通过直观易懂的设计验证产品需求是否成立。这个阶段可以理解为糙快猛的上线,使用更加直接强势的设计验证需求是否成立。
  • 产品快速迭代阶段通过更易扩展的设计方式推动产品功能尽快落地。这个阶段的重点是「快速迭代」,所有的设计都要为速度和扩展性让位。
  • 产品稳定阶段与工程团队协作,推动统一、有品质的设计流程和设计方案。这个阶段产品基本稳定,进入正常的迭代阶段,团队人数也会有所提升,需要关注设计品质。
  • 产品线扩张阶段定义品牌元素,并推动各业务线的落地。这个阶段需要将公司品牌融入各个业务线,从而带来相应的整体感。
  • ……

在不同的阶段职责会有不同,不同的职责便会产生相应的角色,比如到了产品稳定阶段,可能就会需要前端/客户端工程师的加入帮助我们提升效率;产品线扩张阶段,可能就会需要文案、品牌设计师的加入完善品牌建设等等。好的设计团队的定位应该会随着公司和团队的变化而变化,承担的职责也会有所不同,但不论怎么变,设计团队都应该作为一个推动者的角色在工作,而不是被推动者。我们的目标不是「提供良好体验的设计」,而是「提供良好体验的设计并推动落地」。当团队定位变化为「推动者」时,需要考虑的事情相比之前就会多很多,比如上面提到的设计和开发沟通损耗怎么解决?设计工具对团队协作不友好怎么办?设计系统在各个业务线的落地不够顺畅怎么办?先来看看其他团队是怎么解决这个问题的。

Airbnb 在这个方面的做法非常有趣,首先 Airbnb 的设计团队一共由四个部分组成,分别是 Experience, Production, Insights 和 Content Strategy。其中 Experience Designer 负责 Airbnb 产品的设计,而 Production Designer 的职责则是为 Experience Designer 提供服务,这里的比例大约是 1:10。同时 Production Design 也是另外一个更大的组:DesignOps 的一部分。说到这个组就厉害了,这个组里包含了 Design Program Management、Design Tools、Localization、Production Design 和 Team Coordinators 5 个角色。他们的愿景是「Provide agility to the whole product organization through centralized tools, systems and services that enhance speed and quality of execution」,近期非常火的 React Sketch.app 就是这个组的作品,这个产品的作者 Jon Gold 也拥有一个超酷的 title:Design Technologist。Design ops 中的 Design tools 团队更是说到「From solving day-to-day problems all the way up to re-imagining Design tooling 5 years out, our mission is to build tools and systems that empower all Design disciplines to move quicker and design smarter.」

来自瑞典的 Spotify 和 Airbnb 的做法类似,他们在 2014 重新整理了自己的设计语言,并且也发现了这套东西是需要不断迭代和更新的,于是在 2015 年成立了一支叫做 GLUE 的团队(全称 a Global Language for a Unified Experience),他们的愿景则是「GLUE can support our distributed designers by facilitating collaboration across teams and providing frameworks to evolve the different design needs in the company.」他们每周会和产品设计师碰面,聊一聊最近的工作会对他们的效率产生什么影响、设计语言是否有更新,如何同步等等。


从上面的两个例子可以看得出,基本上他们的做法是为设计团队成立一个 Infrastructure Team,里面除了设计师之外还有产品经理、工程师等角色,目标就是让产品设计师的工作更具效率,提升设计质量,让他们把时间放在更重要的创新、产品细节打磨和效果追踪上,至于工具不好用、公共文件管理等等和产品无关的事情,全部交给这个团队来处理。这样的团队在过去只在工程中见过,这是设计从没有过的待遇,但随着公司的发展和对设计团队定位的改变,很多团队也开始逐步建设这样的跨职能、为设计师服务的小团队。这样的团队带来的另一个好处则是可以为设计社区贡献很多有用的东西,比如 Aribnb 的 React -> sketch.app。

希望国内的设计团队也可以有一些这样的尝试,看看是否有可能走出一条适合自己的路,毕竟大家的目标都是一样的:让设计团队更有效率的工作。

————————————

最近搞了一个小密圈,会在里面分享一些有趣的设计观点和设计类文章,没事聊一聊业界动态什么的,仅需 66,买不了吃亏也买不了上当,马上点击吧!

t.xiaomiquan.com/E6ubEU
「挺辛苦的」
3 人赞赏
李新寒
万锐
赵鹏杰
文章被以下专栏收录
7 条评论
推荐阅读