同一套设计规范下,团队设计稿差异竟这么大
苏州/设计爱好者/1年前/5280浏览
版权
同一套设计规范下,团队设计稿差异竟这么大
此文章内容仅基于过往搭建设计规范一些经验,梳理了一些思路,一来可以作为我个人的经验笔记,收拢思路已经些许方法,以便日后随时可查看或有更深的沉淀,也期待能和更多的同行进行交流。(示例配图元素皆由我个人独立绘制)
引言
当我们为团队提供了同一份精心制定的设计规范,满心期待大家能遵循标准创作出整齐的设计稿,却惊觉成员们的成果仍有显著差异。这令人陷入深思。
我们得反思,是设计规范不够清晰,致使成员理解和执行有误?还是成员在应用时过于依赖个人判断和习惯,忽略了整体一致性?抑或是团队内部沟通协作有障碍,信息传递不畅,成员难以准确把握规范核心?
这种差异不仅可能影响项目进度与效率,还可能损害产品质量和品牌形象。它削弱了设计的统一性和专业性,导致用户体验不佳,感到困惑和不适。对此我每次在完成设计规范时,都在思考如何能吧设计规范做到最完美,让成员易学易理解,最大化提高设计规范的覆盖能力。
也许会有人提出质疑,认为过于强调一致性,反而会丧失灵活性,创新性。但是纵观市场上所有知名的品牌/产品都是基于一致性去塑造品牌认知基石头的,比如,苹果公司以其简洁、优雅且始终如一的设计风格,在消费者心中树立了独特且易于识别的品牌形象。
从用户体验角度来看:一致性位用户提供熟悉、可预测性,从团队协作而言,一致的设计规范可以减少沟通成本,避免重复造车轮子,提高工作效率,在项目管理中一致性有助于保障项目进度稳定,还能向外输出设计团队的专业度。
那么这里的差异指得是什么呢?比如同一场景,使用了两种或两种以上的设计方案,而有些方案甚至是脱离了设计规范的。然而,B 端场景颇为复杂,怎样才能使设计规范有效地传达到每一位设计成员,进而缩小设计产出物的差异呢?基于过往的经验,我梳理了几个症结,以及“治疗”处方。
一、内因症结与处方
1、团队成员的视角与理解程度
症结 - 团队视角不一样,导致对设计规范的理解程度不一样
为什么使用同一套设计规范,团队的设计稿依然会产生那么大差异?首先是因为规范的制定者与执行者的视角不一致,导致在实际应用时引发出各种各样的原因,最终导致设计稿产出存在差异。对于一套规范,制定者的视角是从内部到外部,从最内部的品牌调性再到规范的生产,制定者熟悉整个底层逻辑,可以在实际操作中灵活运用规范,而执行者的视角是从外部到内部,从最开始阅读理解规范落地逻辑,再到规范逻辑,每一步的触达都源于上一步,那么在这条链路中,执行者会因为个人理解,形成各色各样的偏差。比如遇到特殊场景,制定者能根据现有设计语言快速产出符合规范的设计方案,但是执行者可能很难做到这个程度,更多时候会产出与规范有一定差异的设计方案。
处方 - 在适当时机让团队成员加入共创
在很早期的时候,我在给项目做设计规范,都是独立完成后,再和设计组长一起评审,评审定稿后,才会对设计团队成员输出,宣讲。因为独立作业能把规范搭建周期缩短,能快速跟上产品迭代速度,但是后来就会发现,一个人的脑力是有限的,规范的设计会受限经验、偏好、思维广度等原因,导致在落地后,经常需要查缺补漏。而且由于大家视角不同,也很难把规范的逻辑和每个成员讲清楚,这就导致在规范落地的过程中,我需要花很多的精力去把控,收口。于是我想的黄蔚老师在服务设计这本书提到的共创理念,所以后来在迭代时或者是完成新项目设计规范的工作时,在设计阶段的评审到定稿让团队成员参与进来,集思广益,最大限度避免事后达补丁,同时降低了后期规范宣讲的难度,虽然整个设计周期会被拉长,但是从长期收益上看,是划算的,当团队成员的规范概念越来越清晰并形成共识,未来即使需要重新制定规范也能因熟能生巧,缩短工期。
2、设计规范的清晰度/完善度
症结 - 设计规范不清晰/不完整
如果设计规范使用指南不清晰或者是不完整,就会让团队成员在实际使用时产生迷思,可能有些设计成员会去跟建设者沟通,有的可能会因为需求周期,直接在现有规范里直接新造。下图是我很早以前支援的一个项目的文字色彩规范,原规范仅对部分文字场景做了规范,不够清晰还缺少部分场景的规范描述。
处方 - 基于设计规范框架,搭建设计规范文档
在制定规范前,先搜罗产品的现有场景并进行梳理,基于产品属性与品牌调性整理设计语言样式及逻辑,以及罗列出设计组件类目和每一个设计组件的特性及逻辑,我一致都是倾向于把交互规范和视觉规范合并的,这样可以大大节省各个团队的协作成本,在进入规范制定之前,先梳理出古范框架,有了框架的指引可以避免边做边想造成遗漏的弊端。
基于规范框架图输出具体文档,还是以早期我做的一个财务项目的文字规范为例,旧版规范在文字字体的规范描述中缺少清晰的定义和场景描述,导致在实际落地时,不同的设计师各自发挥想象和理解,产出很多差异化的设计稿,从而把整个产品的一致性打乱,后期我主导这个项目的重构设计时,在重新梳理规范时,在旧版基础上把类型定义、使用场景、遗漏类型补充上,并向团队成员调研,两种结构哪种更清晰易懂,当然结果就是所有成员都倾向我后面优化的结构。以文字字体和色彩语言为例,分别针对定义不清晰,使用场景描述缺少,规范不完整的问题做一个指引,可以让大家更清晰直观的了解。
3、设计团队成员的偏好与设计规范责任人、责任事项
症结 - 设计团队成员有自己的审美偏好
每位设计师都有独特的创意视角和审美倾向,就像每个人眼中的世界都有独特的色彩。对规范的解读和运用也因人而异。有人注重细节的精致,有人追求整体的和谐,这使得设计稿在细微处或整体氛围上呈现出差别。比如同样标题+标签的场景,不同的成员因对业务理解不同,以及审美偏好导致产出的设计方案存在差异,这在过往的工作项目中也是经常遇到的场景。
处方 - 明确设计规范责任人以及责任事项,把控设计规范落地边界
明确规范负责人以及责任是保障工作顺利推进的重要环节。只有清晰地确定谁来主导规范的制定、执行和监督,以及明确其所承担的具体责任,才能避免职责不清导致的混乱和延误。这要求我们综合考虑相关人员的专业能力、经验和责任心,做出合理的安排,以确保规范得以有效落实,达到预期的目标。
作为规范的制定者,需要全流程跟进规范,并非制定完规范便宣告结束。唯有全流程跟进,才能更好地保障规范落地。
以我曾经主理设计规范时所遇场景为例。在 2021 年所做的一个金融项目中,当时有设计成员遭遇了一个特殊场景,然而当时的规范无法完全支撑该场景。成员向我反馈之后,我让其先依照设计语言设计一个新的业务组件样式,接着我们向领导汇报了这个事项并展开内部评审。评审通过后,我将这个场景和组件样式予以记录并更新设计规范,并在周会时向成员宣讲同步了此场景和组件样式。整个流程为:设计——汇报——评审——记录并更新——宣讲——应用。如此一来,其他成员在后续若遇到类似场景便能复用或借鉴,避免在碰到新场景时各自为政,也能够提升成员设计稿的一致性。
二、外因症结与处方
1、产品迭代速度与设计规范迭代速度产生冲突
症结 - 产品迭代速度过快,导致设计规范的迭代速度跟不上
在部分产品进行视觉焕新的过程中,由于涉及的更新内容极为繁杂,且迭代计划采用了敏捷性的方式,这就不可避免地出现了一些状况。部分设计规范的内容未能及时更新,甚至有些还未确定下来。这种情况直接导致团队成员在这期间所产出的设计稿存在差异。比如说图标的风格,就出现了新版与旧版相互替换的混乱局面。
处方 - 在适当时机让团队成员加入共创
在设计规范文档落地实施前以及落地后出现变更时,不但要向设计团队内部成员进行同步宣讲,还需与项目相关的外部团队成员实现同步对齐,例如业务方成员、产品经理、开发团队等。如此一来,外部团队成员便能迅速明晰设计的标准与要求,无需耗费大量时间去摸索和揣测,从而能够更为迅速地开展工作,减少不必要的沟通以及反复修改,极大程度地减少了因理解存在差异而产生的误解与争议,让团队之间的沟通变得更为顺畅和高效。同时,这能够使外部团队成员的设计思路与整体项目的目标和预期保持一致,有效避免出现偏离主题或者不符合项目定位的设计。而且,这种做法还展示出了对外部团队的尊重与支持,让他们切实感受到被重视,有利于构建起更为稳固的合作关系和信任基础。大家依据相同的设计规范展开工作,能够更出色地协同合作,共同为达成项目目标而携手共进。
2、外部成员个性需求偏好
症结 - 外部成员(业务、产品、开发)有个性化需求偏好
前3个原因都属于内部因素,那么业务团队、产品团队或其他相关团队成员导致的出现设计稿差异,就属于外部原因。在2020年的时候,我在给业务出经营数据看板的需求时,就遇到过这种情况,当时业务团队认为产品现有的数据图表配色有些幼稚,看起来不够专业,要求重新出一套新的配色,这就导致在数据图表的场景,配色方案不一致,为此我还将这个情况上报给该项目设计规范的主理人,在经历了几天夹心饼的体验,最终设计团队向业务妥协。
处方 - 不定时向外部成员宣讲设计规范更迭内容
在设计规范文档落地实施前以及落地后出现变更时,不但要向设计团队内部成员进行同步宣讲,还需与项目相关的外部团队成员实现同步对齐,例如业务方成员、产品经理、开发团队等。如此一来,外部团队成员便能迅速明晰设计的标准与要求,无需耗费大量时间去摸索和揣测,从而能够更为迅速地开展工作,减少不必要的沟通以及反复修改,极大程度地减少了因理解存在差异而产生的误解与争议,让团队之间的沟通变得更为顺畅和高效。同时,这能够使外部团队成员的设计思路与整体项目的目标和预期保持一致,有效避免出现偏离主题或者不符合项目定位的设计。而且,这种做法还展示出了对外部团队的尊重与支持,让他们切实感受到被重视,有利于构建起更为稳固的合作关系和信任基础。大家依据相同的设计规范展开工作,能够更出色地协同合作,共同为达成项目目标而携手共进。
三、设计规范的二八原则
前段时间参加设计圆桌会时,对于规范存在的价值,大家都有不同见解,有的认为规范最大价值就是提效、建立一致性,但也有认为规范阻碍了创新空间,最终导致产品同质化严重。对此我认为规范还是有存在的必要的,一来可以助力产品构建一致性,品牌认知度,还能为团队提效,给用户带来稳定、统一的视觉和使用体验。但创新和灵活性也是一款产品设计的点睛之笔,不仅可以满足用户不断变化的需求,还能为产品提升竞争力同时,刺激团队创造力。所以在构建设计规范时,我一直都遵循二八原则(为了帮助大家更好的理解所以给出了具体百分比,但实际操作时并不需要严格按照80%,20%的配比来构建设计规范,这里提到的二八原则只是一个概念)。
1、场景的二八原则
首先,要清晰明确地定义场景的含义,即业务场景、用户场景、设计场景。而所谓场景的二八原则指得是:对于能够被判断,易评估的场景,可以统一归为基础通用场景;而那些无法判断难以评估的场景则统一称为个性化场景,因而可以暂时不纳入规范当中,根据后续场景的完善慢慢迭代。
在产品设计领域,如果期望一套设计规范就能把整个产品的所有场景都完美覆盖,我个人认为这是不太可能实现的。要知道,一款产品是随着市场、业务、品牌、公司目标等诸多因素呈动态发展的。特别是 B 端产品,其体量庞大,业务往往复杂且多变。倘若要制定出一套能够完全覆盖整个产品的设计规范,那所耗费的人力成本和时间成本无疑是巨大的。而且,产品的迭代也可能会因为等待设计规范的完成而停滞不前,这对产品的发展极为不利。
所以,我一直倾向于遵循场景覆盖率的二八原则。只要设计规范能够覆盖当前产品设计场景的 80%以上,我认为这套规范就具备推动落地的可行性。毕竟产品处于不断发展和改进的进程中,是持续迭代的,设计规范也必然要随之不断更新和完善。
2、规则的二八原则
设计规范指的是是一套为了确保设计的一致性、提高效率、保证质量以及满足特定业务需求和用户体验目标而制定的详细准则和标准。而设计规范的规则是指在设计过程中为实现设计目标、保证设计质量和一致性而制定的具体要求和限定。简单的来说,设计规范的规则指的是某个组件或某个设计语言的规则,而设计规范则是所有规则的总和。
在制定规则时,也可遵循二八原则,即固定规则占比80%,可不固定规则占比20%,什么是固定规则,什么是不固定规则呢?固定规则是指那些在大多数情况下都必须严格遵循,很少有变动或灵活性的规则,比如:主题色、主按钮样式,输入框,不固定规则相对来说具有一定的灵活性和可调整性,会根据具体的情境、特殊的需求或者不断变化的条件而有所变化,比如:卡标题的装饰性图标,特殊页面的布局等。
小到设计语言,到模板页面都可以遵循规则的二八原则,以标签的色彩规则为例。
总的来说,固定规则为设计提供了稳定性和一致性的基础,不固定规则则在一定程度上允许创新和适应特殊情况,以保持设计的灵活性和适应性。
因为每一个设计元素/组件都有自己的特性,所以没有办法将所有规则都作出示范,我也一直在思考有没有一个公式,可以帮助设计师在搭建设计规则时作出参考,我想到了香港大学ICB商业学院副教授汪志谦老师,在《峰值体验》这本书提到的MOT组成三大要素,可以借鉴MOT这个套式,结合我自己在设计设计规范规则时,我会运用到的一些思考,我整理出下列公式(当然也希望有更多的同行,能探索出更有深度,更通用有效的公式)。
3、页面的二八原则
在我们的设计规范中,页面样式遵循也可以二八原则。除了精心打磨设计语言和设计组件外,我们还梳理出了典型模板页面,并将其命名为“基础典型页面”。这些基础典型页面承担着至关重要的角色,它们要支撑 80%的使用场景。通过保持一致性,用户无论在哪个页面都能迅速熟悉操作,强化了品牌在用户心中的认知,大大提高了设计与开发的效率,同时有力地保障了用户的优质体验。而剩下的 20%页面则被设定为个性化页面,其目的在于支撑那些特殊的个性化场景。它们能够突出个性重点,为整个设计提供了灵活性和创新的空间,使我们的页面设计既能满足大众的常规需求,又能在特定场景下展现独特魅力。
四、设计规范相关文档与资源库
1、TOKENS文档与插件
腾讯文档 Token 变量表:https://mp.weixin.qq.com/s/sRRPlsxaUZj7220PLoFiRw
腾讯 TDesign 开源设计系统 Token:https://github.com/Tencent/tdesign-common/blob/develop/style/web/theme/_light.less
Github Token命名文档:https://github.com/Tencent/tdesign-common/blob/develop/style/web/theme/_light.less
Figma Tokens 插件
2、国内大厂设计系统资源库
蚂蚁组件库:https://ant.design/components/button-cn
字节设计系统开发资源:https://arco.design/
腾讯设计系统开发资源:https://tdesign.tencent.com/
Element设计系统开发资源:https://element-plus.org/zh-CN/
Eva设计系统开发资源:https://eva.design/
Echarts可视化设计开发资源:https://echarts.apache.org/examples/zh/index.html
3、国外设计系统资源库
IBM的B端设计系统:https://carbondesignsystem.com/
Atlassian 的设计系统:https://atlassian.design
Shopify Polaris- Shopify 的设计系统:https://polaris.shopify.com/whats-new
Design System Repo - 设计系统示例、资源和工具的精选集:https://designsystemsrepo.com/design-systems
谷歌设计综合资源:https://design.google/
Material Design:https://m3.material.io/
Apple Developer:https://developer.apple.com/cn/
五、最后的思考
总之,实现设计规范的有效传达和设计产出物的一致性是我们团队不懈追求的目标。在未来的工作中,我们将持续关注并解决这些问题,不断优化设计规范和传达方式,充分发挥其作用,提升团队的整体设计水平和协作效率,打造出更加优质、统一且具有创新性的设计作品,为用户带来更出色的体验,为品牌塑造更卓越的形象。
但我常常会听到一种声音“B端就是套组件,不需要有太多的设计”,但我自己一直都不太苟同这种观点,因为这句话咋听之下好像没有问题,其实是在侧面否定以及降低设计师价值,只会让更多的人认为设计师就是个画图工具人,虽然市面上已经有很多成熟的开源设计规范资源,一定程度上降低了设计师整理设计规范和设计组件的难度,但要做好一套设计规范去落地,难度还是很大的,如果只是机械得套用大厂的规则,也势必会让产品趋于同质化,最终只会扼杀设计师的创新能力。
不管是交互体验还是视觉体验,我认为都是体验不可分割的一环,因为人的体验感官也不是单一的,触觉、听觉、视觉、嗅觉、味觉这五感都会触发用户体验,一款产品的价值呈现除了提升交互体验,优秀的视觉体验也是能为产品提升价值的,就如同是世面上高客单价的产品无一例外不对包装用心的。
有人也会提出一种观点,随着AI的发展,也许未来AI会直接把设计规范的工作给兼容了,但我认为AI的价值更多是辅助人类从而提高工作效率的的,而不是代替人类的,即使AI真的可以完成设计规范的工作,但是如果设计师懂得设计的底层逻辑,反而可以将AI化成利器,去做更高价值的产出。
176
Report
声明
169
Share
相关推荐
in to comment
Add emoji
喜欢TA的作品吗?喜欢就快来夸夸TA吧!
You may like
相关收藏夹
Log in
99+Log in and synchronize recommended records
99+Log in and add to My Favorites
评论Log in and comment your thoughts
分享Share




















![瓶子集合啦[图标、icon]](https://img.zcool.cn/community/0314b62576613170000018c1b098c85.jpg?x-oss-process=image/resize,m_fill,w_520,h_390,limit_1/auto-orient,1/sharpen,100/quality,q_80)
![一组图标两种风格[icon/ICON]](https://img.zcool.cn/community/03179eb5738499f6ac72580edcde150.jpg?x-oss-process=image/resize,m_fill,w_520,h_390,limit_1/auto-orient,1/sharpen,100/quality,q_80)
![小小僵尸先生手机主题图标[手机主题ICON/手机icon]](https://img.zcool.cn/community/0314dae571cb1fa0000017d6cfd5f3d.jpg?x-oss-process=image/resize,m_fill,w_520,h_390,limit_1/auto-orient,1/sharpen,100/quality,q_80)







































































