大家好，这里是和你们聊设计的花生~近日，世界顶尖包装设计平台及设计大赛 Pentawards 发布了 2022-2023 趋势报告。Pentawards 团队在浏览审查了来自 5 大洲 60 多个国家的 2000 件参赛作品之后，最终确定了 10 个将在未来一年中塑造包装设计的关键趋势，而这些趋势将会成为指导包装...

大家好，这里是和你们聊设计的花生~

近日，世界顶尖包装设计平台及设计大赛 Pentawards 发布了 2022-2023 趋势报告。Pentawards 团队在浏览审查了来自 5 大洲 60 多个国家的 2000 件参赛作品之后，最终确定了 10 个将在未来一年中塑造包装设计的关键趋势，而这些趋势将会成为指导包装设计领域现在和未来发展方向的重要指南。

最新整理！设计师必备的5个专业包装设计灵感网站 大家好，这里是和你们聊设计的花生~ 所谓人靠衣装马靠鞍，对产品包装来说也是一样的道理。

阅读文章 >

一、罐装的崛起 传统包装在近年来一直有崛起的趋势，究其原由也许是制作材料的环保可回收性，也许是在运输环节更加节省成本，又或者仅仅是为了从同类包装中脱颖而出，给人带来有新鲜感。

罐装设计的崛起之势在饮料行业已经酝酿了好几年，今年的饮料白金奖得主就是这一趋势的完美范例。Williams 鸡尾酒是鹿特丹一家酒吧在停业期间为了将来继续营业而研发的，在完善了酒的配方后，他们想让外包装也更有吸引力。最终得到的结果是 6 种不同口味的鸡尾酒各有 6 种不同的标签和 Logo，而这些内容最终都集中呈现在一个 100%可回收的薄轧钢罐里。

而在饮料市场以外的领域，易拉罐的身影也悄然出现。在这个被玻璃瓶和塑料袋装占领的市场中，Potts'希望自己的烹饪酱料能以一个独特的外观在货架上脱颖而出。考虑到环境问题，公司最终选择了可回收的铝罐——尽管这是软饮料最常用的包装。由于无法看到产品是什么样子，铝罐包装上的图形和设计必须更用心，以清楚表达每个包装中的不同味道。

还有就是彩色隐形眼镜 CoFANCY 的包装和 Aokka 咖啡的 WHAT NEXT 系列包装。

COFANCY CONTACT LENS CAN COLLECTION

AOKKA VISUAL IDENTITY AND PACKAGING DESIGN

趋势启发：

我们希望看到罐装包装成为食品和饮料行业中越来越受欢迎的选择，因为它在提供新奇和差异化的同时，也提供了可持续发展的 包装设计 思路。正如 Potts'的例子所示，我们预计这一趋势将超越人们熟悉的饮料和罐头领域。我们还希望看到高端产品和品牌使用带有复杂图形设计的罐头包装，将罐头重新定位为一种高端包装选择。

二、包装即产品 可持续发展的理念不再是一种趋势，而是任何包装设计过程中的一个基本组成部分。为了节省空间和避免浪费，越来越多的产品包装成为产品本身的关键部分。在这方面做得很好的例子是今年的钻石奖——最佳展示奖得主Urban Forest的颈枕。其贝壳形的外包装由硅胶材料制成，既可以作为储物袋，也可以用作充气泵。这种包装设计鼓励消费者不要丢弃它，并巧妙地改变了充气枕头的使用方式。

还有就是 F SolidPod 的设计。它是一个实用便携的小盒子，由可回收材料制成，用于容纳各种可替换的香皂或固体清洁膏。F SolidPod 的设计让香皂可以最大程度的得到利用，在使用时也不易滑落，还不易滋生细菌，是作为化妆品和个人护理行业一次性包装的替代解决方案而开发。

同样体现这一 设计趋势 的还有香奈儿为庆祝 N°5 香水问世 100 周年而设计的降临节日历。采用了香水瓶标志性外形并制作成了超级尺寸，包装使用环保模制纸浆，里面的每个小盒子上印有一个日期。包装的各部分一起构成一本日历，这让整个产品既有环保意义又极具收藏价值。

趋势启发：

"包装即产品"是推动更多可持续包装解决方案和循环经济的必然结果。然而就这一趋势的发展而言，我们希望看到更多美学与功能的融合，创造出既美观又能鼓励消费者保留和重复使用的包装，同时在运输成本和废物方面也具有环保意识。

三、以消费者为主导可持续发展 个人护理和美容行业每年在全球范围内生产超过 1200 亿个包装，品牌和机构一直在寻找方法来减少它们的影响。有越来越多的品牌与消费者沟通，告诉他们可以做哪些事情来帮助完成更加环保的循环，教育消费者如何处理包装上的各种元素也有助于让他们也承担起一些责任。这可以看作是去年我们看到的一个趋势的进步，即品牌通过他们的包装讲述他们的可持续发展故事。

高露洁的 "Recycle Me "牙膏管，是同类产品中的第一个，希望通过明显的回收标识来提高消费者的意识并促进他们的行为改变。Carte Dors Affogati 冰激凌系列则已经改用 100%可堆肥和可回收的纸张，并说明了哪些元素需要回收或堆肥。

Colgates 的 Recycle Me 系列牙膏

Carte Dors Affogati 冰激凌的可回收纸张包装

Dove 的可重复使用的沐浴露瓶和浓缩液补充剂设计也体现了同一理念， 为有生态意识的消费者提供了一个减少浪费的简单解决方案。关于如何使用补充剂和这样做的积极影响，在包装的各个部分都有清晰的说明。

趋势启发：

对于品牌来说，这种包装设计让消费者有机会更多地参与到品牌的可持续发展的故事中来，反过来又可以促进消费者对品牌的忠诚度，因为他们感到对地球的共同责任。

四、超大胆的视觉效果 在被疫情阴霾笼罩的世界里，人们对令人惊叹的视觉因素的需求非常强烈。因此，品牌必须靠视觉在实体店、线上网店以及社交媒体上脱颖而出。为了做到这一点，我们看到品牌专注于大胆的颜色、字体和图形。

护肤品系列 BYOMA 使用现代简约的字体、图标和大胆的色彩来展现品牌的先锋科学属性和创新性。该品牌的方形瓶子便于有效地运输，以减少其碳足迹。

在与安迪-沃霍尔基金会的联名合作中，SK-ll 的包装从沃霍尔标志性的电视测试图案中获得灵感，设计了具有 VHS 磁带和电视屏幕特色的礼品套装盒，呈现了独具一格的视觉效果。

趋势启发：

虽然使用大胆的色彩本身并不是一个完全原创的趋势，但在日益激烈的社交媒体竞争中，以及在与强大专业的 DTC（直接向消费者）品牌的激烈竞争中，想脱颖而出必须采用强烈和极端的色彩模式和排版。且是简单而大胆的，而不是复杂的，因为前者才是在数字环境中最突出的东西。然而我们预计这种趋势终将达到饱和点，这时我们可能会看到更勇敢的品牌选择单色或更柔和的配色方案。

五、超级优质玻璃 随着品牌的可持续发展，我们在货架上和网上看到越来越多的玻璃包装。为了给产品增加更多的亮点，我们也看到许多瓶装软饮料转而采用定制的强化玻璃瓶，并进行超高级的细节处理和加工。

MATCH 的汤力水标签看起来和感觉都很独特，因为它们有一个微穿孔的外观和橡胶的柔软触感，让人联想到新的自行车或网球拍手柄的奢华感觉，而 Pursues Hard Seltzer 硬苏打水创造了一个定制的瓶子，提供了一个更怀旧的外观和更独特的使用体验。

MATCH 汤力水包装

Pursues Hard Seltzer 硬苏打水包装

我们还看到 Maybe Sammys 酒吧的瓶装高级鸡尾酒的包装设计，通过瓶身纹理、简单而精致的标签体现对细节的考究，使得包装与酒吧一样精致优雅。酒吧的绿色和金色已经成为该品牌的代名词，这种色调被延伸到包装细节中。

MAYBE SAMMY BOTTLED COCKTAILS

MAYBE SAMMY 是悉尼的著名酒吧

趋势启发：

我们期待品牌通过使用回收玻璃来提高其玻璃包装的可持续性，向循环经济靠拢。由于品牌必须千方百计努力地建立客户忠诚度，而有意识的消费者在购买时会变得更加挑剔，因此包装能否给人的优质感受将十分重要。

六、无障碍和包容性的设计 能包容更多消费者的包装设计是品牌巩固自己地位有切实举措，无障碍的设计的趋势现在正赢得更多的关注，成为许多品牌的必备品。

在与残疾人的合作中，Microsofts Surface Adaptive Kit 的包装被设计为无障碍模式。包装上带有标签，可以帮助那些有视力障碍或残疾的人使用他们的 Surtace 笔记本电脑；还有便于拆卸的集成环以及盲文 QR 码，都帮助了此类用户的解决自己的遇到的问题。

多力多滋的发起的“Solid Black”活动设计旨在为黑人创作者发声，让他们的故事被更多人知道，为此多力多滋推出了限量款包装，还向对应的非营利组织捐赠 500 万美元，作为该活动的一部分。这些都是包容性设计的体现，并将包装设计与现实世界的变化联系起来。

趋势启发：

随着品牌对其受众的多样性和需求的理解在不断深入，体现无障碍和包容性理念的 包装设计趋势 必将进一步发展。在今年的 Pentawards Festival 上，Diageo 的全球设计总监 Jeremy Lindley 强调了设计中无意识偏见的危险性，以及设计中仍然缺乏真正的同理心的事实。Lindley 还谈到游戏性是创造真正的包容性设计的最重要的工具之一，我们期望未来几年在包装上看到更多为不同的受众设计的游戏性解决方案。

七、触感细节 人们总是偏好新奇的感受，品牌也想借此吸引消费者，因此包装设计被附加了视觉维度之外的另一个维度——触觉，为更多人打开了全新的包装体验。

在限量版的 AVYUN 葡萄酒中，设计的核心元素是一片压印的葡萄叶，红色的颜料在其凹陷的脉络中不同程度地流动着，以反映葡萄酒的成熟度。

同时，Almatura 使用手工制作的回收标签，摸起来质感十足的纤维使人感受到产品的自然品质。压印的字体进一步增加了质感，且标签可以直接种植在土壤中使其种子发芽，繁殖植物生命。

趋势启发：

我们期待看到更多独特而有创意的包装体验方法，因为在一个日益数字化的世界里，有形的价值将继续吸引消费者。使包装更具有感官多样性的想法，必将与正在兴起的无障碍和包容性包装设计同步进行。

八、升级的智能包装 品牌正在不断寻找新的方式来与消费者进行沟通和交流，近年来智能互联性质的包装也急剧增加。作为一个相对较新的趋势，我们已经看到它以新的和令人兴奋的方式继续发展。

时尚鸡尾酒品牌 The Fetichist 的包装设计使用了大胆的数字霓虹灯效果，灵感来自于视频游戏和夜晚世界，而酒瓶包装上醒目的二维码则让消费者可以在扫描发现更多鸡尾酒并在线购买。

FaceGym 是一个以运动为灵感的美容品牌，拥有独特的类似私人教练的应用技术，但只能通过二维码访问。他们在包装上创造了一个触感良好的标签，吸引了消费者的注意二维码，并通过观看教学视频获得更好的护肤体验。

趋势启发：

随着技术和社交媒体的日益成熟，我们期待看到品牌以新的方式与消费者建立联系，而不仅仅是包装盒上显示的内容。我们也希望这些内容能让消费者参与到全球性问题以及每个产品背后的可持续发展故事中，因为这些对全球受众来说越来越重要。

九、包装也需“瘦身” 环境问题的越来越不容忽视，因此我们考虑的不仅仅是材料的可回收性和可持续性，还包括如何简化包装，以减少浪费并节省运输费用。

作为减少塑料使用的一部分，SONY 开发了一种新的包装材料，由竹子、甘蔗纤维和再生纸制成，将 WF-1000XM4 耳机的包装尺寸减少了 34%。

同时，VETA 酒瓶的包装被设计成最大程度上贴合酒瓶本身的几何形状，且使用的是可持续的模塑纸浆。这种设计既以一种有吸引力的方式保护产品，同时又最大限度地减少包装。

趋势启发：

简化包装作为一种相对简单的可持续发展方法，对品牌来说也很有成本效益，随着过度包装和浪费行为被越来越多的消费者反感，我们希望这一趋势能够长期持续。当品牌使用二维码链接到数字信息，而不是使用空间和多余的材料在包装上展示产品细节时，我们会注意到智能包装的概念与这一趋势相结合。

十、涂鸦 我们还看到手绘插图或手写笔记风格的包装也在增加，它能唤起了一种个性化的感觉及与品牌进行直接的情感交流。

疫情居家期间许多人重新拾起写作或绘画这样的爱好，以宣泄内心的情绪。于是 Vouni Panayia Winery 发布限量版的 "Untitled（无题） "系列葡萄酒时，在包装上为这样情绪留下一个呈现的窗口，同时也是许多人可能已经感受到了的—— 自新冠疫情开始以来 "We are not drunk enough to survive the 21st century（我们没有醉到足以在21世纪生存）"。

一个针对年轻人的新啤酒品牌 Lovibonds 在其包装标签上用发光的墨水描绘了两种不同的场景：白天是宁静的插图，晚上是嘻哈的氛围。

同时，菓语复合果汁的包装上是一幅有趣的 "水果怪兽 "的 插画，其中有充满活力和想象力的符号图案的涂鸦，这种创造性的方法有助于它在竞争对手中脱颖而出。

趋势启发：

随着数字世界的发展，我们认为手绘图案将继续在包装中发挥作用，作为对越来越多的模拟设计的一种平衡。特别是涂鸦个性而自由形式，让人联想到孩子般的创造力，这将继续吸引所有世代的人，为包装的视觉设计带来特别的人性感觉。

以上就是今天为大家推荐的包装设计界“奥斯卡”Pentawards 发布 2022-2023 趋势报告。

喜欢的话记得点赞收藏，也可以转发给身边有需要朋友 。如果有关于本文或者设计的疑问，可以在评论区提出，我会第一时间为大家解答 ~

推荐阅读：

先睹为快！2023年值得关注的10大平面设计流行趋势 大家好，这里是和你们聊设计的花生~ 一转眼 2022 年就只剩最后一个月了，除了总结今年的收获，也是时候了解一下未来的设计新趋势了。

阅读文章 >

来了！潘通2023年度流行色「非凡洋红」正式发布！ 每年12月初，潘通都会踩着点发布第二年的流行色。

阅读文章 >

本文分享个人搭建青云 QingCloud 可视化色彩体系过程中的一些经验。（阅读此文需要一定的色彩空间知识作为基础，否则有些难啃）基础科普：如何4步建立系统级色彩体系？来看京东高手的方法！

本文分享个人搭建青云 QingCloud 可视化 色彩体系 过程中的一些经验。（阅读此文需要一定的色彩空间知识作为基础，否则有些难啃）

基础科普：

如何4步建立系统级色彩体系？来看京东高手的方法！ 色彩体系的推导其实有很多文章有详细的介绍了，这一篇主要粗浅的梳理了整体流程经验，补充一下技术方法与色彩模型的差异。

阅读文章 >

一、前言 1. 背景

目前平台上使用了三套组件库 A、B、C，A 是最原始的组件库，基于此扩展了 B 组件库，并对颜色进行了改进，C 是全新的组件库，引用了 Token 及其他新的前端技术栈。三套组件库独立存在，应用在庞大的云平台各个业务产品中，发展趋势为使用 C 组件库开发日后新的业务，并逐步替换老的业务。

关于颜色，B 组件库采用 HSB 色彩空间调色并进行人工调整，C 组件库沿用 B 组件库的色板并对部分颜色进行了优化。

关于可视化组件，平台使用第三方开源图表库 Echarts 进行简单定制化。

目前的需求是基于 Echarts 系统化定制出一套图表类型较全面、交互较统一、使用规范较明确的可视化组件库。因此，确定一套可视化颜色系统成为当务之急，经过简单的调研得出两套解决方案：

方案一：沿用组件库 C 的颜色； 方案二：基于适用于可视化场景的色彩空间确定一套全新的颜色。 不难判断的是，采用方案一，要面临的问题就是：

色彩空间落后，不适用于可视化场景； 大量人工调整，无法满足日后自动化交付场景所需； 相关算法及推导过程丢失，设计侧无法进行科学化、可持续化迭代。 且在调研过程中我们发现，可视化色彩与设计系统色彩并无必要的理由进行捆绑：

一方面，可视化场景对色彩的要求要远高于设计系统组件库，因其主要通过颜色来识别数据差异，所以，对颜色的亮度、对比度、色差、和谐度等要求非常高； 另一方面，可视化组件库的适用产品类型通常是多种多样的，夸张点讲就是任何类型的产品中都可能会用到可视化。这一点就需要可视化组件库拥有很强的风格兼容性，这就导致了其颜色必须兼容性强，并非随便拿一套设计系统色彩过来就能满足的； 设计系统中的颜色使用场景与可视化中的颜色使用场景不同，这就导致很多已经成型的设计系统色彩从设计之初的（设计目标）就不适合拿来做 可视化设计 ； 再向底层去挖掘，很多设计系统的色彩空间不适合可视化场景，这会导致相关扩展色板的推导流程甚至主题演变流程变得异常困难。 最终，我们采用了方案二，也就有了接下来要发生的事情。但在开始之前，我们需要想清楚几个问题。

2. 理想的可视化色彩特点是什么？

看待这个问题，其实我们要搞清楚的是可视化场景对颜色的要求是什么？

① 保证同色相或不同色相之间的辨识度与色差是基本要求

可以毫不夸张的说，可视化系统就是一个色彩系统，无论多么复杂花样繁多的图表，都要依靠颜色去表达。而在众多表达手法中，颜色与颜色之间的对比是最常使用的。

② 颜色所传达出来的感觉要准确

众所周知，颜色不仅仅能表达人类的情绪，如热闹、喜庆、冷淡、沉稳。还能表达事物的特征，如温度冷暖、海拔高低、数据升降。

③ 充分考虑色盲色弱等视障群体的使用体验

我们在产品设计过程中经常会提到无障碍设计，也通常会在设计系统中对颜色对比度、字体大小等做一些验证，也会充分考虑用户设备情况及产品使用环境做一些针对性设计。在可视化设计中，这些验证是相通的。

④ 颜色的生成、演变与应用是动态的

前面我们提到过，无论是产品迭代还是纯视觉升级亦或产品交付自动化，从技术架构到颜色算法在设计之初都要充分考虑扩展性。以至于在可视化设计中，色环的确定、色板的生成、色彩的搭配、色序的应用等都要保证有理有据且灵活可变，充分兼容复杂极端场景。

注意，颜色算法是指通过大量实践、总结和优化，可以用来相对科学的批量的解决符合一定规律或映射关系的场景问题的一种途径，其产出相对理性过程也相对高效，是做后续颜色优化工作的基础，可以大大降低人为干预的几率，而非一成不变的去应用。

⑤ 颜色搭配要符合产品调性，是品牌的延续

可视化的应用场景非常广泛，从国家生产总值到个人收支明细，大到政务系统小到记账 App，都有其载体风格调性，如中立、活泼、科技等，均不能脱离于“品牌”而设计。

⑥ 保证颜色的美观性

回到设计本身，也是设计本质---美，还是要保证的。

3. 传统的色彩空间弊端是什么？

我们先来简单看一下使用传统的色彩空间是如何配色的。

此处受 @lemonoO 的启发

最初，互联网上的产品形态比较简单，对颜色的定义仅仅局限于红、黄、蓝、绿四个语义色上，用来模拟表达成功、失败等情绪。

在此之上，手动扩展几个相对深与浅的颜色用于如按钮 Hover、Active 状态。

颜色之间依靠一些配色工具在色盘上根据对比色、互补色等原理进行搭配。

随着互联网的飞速发展，互联网产品的形态逐渐复杂，组件也日趋完善，人们不断探索能够满足更多使用场景的配色方案，定义相对完善的色彩体系。于是，Tint&Shade 扩展色阶的方案就出现了。

该方案通过定义基准色后分别向深浅两个方向叠加不同不透明度的黑色与白色来生成色阶，达到扩展基础色板的目的，典型的工具如 Tint and Shade Generator。

后来人们发现，这种方案虽然简单粗暴，但依靠叠加不同量黑色与白色生成的色阶存在一些问题或不满足使用场景，如首尾丢色严重，无法通过色相偏移的方式制造冷暖效果等。

于是，基于更符合人类认知的色彩空间如 HSB、HSL 生成色阶法就诞生了，并成为至今使用范围最广的方案。

以 HSL 为例，该方案通过将颜色定义为符合人类认知的三个变量：色相、饱和度、亮度，分别进行控制并灵活调配，如固定饱和度与亮度，在色环上通过改变色相生成基础色。

或固定色相与饱和度，通过调整亮度生成色阶。

就如同人类科技发展史一样，人们总是在发现问题解决问题和改进方案。如下图所示，这种符合人类认知习惯的色彩空间搭配出来的颜色，其数值亮度并不是与人眼感知亮度相通的，这注定需要人为介入来改变局面。

以至于依靠这种方法生成的色彩阶梯肉眼可见的过渡不均匀，且同阶梯不同颜色间差异过大。

于是乎，这里调一下亮度，那里调一下饱和度，经过不懈的努力花费了巨大的成本终于得到了满意的效果，然后发现整个色板参数完全失控了。

推导经验无法复用，色板升级只能肉眼调，主题定制纯靠研发批量替换......

至此，人们发现，传统的色彩空间配色方案弊端主要体现在无法科学准确的表达颜色亮度上，也终于意识到，计算机对颜色的识别和处理是线性和对称的，而人眼对色彩的感知是非线性和不均匀的。

简单的例子就是红色比蓝色亮（刺眼），绿色比红色亮（刺眼）。

所以，这些基于 RGB 色彩空间扩展出来的配色工具或空间（HSB、HSL 等）终究是要被取代的，这也正式促使了 感知均匀色彩空间 的诞生。

由 CIE 组织（国际照明委员会）于 1976 年提出，理论上可以覆盖人眼所能识别的所有色彩，其颜色总量远大于传统色彩空间，最大的特性就是数值变化均匀则颜色变化均匀，亮度亦如此，人们终于可以客观的依据数值来判定颜色了。虽并非完全意义上的感知均匀，但相比传统色彩空间已是质的飞跃。

完整介绍可参考《基础概念》篇，这里不做赘述。

4. 为何选取感知均匀的色彩空间？

很多可视化产品都在推荐使用人眼感知均匀的色彩空间来搭建可视化色彩系统，不断强调感知亮度均匀，但并没有告诉大家为什么。

首先，这里需要强调的是，我们所追求的感知亮度均匀更贴切的说法应该是追求亮度的准确表达。

表达是否准确就像建房子一样，砖是墙的基础，墙美不美观稳不稳定，取决于每一块砖的大小是否标准，而衡量这个标准的前提是砖的长宽高都是可被衡量的。与之对应的，色板是否“美观与稳定”，取决于每一个颜色是否标准，而衡量这个标准的前提是颜色的每个指标都是可被衡量的。

图片源自网络，侵权请联系

基于这个前提，我们就可以顺利地构建出一个可被衡量且变化均匀的全量色板。

其次，区别于设计系统的是，可视化场景需要基于全量色板按照特定的规则扩展出不同类型的色板，如分类色板、发散色板等，而亮度又是这些特定规则中的重要指标。

因此，一个可被衡量且感知变化均匀的全量色板何尝不是可视化设计的最佳选择呢？

再其次，我们反向思考一下，如果将感知不均匀的色彩空间应用在可视化场景里会发生什么呢？

下面是一个描述美国各地雨水蒸发量的案例，可以非常明显的观察到一条分界线将整张地图一分为二，这很容易让人在解读数据时发生误判---分界线两侧数值发生了巨大的变化。

作者：Robert Kosara，查看 原文 。

而通过观察其图例上的数值后发现并非如此，分界线两侧的颜色所代表的数值区间差均为 0.09，与其他颜色并无差异。

这正是由于分界线两侧的颜色感知亮度有较大差异，以及不同色调之间过渡不均匀所导致的。

通过这个案例我们可以看出来，很多对数据精度要求高的场景（如气象预测），在分析数据时，需要遵循一个很重要的原则就是保证颜色的客观性，降低颜色对数据分析结果的影响，降低解读数据时数值变化量误差（对应色彩变化量）。

最后，总结一下，使用感知均匀的色彩空间可以让我们收获什么？

它可以让 设计师 真正拥有明辨色彩是非的能力。在看似复杂的全量色板上客观、有依据的挑选合适的颜色（通过数值判断颜色是否合适而非阶梯判断），用以表达明暗、冷暖关系（如发散色板的构建），构建贴近工程化理念的配色方案（如动态顺序色板的构建）等。

5. 如何选取感知均匀的色彩空间？

在众多感知均匀的色彩空间中，选取适合我们的色彩空间需要满足以下几个基本条件：

易于操作，最好是有成熟的工具或算法可以用来深入了解对比； 颜色变量易于理解，最好能够像 HSL 等空间一样符合人类认知； 可生成自定义数量的阶梯，且每个阶梯的亮度可以自由把控。 ① CIE 系列

基于这些基本条件，我们首先排除了 CIELab（CIELuv 与之类似），其色彩空间由 L（感知亮度）、a（红绿通道）、b（蓝黄通道） 三个变量构成。L 变量是相对可控的，但 a、b 变量不符合人类的认知，类似于 RGB 调色板一样，不同的颜色是通过改变 a、b 变量中的红绿与蓝黄的量而得出的。

但也不排除使用该色彩空间配色的可能，观赏一下。

而 CIELch 是 CIELab 的极坐标转换，通过易于理解的 L（感知亮度）、C（色度，可简单理解为饱和度）、H（色相）三个变量来形容颜色。同时，生态也比较完善，有多种工具可以不同程度的帮助我们生成色阶，作为保留方案。

② OK 系列

OKLab、OKLch 针对 CIE 系列空间做了进一步优化，纠正了色相偏移（阿布尼效应）与色度对感知亮度的影响（亥姆霍兹-科尔劳施效应）。

但这类色彩空间目前还处于早期阶段，生态不完善，兼容的场景也很少，仅有的工具也只能作为调色器（如这个工具 OKLch-Picker）使用。此外，在该色彩空间内，固定色相与色度的同时可覆盖的亮度区间要小于 CIE 系列色彩空间，超出限定区间的颜色又无法在 sRGB 色域内甚至任何设备上正常显示，用于生成色阶非常局限。所以，放弃之。

无论使用任何色彩空间进行调色，我们最终都要保证所有颜色均能在 sRGB 色域内正常显示，这是底线。比如你使用了 P3 色域中的颜色，则会有部分用户的设备无法显示并自动取 sRGB 色域中相似的颜色来呈现，从而影响你的设计交付效果。

③ HCT

HCT 色彩空间是谷歌在 Material Design 3.0 中推出的新方案，基于 CAM16 色彩空间与 CIELab 色彩空间进行了优化，通过 H（色相）、C（色度）、T（光度，源自 CIELab 中的 L） 三个变量描述颜色。

官方提供了在线配色工具，但使用该工具生成的黄色显脏，可用色阶少，且无法自定义色阶，许多颜色在色阶两端有丢色偏色的现象。

但好在开源，我们可以借助其算法通过在代码中自定义 T 的数量及数值模拟我们想要的效果。单看生成的色阶效果其实还不错，也能够满足基本的使用需求。

代码源自：Jony，查看 原文 。

import { argbFromHex, TonalPalette } from "@material/material-color-utilities"; // 定义 tone 梯度 const TONE_ARR = [0, 5, 10, 20, 30, 40, 50, 60, 70, 80, 90, 94, 97, 100]; const createTonalPalette = (hex) => { // 将 hex 格式颜色转化为 argb 格式 const argb = argbFromHex(hex); // 创建 palette const palette = TonalPalette.fromInt(argb); // 在 palette 上取一组 tone 梯度对应的颜色数组 const colorArr = TONE_ARR.map((t) => hexFromArgb(palette.tone(t))); return colorArr; };{{{pre>

其感知亮度变化也是相对均匀的（PS 灰度模式效果）。

大家可能在很多教程里都看到过使用灰度模式（用词精确，非黑白模式）来模拟感知亮度变化。首先需要申明的是：在 PS 里，有一个图层叠加模式叫“明度”，在 Figma 里叫 Luminosity，总之使用这种方式来模拟的效果都是不准确的，推荐使用 PS 中的灰度模式来模拟，或者直接打印出来查看效果。

那为何使用灰度模式来模拟呢？（这个问题并未找到科学靠谱的答案，属于猜测）

相信大家在初次接触美术时都学过素描，通过简单的黑白灰来表达一个物体的光影、层次关系，而色彩会有很明显的情绪传达。所以，要想表达人眼对色彩亮度的感觉，是不是去掉“色彩”会相对客观一些呢？

基于该结论，我们还会发现这种方式除了可以用来模拟感知亮度变化以外，还可以用来体现明暗关系（如视障用户无法顺利通过颜色辨别图形时可以依靠明暗对比来辨别），以及用来还原打印效果（打印数据图表分析数据）等。

但有一个非常让人难受的缺陷：默认情况下 Key Color（或主题色）很可能会不存在于生成的色阶中，这就意味着需要不断去尝试取 Key Color 相邻的色值让其存在于色阶中，或者通过定义无限多的 T 数量及数值让其显露出来，这显然不符合我们“易于操作”的要求，放弃之。

④ 结论

其他调研细节就不在这里啰嗦了，总之，我们最终选择了 CIELch 色彩空间。

至此，需要铺垫的内容也就告一段落了，接下来我们通过实战来看一下如何推导一套可视化色彩体系。

二、全量色板 推导整个色彩体系之前，我们已知的条件就是一个主题色。基于青云 QingCloud 品牌 VI 中定义的主题色，我们将其进行一个简单的色彩演变，降低饱和度的同时微调亮度使其更加适用于互联网产品但不脱离我们中立沉稳的品牌调性。

这里需要注意，在做色彩空间转换时，尽量保证精确度，从而提升后期颜色推导的精确度。

1. 基础 10 色 ① 24 基色

基于 RGB 色彩空间，我们首先需要绘制一个标准色盘。

通过正色取值法，以正红色为基准，间隔 15° 取色，中间会覆盖正蓝（210°）、正青（180°）等颜色，得到一个标准的 24 基色。当然，这些颜色并不能直接拿来使用。

与正色取值法对应的是主色取值法，以主题色色相为基准间隔 15° 取色，得到一个色相偏移的 24 基色。但经过尝试，我们发现，该方案由于主题色色相的不确定性（经验复用时会发生），很有可能导致取出来的颜色“不当不正”，做颜色矫正的成本较高。

② 8 基色

基于生成的 24 基色，我们选取人眼最容易识别且符合人类认知的 8 个基准色：红、橙、黄、绿、青、蓝、紫、粉。

这里取色的过程可以根据自己产品的调性对部分颜色特殊处理，如我们取的粉色就相对沉稳一些。

③ 色相矫正

虽然现在生成了 8 个基准色，但仍然不能直接使用。此时，我们需要结合一些条件对色相进行偏移。

首先是保证视觉舒适度，如黄色、青色过于刺眼； 其次是基准色之间要肉眼可区分； 最后是生成的梯度色板之间也要肉眼可区分（如我们的主题色与绿、青基准色经过感知均匀的色彩空间转换后生成的梯度色板十分接近）。 以上矫正过程需要结合后续的推导结果不断循环往复来回调整，直至符合要求。

④ 色彩矫正

前面我们花了很多篇幅介绍色彩空间，在这一步才真正得以体现。我们先将颜色转换至感知均匀的色彩空间，方便后续对色彩进行处理。

转换至感知均匀的色彩空间后，我们根据主题色的感知亮度将其他颜色也设为一致，这是体现整个可视化色彩体系贴近品牌调性的关键步骤，因为我们会拿这些基色去生成全量色板。

大家可能发现我们在这个过程中选用了 HCT 色彩空间进行转换（不是打脸哦），因其调色器工具能自动根据感知亮度调整色度致使各个颜色都保持和谐。当然，你也可以使用其他感知均匀的色彩空间来做转换，差异不大。

此外，大家可能还会有疑问，黄色和橙色怎么像?一样？为什么还放在这里？因为在真实使用场景中，色板里的颜色并不一定都能被使用到，这是其一。其二，颜色长的丑并不能否定它作为我们生成色阶的基准色。（后面的推导流程推翻了这个结论，但仍不能否定它存在于色板中）

三步变化效果。

⑤ 生成中性基色

常用的中性色大家都知道有中性中性色和冷调中性色，结合品牌调性我们选用了冷调中性色。基于蓝色我们可以通过降低色度的方式扩展出中性基色。

这里的中性色比较特殊，仅适用于图表图形中用以中和色调，而非用于文字、填充、轴线等场景的全局中性色。

⑥ 相对亮度验证

通过上面的步骤，我们得到了感知均匀的 10 个基色，我们使用 Chroma.js 中的相对亮度计算工具验证一下，方便我们基于这些基准色扩展色阶。

这里引入了新的概念“相对亮度”，可以查看 W3C 相对亮度 的计算公式和 维基百科 对其的定义。大概可以理解为感知亮度的另一种表达，任意两个颜色的相对亮度值一致说明其感知亮度（HCT 中的 T 或 CIELab 中的 L）值也是一致的。白色为 1，黑色为 0。

当然这里我们其实是无需验证的，因为在色彩矫正步骤 2.1.4 里已经基于 HCT 色彩空间将 T 设为一致了，那其相对亮度值也是一致的。我们验证的目的是为了配合后文会提到的 Chroma.js 工具及相对亮度等差数列生成色阶。

2. 完整色阶 首先需要判断一下需要多少个阶梯，通常情况下的阶梯有 7、9、11、13 几种，大家根据自己的需要选择。我们选择了 13 阶梯，一方面可以使色阶过渡细腻一些，另一方面也可以让取色范围更广一些。

其次，谈起色阶就不得不说一下插值。插值的目的是为了获取一个有规律的亮度变化曲线，使色阶过渡均匀。通常的做法就是固定首尾两个点，通过一些算法或工具生成对应的贝塞尔曲线，也可以使用简单的等差数列来完成。

而感知均匀的色彩空间有一个很大的特征就是：它的色彩空间是三维且不规则的，固定 L、C、H 三个变量并从中“切一片”下来放进二维平面中观察，你会发现它的形状是不规则的。固定其中任意两个变量改变第三个变量时，都会影响这个二维平面的形状，三者互相影响。

这里有点儿考验大家的立体几何想象能力。

这就意味着，不管你的亮度曲线是等差数列还是各种高大上的贝塞尔曲线，当你把曲线套进色彩空间中 360° 旋转切换色相生成色阶时，曲线中的某些点说不定会跑出整个三维色彩空间。这就需要联动色度及色相一起做各种矫正工作，对设计师来说学习成本和操作成本是巨大的。

我们想简化整个流程。前面我们定义好了 10 个基色，也得知其相对亮度值均为 0.287 左右，这就相当于定义好了整个色阶中的“中间”阶梯，我们按等差数列向上向下分别取不同数量的阶梯即可，之后借助现成的算法或工具帮助我们去做矫正工作。

为什么基准色阶往右的阶梯要多一些？

主要原因在于基准色阶的相对亮度较低，自然可以往亮处扩展的多一些。那为什么我们不在这个基础上间隔取样，使左右两侧的色阶数量相等看起来对称舒服一些呢？

这是由于我们在扩展分类色板、顺序色板等时发现，经常需要按不同规律来间隔取样，这样划分会使我们的可选择余地多一些，不至于陷入亮色不够用，暗色又用不到的尴尬境地。

通过调研了十几个工具后发现 Chroma.js 正好满足我们的需要。我们只需要选择合适的色彩空间，定义好 Key Color（基准色），定义好相对亮度等差数列即可顺利生成色阶。

受 @少年游 的 文章 启发，这里插播一个知识点：韦伯-费希纳定律，可以解释我们为什么会使用等差数列来设计色阶。

定律现象：人眼对亮色区域的颜色变化敏感度要高于暗色区域。

按照传统的 HSL 色彩空间生成色阶时，需要在亮色区域将阶梯层级设计的细腻一些，也就是亮度变化度（非 L 值的直观体现，需要计算）要小于暗色区域，防止使用亮色区域相邻色阶时造成亮度变化过大的错觉。如图左，浅色按钮之间的变化度为 2.6 倍，而暗色按钮之间的变化度为 1.1 倍。

而我们使用的感知均匀色彩空间就很好的避免了这个问题，只要保证颜色之间相对亮度值的变化量是一样的（等差），那就说明无论是浅色按钮还是暗色按钮他们之间的变化度也是一样的，如图右。

① 基础色阶

基于 Chroma.js，我们生成了大部分颜色的色阶。

② 特殊色阶

而当我们按照同样的规则去生成黄色与橙色色阶时，我们发现整个色阶过于偏“暗”导致可用阶梯非常少。

于是，经过不断地尝试后发现：通过提升黄色与橙色的基准色感知亮度与色度则可以提升整个色阶的亮度与色度，并保持变化均匀。因此，针对黄色与橙色，我们选择基准色色彩矫正前的颜色（2.1.3 步骤中所得出的颜色）做为新的基准色生成色阶。

这个过程由于色彩空间、算法等缺陷会导致部分颜色产生差异，但属于肉眼无法辨别的差异，还可接受。

③ 色彩矫正

现在，我们拥有一套完整的色板了。但仔细观察后发现，个别颜色有些不太符合我们的品牌调性，感知亮度或色度有些过了。

我们手动压一压，微调得到最终的全量色板。（绿色因与主题色过于接近，去之）

这些微调其实属于可以不调的程度，并不会在实际生产过程中影响自动化交付效果。

3. 色彩验证 生成全量色板后不意味着推导工作可以结束了，好的色板是要能经得住考验的，同时也是循环往复来回调整基色的必要过程。

① 相对亮度

验证全量色板中的每层阶梯颜色是否符合相对亮度标准，这也是检验色阶是否过渡均匀的重要手段。

灰度模拟效果还不错，使用 PS 中的灰度模式模拟。

亮度曲线分布一致，使用工具 Huetone 模拟。

② 色差验证

在感知均匀的色彩空间内，验证任意两个基准色之间的色差，其目的是为了保障视力正常的用户能够顺利分辨出两个颜色的不同。我们基于 CIE2000 标准进行验证，Delta E ≥

18 即满足，可用工具 Color Contrast 进行计算。

“18”这个值的说服力有待考证，暂以其为标准。

CIE2000 较 CIE1976（目前使用范围较广） 在算法上进行了优化，描述色差更加准确。

可以发现，部分颜色间的色差是不满足标准的（红字加粗部分）。

首先我们这里校验的基准色都是可以直接拿来用在设计稿中或者用于后期推导其他色板的，所以校验目标颜色的亮度阶梯是固定的，如黄色取亮度 0.6 阶梯，橙色取 0.44 阶梯。

所以，留给我们的选择就是改变色相与色度，通过微调的方式重新生成色板，使被校验的基准色达到色差要求。

经过多次尝试，我们发现：如橙色，满足色差要求的同时整个色阶会偏向红色；而黄色，满足色差要求的同时整合色阶需要偏向绿色，结果会很脏，否则会更加偏向橙色不满足要求。

最主要的原因是：感知均匀的色彩空间并不像传统色彩空间那样可以肆无忌惮的调出想要的颜色，加上工具和算法的限制会导致微调并不起作用，直观的体现就是换了其他相近的颜色但生成的色阶结果还是一样的。

这个时候我们就需要做出取舍了，我们最终选择了保视觉效果而非色差，或许我们后续还有机会回头重新看待这个缺陷。

无法满足 CIE2000 标准的颜色，也尽量保证满足 CIE1976 标准，推荐使用工具 iWantHue 计算。

③ 色度分布

观察所有颜色的色度分布趋势，我们会发现用来生成色阶的基准色刚好处于色度曲线顶点位置处，这是为何？

猜测：根据色度分布曲线我们可以大致推测出 Chroma.js 算法的关键点在于基准色，你输入的基准色的色度会是最高的，然后依次向两侧色阶降低。

那么，基于该结论，我们就可以知道为什么在步骤 2.2.2 中生成的黄、橙色阶是不理想的了。因为你把整个色阶里的最高色度点定的太低了，以至于使整个色阶偏“暗”。这也反向验证了我们选择色彩矫正前的黄、橙色作为新基准色的做法是可行的。

说通俗一点儿就是：选择用于生成色阶的基准色，一定要视觉舒适，要“漂亮”。举个不太恰当的例子，如果你的基准色可以直接拿来用在设计稿中，那么它大概率就是一个合格的基准色。

最后，我们来对比一下我们的可视化色板（CIELch）与设计系统色板（HSB）的色阶过渡效果。

灰度模拟效果。

三、分类色板 用于表示可视化场景中的不同类型的数据。

1. 竞品分析

我们参考知名可视化产品 ColorBrewer2 中的分类色板，通过分析其不同主题中的色彩规则来制定我们的分类色板。

主题一：三套不同亮度的色板，最多 8 种颜色，色相一致，适用于不同场景，同时也适用于不同品牌调性，如清新、沉稳、复古，思路值得借鉴； 主题二：两套不同亮度的色板，最多 9 种颜色，与主题一原理类似，后续扩展主题时可借鉴； 主题三：相邻颜色色相一致但相对亮度明暗交替，最多 12 种颜色，适用于多数据类型的场景，可以借鉴； 主题四：没搞懂原理及用途，先放之； 主题五：整体偏亮，最多 12 种颜色，相邻颜色色相不一致但相对亮度明暗交替，所以也适合多数据类型场景，思路可借鉴。 结合其他可视化产品，我们确定了接下来要做的事情的一些基本思路：

通过某种取色规则制定不同风格的分类色板，根据其效果选择一套适合我们品牌调性的； 分类色板要兼容多数据类型和少数据类型； 少数据类型时，相邻颜色色相不同且明暗交替； 多数据类型时，相邻颜色色相相同且明暗交替。 2. 生成色板

① 风格确定与基础色板

分类色板颜色主要考虑明暗交替变化（兼顾视障用户群体），其次考虑色彩美观度及颜色间的对比是否协调，如黄、橙色不脏，中性色不能太深或太浅等。我们一步步来，先把风格确定一下。

在全量色板上，我们以主题色所在的相对亮度阶梯为基准，通过明暗交替的方式排布取色标准点。

在进行明暗交替取色时，取更暗还是更明，主要取决于色彩美观度及颜色之间协调性。

再以相同的规则，将取色标准点整体向上向下偏移取出相对较亮和较暗两种风格的色板。

当然，如果你想要更亮或者更暗的风格，改变偏移量即可。

较亮。

较暗。

至此，我们得到了三套不同风格的基础分类色板，结合我们的产品调性，并在实际使用场景中进行验证，我们选择了相对沉稳、中立的版本。

灰度模式模拟效果。

色相相对亮度分布示意。

② 扩展色板

前面提到过，分类色板还需要兼容多数据类型场景。如我们现在的基础色板中有 9 种不同的颜色，如果一张图表需要用到 10 种颜色该如何解决？

常用的解决方案是将生成的基础色板颜色循环使用，如 Echarts，但这种方案有一个很大的弊端就是会出现首尾颜色相接无法正常区分的情况。

因此，我们决定基于基础色板按相邻颜色色相相同但明暗交替的规则衍生出一套扩展色板。

注意观察，基础色板中的蓝、红、青、粉色相对亮度值为 0.36，而扩展色板中却为 0.287。这是由于基础色板颜色需要满足明暗交替原则，而对应到扩展色板中时，相邻颜色已为明暗交替的同色相颜色，因此无需再将所有暗色都处理成明暗交替。

扩展色板使用效果。

③ 关于使用顺序

在风格确定步骤中，大家可能会有疑问：取色标准点怎么排布看懂了，但要得出分类色板，还差一个必要条件，那就是不同色阶的摆放顺序。

其实这个摆放顺序就是分类色板中的颜色使用顺序，这个顺序至关重要，为何？

首先，无需过多解释的就是：顺序不一样，意味着分类色板不一样，这是不同可视化产品之间差异化体现的重要途径，也就是我们前面提过的 体现整个可视化色彩体系贴近品牌调性的另一关键步骤。

其次，基于分类色板的特性我们可以明确的一点就是：这个顺序是固定的，不能随意更改，否则会破坏整个产品的视觉和谐度。你不能说环形图用顺序 1，玫瑰图用顺序 2，或者这个页面环形图用顺序 1，另一个页面环形图又用顺序 2。

最后，这个顺序会直接影响取色标准点的排布。顺序的不同，意味着原本应该取的暗色却变成了亮色，导致整个分类色板明暗变化产生差异。

看到这里大家可能会发现，这正是用来生成不同主题的好手段啊！

至于如何决定这个顺序，应该是仁者见仁智者见智并无对错的，这里只阐述一下我们的确立依据：

第一位是主题色绿，其次为蓝色。一方面考虑使用绿、蓝等偏中性的颜色可以保证大多数图表在页面中不会突兀，另一方面也能够兼容大多数 B 端产品的色彩基调。

其次为避免页面过于单调冷淡，所以加入暖色--黄色中和。

约定成俗的语义色就是红、黄、蓝、绿，所以考虑将红色也加进来。不过红、黄色相邻的话会使色板变得过暖，可以在其中间加入偏暖的中性色-紫色来使其过渡均匀。

此时整个色板呈现冷-暖变化趋势，紧接着需要回到冷趋势，同样为了避免发生冷暖突变，我们加入绝对中性色--灰色来中和，顺位往下走就只剩青色可选了。

接着就是暖色橙色，而粉色是个轻佻暧昧的颜色，使用时稍有不慎就会轻易打破整个页面的风格，所以放在最后，整个色板的顺序就定下来了。

此外，除了考虑颜色自身冷暖属性、语义属性外，还需要考虑识别度、视觉歧义、视障等因素。如从识别度角度考虑会使橙、黄色不相邻，绿、青色不相邻；如从视障角度考虑会使红、绿不相邻，粉、青色不相邻等。

最后，需要申明的观点就是：

可视化场景仅靠颜色是解决不了所有问题的，这其中需要设计师有能力将复杂的视觉问题和交互问题进行简化、合理化，如使用恰当的图表，使用纹理图形辅助识别，重组数据便于理解等。

图片源自：Matplotlib。

3. 色彩验证

① 视障验证

视觉障碍用户群体主要是色盲色弱用户，根据 Color Oracle 的统计，全世界人类中，绿色盲占比 5%，红绿色盲占比 2.5%，蓝黄色盲占比 0.5%。我们需要保证的就是尽可能让这部分群体也能够无障碍使用我们的产品，无障碍解读数据。

② 色差验证

步骤 2.3.2 中详细介绍了色差的验证方式以及验证目的，这里不赘述。

4. 应用

不在实际业务场景中验证颜色的行为个人认为就是在耍流氓。

① 使用规范

实际应用时发现，图表类型众多样式差异巨大，统一使用全量分类色板中的 9 个颜色并不合适。

如折线图，其图形（线段）视觉占比非常小，通常是 1～2px 粗细的线段。使用全量分类色板时，部分颜色（如橙色与黄色，红色与粉色，绿色与青色）虽能顺利辨识，但长时间查看会产生视觉疲劳导致辨识困难。

此外，在 Dashboard 或 BI 等场景中，通常会遇到数据量大，图表类型繁多，数据类型繁多的情况，此时的页面视觉效果将是灾难级的（使用 Echarts 主题定制工具模拟）。

因此，针对常规场景，遵循少即是多原则，我们去除了可能会无法辨识的颜色，将可用颜色数量限制为 6 个。特殊场景不做限制，如桑基图。

超出 6 种数据类型时，使用分类色板扩展色板，共 18 个。

超出 18 种数据类型时，使用强调色板。

② 应用效果

这里使用屏幕截图，所以效果会出现些许偏差。

四、顺序色板 通过亮度变化均匀的一组颜色表示具有顺序、梯度、频率等关系的数据。

1. 固定色板

顾名思义，固定色板即色阶数量有限的色板，用于数据阶梯较少的场景。可基于两个准则确定顺序色板：

色阶亮度层次拉开； 色阶使用顺序明确。 因此，从全量色板中选取色阶时需要注意，亮色区域间隔取色，保证数据阶梯之间能够清晰分辨。

基于此，确定我们的 7 阶固定色板。

最亮阶梯不满足对比度要求，用于图表中可能无法识别；最暗阶梯无法顺利辨别多个颜色之间的区别，也应避免使用。

而明确色阶使用顺序时，除要考虑遵循规律（方便开发实现）外，还要考虑页面和谐。通常的做法是从最亮阶梯开始往上取，当数据阶梯比较少时，其效果其实并不是我们想要的。

因此，我们改变一下这个顺序：从中间阶梯（主题色所在的阶梯）开始往下取，取完再依次往上取。

该方案仅供参考，目前尚未与研发同学达成共识验证其可行性。

最终，我们得到一个包含使用顺序的色板（从左往右依次对应数据阶梯数量）。

应用效果（以主题色为例）。

2. 动态色板

动态色板主要应对数据阶梯量大且不可预知的场景，因此需要借助算法根据数据分布阶梯自动生成对应的色阶。

设计师仅需提供最亮、中间及最暗的三个颜色即可。

因应用场景区别于固定色板的应用场景，所以动态色板会使用到全量色板中的最亮和最暗阶梯。当然你也可以选择使用与固定色板相对应的最亮、最暗阶梯，本质上设计师提供的三个颜色都是可以自定义的。

应用效果（以主题色为例）。

五、强调色板 与分类色板相对应，当分类数据较多时，或需对比数据时，通常会使用强调色板强调数据，弱化无关数据。

1. 取色规则

基于全量色板，以基准色作为强调色，向下扩展对应的弱化颜色。

注意，与分类基础色板不同的是，通常情况下的强调色不会同时出现，因此无需考虑明暗交替；其次，与分类扩展色板不同的是，因分类扩展色板需要考虑对比度，这里则需要尽量弱化，所以弱化色亮度要高于分类扩展色板。

2. 应用效果

六、发散色板 用来表示具有正负、高低、涨跌等关系的数据，拥有临界中间值，因此通常使用一对冷暖色来呈现。

1. 取色规则

首先，根据发散色板表达数据对立关系的特性，我们在选取对立冷暖色时，可以通过模拟视障效果来排除掉一些可能会出现问题的颜色。

我们选取了既可以表达冷暖关系又不会出现问题的三组颜色，以及表达中立的一组颜色。

其次，由于发散色板的使用场景与顺序色板类似，因此我们可以基于全量色板扩展出对应的固定色板。并使用 Chroma.js - chroma.mix 工具将对立相接的两个颜色进行混合，使其过渡更加均匀。

视障用户效果模拟，既不能混淆颜色，又不能改变原冷暖关系映射。

而为了应对数据阶梯量大且不可预知的场景，我们可以基于固定色板扩展出动态色板，与顺序色板动态色板原理类似，本质上是一组渐变色板，数据阶梯分布区间有多少，则可以在渐变色板上插对应数量的值。

此处再次体现感知均匀色彩空间的优势，渐变色过渡也是非常自然的。

2. 应用效果

可视化效果使用 Datawrapper 模拟。

3. 色相偏移

关于发散色板的生成，其实还有一种使用范围更广的色相偏移色板，相对无色相偏移色板来说过渡更加自然，更加符合人类对色温的认知。也就是常说的随着色阶的变化冷色会更冷，暖色会更暖。先来看下对比效果：

我们的方法是取三种不同暖色中的关键色与三组不同冷色中的关键色，使用 Chroma.js Color Palette Helper 进行混合，生成新的色相偏移色板。

但使用该方案并不能生成所有想要的色板，因为我们的一个大前提是所有颜色取至全量色板。如在生成红-蓝发散色板时发现，并没有合适的三组暖色供我们选择用来取出关键色，这就会导致生成的色板偏色严重无法使用。

所以，个人猜测，未来一方面应该向更科学合理的色相偏移方案探索，另一方面在该场景中不应将取色标准局限于全量色板。

由于我们的产品中很小概率会使用到发散色板，所以这里不做深入研究，也避免误导大家，就此打住。

七、语义色板 可视化场景中不受主题、风格影响的颜色，是约定成俗具有特定寓意的颜色，通常用于表示告警等级、正负关系等。

1. 取色规则

关于语义色板的取色来源颇受争议，一种方案是直接选取设计系统中的语义色，另一种是从可视化全量色板中选取并重新定义。其实两种方案各有优劣，关键在于如何客观评判。我们选择从可视化色板中选取并重新定义的理由如下：

设计系统色板的色彩空间与可视化有本质区别，无法做到统一； 设计系统中定义的语义色感官上饱和度及亮度与可视化色彩不统一，融入可视化场景中不和谐； 图表中的元素形状面积通常占比较大，与其他颜色的元素搭配时，使用可视化色彩会更协调； 设计系统中的语义色从使用场景、设计思路等角度考虑的话，会与可视化场景有细微差别，解耦设计更合理一些。 注意灰色语义色取至中性色板，后面会解释原因。

2. 应用效果

八、中性色板 中性色板用于可视化图表中的标题、轴线、文字等场景，与设计系统中性色板保持一致，这里不做特殊定制。上文提到过，为何中性色板区别于语义色板，可以与设计系统共用呢？

首先中性色板本质上都是中性色，应该区别于“有色彩”的颜色。那么，从其使用场景上来看，中性色板可以不受系统限制，独立于设计系统或者可视化组件库以外，成为一套公共的色板； 其次，从使用者角度来考虑，中性色板可以说是使用范围最广的，这就形成了肌肉记忆，不再适合重新开辟一套来给大家造成记忆负担； 再其次，从页面效果来看，理想状态还是所有中性色保持一致，不能说承载图表的卡片标题是一个颜色，而同级别非图表卡片标题又是另一个颜色； 最后，从底层色彩空间来看，中性色是不受色彩空间限制的，可以通用于各种不同色彩空间搭建的系统中是必然的。

九、总结 总之就一句话，关于颜色的探索是永无止境的，随着探索的不断深入，越发觉得距离踏入门槛是越来越远了。

本文分享个人搭建青云 QingCloud 可视化色彩体系过程中的一些经验。（阅读此文需要一定的色彩空间知识作为基础，否则有些难啃）基础科普：如何4步建立系统级色彩体系？来看京东高手的方法！

本文分享个人搭建青云 QingCloud 可视化 色彩体系 过程中的一些经验。（阅读此文需要一定的色彩空间知识作为基础，否则有些难啃）

基础科普：

如何4步建立系统级色彩体系？来看京东高手的方法！ 色彩体系的推导其实有很多文章有详细的介绍了，这一篇主要粗浅的梳理了整体流程经验，补充一下技术方法与色彩模型的差异。

阅读文章 >

一、前言 1. 背景

目前平台上使用了三套组件库 A、B、C，A 是最原始的组件库，基于此扩展了 B 组件库，并对颜色进行了改进，C 是全新的组件库，引用了 Token 及其他新的前端技术栈。三套组件库独立存在，应用在庞大的云平台各个业务产品中，发展趋势为使用 C 组件库开发日后新的业务，并逐步替换老的业务。

关于颜色，B 组件库采用 HSB 色彩空间调色并进行人工调整，C 组件库沿用 B 组件库的色板并对部分颜色进行了优化。

关于可视化组件，平台使用第三方开源图表库 Echarts 进行简单定制化。

目前的需求是基于 Echarts 系统化定制出一套图表类型较全面、交互较统一、使用规范较明确的可视化组件库。因此，确定一套可视化颜色系统成为当务之急，经过简单的调研得出两套解决方案：

方案一：沿用组件库 C 的颜色； 方案二：基于适用于可视化场景的色彩空间确定一套全新的颜色。 不难判断的是，采用方案一，要面临的问题就是：

色彩空间落后，不适用于可视化场景； 大量人工调整，无法满足日后自动化交付场景所需； 相关算法及推导过程丢失，设计侧无法进行科学化、可持续化迭代。 且在调研过程中我们发现，可视化色彩与设计系统色彩并无必要的理由进行捆绑：

一方面，可视化场景对色彩的要求要远高于设计系统组件库，因其主要通过颜色来识别数据差异，所以，对颜色的亮度、对比度、色差、和谐度等要求非常高； 另一方面，可视化组件库的适用产品类型通常是多种多样的，夸张点讲就是任何类型的产品中都可能会用到可视化。这一点就需要可视化组件库拥有很强的风格兼容性，这就导致了其颜色必须兼容性强，并非随便拿一套设计系统色彩过来就能满足的； 设计系统中的颜色使用场景与可视化中的颜色使用场景不同，这就导致很多已经成型的设计系统色彩从设计之初的（设计目标）就不适合拿来做 可视化设计 ； 再向底层去挖掘，很多设计系统的色彩空间不适合可视化场景，这会导致相关扩展色板的推导流程甚至主题演变流程变得异常困难。 最终，我们采用了方案二，也就有了接下来要发生的事情。但在开始之前，我们需要想清楚几个问题。

2. 理想的可视化色彩特点是什么？

看待这个问题，其实我们要搞清楚的是可视化场景对颜色的要求是什么？

① 保证同色相或不同色相之间的辨识度与色差是基本要求

可以毫不夸张的说，可视化系统就是一个色彩系统，无论多么复杂花样繁多的图表，都要依靠颜色去表达。而在众多表达手法中，颜色与颜色之间的对比是最常使用的。

② 颜色所传达出来的感觉要准确

众所周知，颜色不仅仅能表达人类的情绪，如热闹、喜庆、冷淡、沉稳。还能表达事物的特征，如温度冷暖、海拔高低、数据升降。

③ 充分考虑色盲色弱等视障群体的使用体验

我们在产品设计过程中经常会提到无障碍设计，也通常会在设计系统中对颜色对比度、字体大小等做一些验证，也会充分考虑用户设备情况及产品使用环境做一些针对性设计。在可视化设计中，这些验证是相通的。

④ 颜色的生成、演变与应用是动态的

前面我们提到过，无论是产品迭代还是纯视觉升级亦或产品交付自动化，从技术架构到颜色算法在设计之初都要充分考虑扩展性。以至于在可视化设计中，色环的确定、色板的生成、色彩的搭配、色序的应用等都要保证有理有据且灵活可变，充分兼容复杂极端场景。

注意，颜色算法是指通过大量实践、总结和优化，可以用来相对科学的批量的解决符合一定规律或映射关系的场景问题的一种途径，其产出相对理性过程也相对高效，是做后续颜色优化工作的基础，可以大大降低人为干预的几率，而非一成不变的去应用。

⑤ 颜色搭配要符合产品调性，是品牌的延续

可视化的应用场景非常广泛，从国家生产总值到个人收支明细，大到政务系统小到记账 App，都有其载体风格调性，如中立、活泼、科技等，均不能脱离于“品牌”而设计。

⑥ 保证颜色的美观性

回到设计本身，也是设计本质---美，还是要保证的。

3. 传统的色彩空间弊端是什么？

我们先来简单看一下使用传统的色彩空间是如何配色的。

此处受 @lemonoO 的启发

最初，互联网上的产品形态比较简单，对颜色的定义仅仅局限于红、黄、蓝、绿四个语义色上，用来模拟表达成功、失败等情绪。

在此之上，手动扩展几个相对深与浅的颜色用于如按钮 Hover、Active 状态。

颜色之间依靠一些配色工具在色盘上根据对比色、互补色等原理进行搭配。

随着互联网的飞速发展，互联网产品的形态逐渐复杂，组件也日趋完善，人们不断探索能够满足更多使用场景的配色方案，定义相对完善的色彩体系。于是，Tint&Shade 扩展色阶的方案就出现了。

该方案通过定义基准色后分别向深浅两个方向叠加不同不透明度的黑色与白色来生成色阶，达到扩展基础色板的目的，典型的工具如 Tint and Shade Generator。

后来人们发现，这种方案虽然简单粗暴，但依靠叠加不同量黑色与白色生成的色阶存在一些问题或不满足使用场景，如首尾丢色严重，无法通过色相偏移的方式制造冷暖效果等。

于是，基于更符合人类认知的色彩空间如 HSB、HSL 生成色阶法就诞生了，并成为至今使用范围最广的方案。

以 HSL 为例，该方案通过将颜色定义为符合人类认知的三个变量：色相、饱和度、亮度，分别进行控制并灵活调配，如固定饱和度与亮度，在色环上通过改变色相生成基础色。

或固定色相与饱和度，通过调整亮度生成色阶。

就如同人类科技发展史一样，人们总是在发现问题解决问题和改进方案。如下图所示，这种符合人类认知习惯的色彩空间搭配出来的颜色，其数值亮度并不是与人眼感知亮度相通的，这注定需要人为介入来改变局面。

以至于依靠这种方法生成的色彩阶梯肉眼可见的过渡不均匀，且同阶梯不同颜色间差异过大。

于是乎，这里调一下亮度，那里调一下饱和度，经过不懈的努力花费了巨大的成本终于得到了满意的效果，然后发现整个色板参数完全失控了。

推导经验无法复用，色板升级只能肉眼调，主题定制纯靠研发批量替换......

至此，人们发现，传统的色彩空间配色方案弊端主要体现在无法科学准确的表达颜色亮度上，也终于意识到，计算机对颜色的识别和处理是线性和对称的，而人眼对色彩的感知是非线性和不均匀的。

简单的例子就是红色比蓝色亮（刺眼），绿色比红色亮（刺眼）。

所以，这些基于 RGB 色彩空间扩展出来的配色工具或空间（HSB、HSL 等）终究是要被取代的，这也正式促使了 感知均匀色彩空间 的诞生。

由 CIE 组织（国际照明委员会）于 1976 年提出，理论上可以覆盖人眼所能识别的所有色彩，其颜色总量远大于传统色彩空间，最大的特性就是数值变化均匀则颜色变化均匀，亮度亦如此，人们终于可以客观的依据数值来判定颜色了。虽并非完全意义上的感知均匀，但相比传统色彩空间已是质的飞跃。

完整介绍可参考《基础概念》篇，这里不做赘述。

4. 为何选取感知均匀的色彩空间？

很多可视化产品都在推荐使用人眼感知均匀的色彩空间来搭建可视化色彩系统，不断强调感知亮度均匀，但并没有告诉大家为什么。

首先，这里需要强调的是，我们所追求的感知亮度均匀更贴切的说法应该是追求亮度的准确表达。

表达是否准确就像建房子一样，砖是墙的基础，墙美不美观稳不稳定，取决于每一块砖的大小是否标准，而衡量这个标准的前提是砖的长宽高都是可被衡量的。与之对应的，色板是否“美观与稳定”，取决于每一个颜色是否标准，而衡量这个标准的前提是颜色的每个指标都是可被衡量的。

图片源自网络，侵权请联系

基于这个前提，我们就可以顺利地构建出一个可被衡量且变化均匀的全量色板。

其次，区别于设计系统的是，可视化场景需要基于全量色板按照特定的规则扩展出不同类型的色板，如分类色板、发散色板等，而亮度又是这些特定规则中的重要指标。

因此，一个可被衡量且感知变化均匀的全量色板何尝不是可视化设计的最佳选择呢？

再其次，我们反向思考一下，如果将感知不均匀的色彩空间应用在可视化场景里会发生什么呢？

下面是一个描述美国各地雨水蒸发量的案例，可以非常明显的观察到一条分界线将整张地图一分为二，这很容易让人在解读数据时发生误判---分界线两侧数值发生了巨大的变化。

作者：Robert Kosara，查看 原文 。

而通过观察其图例上的数值后发现并非如此，分界线两侧的颜色所代表的数值区间差均为 0.09，与其他颜色并无差异。

这正是由于分界线两侧的颜色感知亮度有较大差异，以及不同色调之间过渡不均匀所导致的。

通过这个案例我们可以看出来，很多对数据精度要求高的场景（如气象预测），在分析数据时，需要遵循一个很重要的原则就是保证颜色的客观性，降低颜色对数据分析结果的影响，降低解读数据时数值变化量误差（对应色彩变化量）。

最后，总结一下，使用感知均匀的色彩空间可以让我们收获什么？

它可以让 设计师 真正拥有明辨色彩是非的能力。在看似复杂的全量色板上客观、有依据的挑选合适的颜色（通过数值判断颜色是否合适而非阶梯判断），用以表达明暗、冷暖关系（如发散色板的构建），构建贴近工程化理念的配色方案（如动态顺序色板的构建）等。

5. 如何选取感知均匀的色彩空间？

在众多感知均匀的色彩空间中，选取适合我们的色彩空间需要满足以下几个基本条件：

易于操作，最好是有成熟的工具或算法可以用来深入了解对比； 颜色变量易于理解，最好能够像 HSL 等空间一样符合人类认知； 可生成自定义数量的阶梯，且每个阶梯的亮度可以自由把控。 ① CIE 系列

基于这些基本条件，我们首先排除了 CIELab（CIELuv 与之类似），其色彩空间由 L（感知亮度）、a（红绿通道）、b（蓝黄通道） 三个变量构成。L 变量是相对可控的，但 a、b 变量不符合人类的认知，类似于 RGB 调色板一样，不同的颜色是通过改变 a、b 变量中的红绿与蓝黄的量而得出的。

但也不排除使用该色彩空间配色的可能，观赏一下。

而 CIELch 是 CIELab 的极坐标转换，通过易于理解的 L（感知亮度）、C（色度，可简单理解为饱和度）、H（色相）三个变量来形容颜色。同时，生态也比较完善，有多种工具可以不同程度的帮助我们生成色阶，作为保留方案。

② OK 系列

OKLab、OKLch 针对 CIE 系列空间做了进一步优化，纠正了色相偏移（阿布尼效应）与色度对感知亮度的影响（亥姆霍兹-科尔劳施效应）。

但这类色彩空间目前还处于早期阶段，生态不完善，兼容的场景也很少，仅有的工具也只能作为调色器（如这个工具 OKLch-Picker）使用。此外，在该色彩空间内，固定色相与色度的同时可覆盖的亮度区间要小于 CIE 系列色彩空间，超出限定区间的颜色又无法在 sRGB 色域内甚至任何设备上正常显示，用于生成色阶非常局限。所以，放弃之。

无论使用任何色彩空间进行调色，我们最终都要保证所有颜色均能在 sRGB 色域内正常显示，这是底线。比如你使用了 P3 色域中的颜色，则会有部分用户的设备无法显示并自动取 sRGB 色域中相似的颜色来呈现，从而影响你的设计交付效果。

③ HCT

HCT 色彩空间是谷歌在 Material Design 3.0 中推出的新方案，基于 CAM16 色彩空间与 CIELab 色彩空间进行了优化，通过 H（色相）、C（色度）、T（光度，源自 CIELab 中的 L） 三个变量描述颜色。

官方提供了在线配色工具，但使用该工具生成的黄色显脏，可用色阶少，且无法自定义色阶，许多颜色在色阶两端有丢色偏色的现象。

但好在开源，我们可以借助其算法通过在代码中自定义 T 的数量及数值模拟我们想要的效果。单看生成的色阶效果其实还不错，也能够满足基本的使用需求。

代码源自：Jony，查看 原文 。

import { argbFromHex, TonalPalette } from "@material/material-color-utilities"; // 定义 tone 梯度 const TONE_ARR = [0, 5, 10, 20, 30, 40, 50, 60, 70, 80, 90, 94, 97, 100]; const createTonalPalette = (hex) => { // 将 hex 格式颜色转化为 argb 格式 const argb = argbFromHex(hex); // 创建 palette const palette = TonalPalette.fromInt(argb); // 在 palette 上取一组 tone 梯度对应的颜色数组 const colorArr = TONE_ARR.map((t) => hexFromArgb(palette.tone(t))); return colorArr; };{{{pre>

其感知亮度变化也是相对均匀的（PS 灰度模式效果）。

大家可能在很多教程里都看到过使用灰度模式（用词精确，非黑白模式）来模拟感知亮度变化。首先需要申明的是：在 PS 里，有一个图层叠加模式叫“明度”，在 Figma 里叫 Luminosity，总之使用这种方式来模拟的效果都是不准确的，推荐使用 PS 中的灰度模式来模拟，或者直接打印出来查看效果。

那为何使用灰度模式来模拟呢？（这个问题并未找到科学靠谱的答案，属于猜测）

相信大家在初次接触美术时都学过素描，通过简单的黑白灰来表达一个物体的光影、层次关系，而色彩会有很明显的情绪传达。所以，要想表达人眼对色彩亮度的感觉，是不是去掉“色彩”会相对客观一些呢？

基于该结论，我们还会发现这种方式除了可以用来模拟感知亮度变化以外，还可以用来体现明暗关系（如视障用户无法顺利通过颜色辨别图形时可以依靠明暗对比来辨别），以及用来还原打印效果（打印数据图表分析数据）等。

但有一个非常让人难受的缺陷：默认情况下 Key Color（或主题色）很可能会不存在于生成的色阶中，这就意味着需要不断去尝试取 Key Color 相邻的色值让其存在于色阶中，或者通过定义无限多的 T 数量及数值让其显露出来，这显然不符合我们“易于操作”的要求，放弃之。

④ 结论

其他调研细节就不在这里啰嗦了，总之，我们最终选择了 CIELch 色彩空间。

至此，需要铺垫的内容也就告一段落了，接下来我们通过实战来看一下如何推导一套可视化色彩体系。

二、全量色板 推导整个色彩体系之前，我们已知的条件就是一个主题色。基于青云 QingCloud 品牌 VI 中定义的主题色，我们将其进行一个简单的色彩演变，降低饱和度的同时微调亮度使其更加适用于互联网产品但不脱离我们中立沉稳的品牌调性。

这里需要注意，在做色彩空间转换时，尽量保证精确度，从而提升后期颜色推导的精确度。

1. 基础 10 色 ① 24 基色

基于 RGB 色彩空间，我们首先需要绘制一个标准色盘。

通过正色取值法，以正红色为基准，间隔 15° 取色，中间会覆盖正蓝（210°）、正青（180°）等颜色，得到一个标准的 24 基色。当然，这些颜色并不能直接拿来使用。

与正色取值法对应的是主色取值法，以主题色色相为基准间隔 15° 取色，得到一个色相偏移的 24 基色。但经过尝试，我们发现，该方案由于主题色色相的不确定性（经验复用时会发生），很有可能导致取出来的颜色“不当不正”，做颜色矫正的成本较高。

② 8 基色

基于生成的 24 基色，我们选取人眼最容易识别且符合人类认知的 8 个基准色：红、橙、黄、绿、青、蓝、紫、粉。

这里取色的过程可以根据自己产品的调性对部分颜色特殊处理，如我们取的粉色就相对沉稳一些。

③ 色相矫正

虽然现在生成了 8 个基准色，但仍然不能直接使用。此时，我们需要结合一些条件对色相进行偏移。

首先是保证视觉舒适度，如黄色、青色过于刺眼； 其次是基准色之间要肉眼可区分； 最后是生成的梯度色板之间也要肉眼可区分（如我们的主题色与绿、青基准色经过感知均匀的色彩空间转换后生成的梯度色板十分接近）。 以上矫正过程需要结合后续的推导结果不断循环往复来回调整，直至符合要求。

④ 色彩矫正

前面我们花了很多篇幅介绍色彩空间，在这一步才真正得以体现。我们先将颜色转换至感知均匀的色彩空间，方便后续对色彩进行处理。

转换至感知均匀的色彩空间后，我们根据主题色的感知亮度将其他颜色也设为一致，这是体现整个可视化色彩体系贴近品牌调性的关键步骤，因为我们会拿这些基色去生成全量色板。

大家可能发现我们在这个过程中选用了 HCT 色彩空间进行转换（不是打脸哦），因其调色器工具能自动根据感知亮度调整色度致使各个颜色都保持和谐。当然，你也可以使用其他感知均匀的色彩空间来做转换，差异不大。

此外，大家可能还会有疑问，黄色和橙色怎么像?一样？为什么还放在这里？因为在真实使用场景中，色板里的颜色并不一定都能被使用到，这是其一。其二，颜色长的丑并不能否定它作为我们生成色阶的基准色。（后面的推导流程推翻了这个结论，但仍不能否定它存在于色板中）

三步变化效果。

⑤ 生成中性基色

常用的中性色大家都知道有中性中性色和冷调中性色，结合品牌调性我们选用了冷调中性色。基于蓝色我们可以通过降低色度的方式扩展出中性基色。

这里的中性色比较特殊，仅适用于图表图形中用以中和色调，而非用于文字、填充、轴线等场景的全局中性色。

⑥ 相对亮度验证

通过上面的步骤，我们得到了感知均匀的 10 个基色，我们使用 Chroma.js 中的相对亮度计算工具验证一下，方便我们基于这些基准色扩展色阶。

这里引入了新的概念“相对亮度”，可以查看 W3C 相对亮度 的计算公式和 维基百科 对其的定义。大概可以理解为感知亮度的另一种表达，任意两个颜色的相对亮度值一致说明其感知亮度（HCT 中的 T 或 CIELab 中的 L）值也是一致的。白色为 1，黑色为 0。

当然这里我们其实是无需验证的，因为在色彩矫正步骤 2.1.4 里已经基于 HCT 色彩空间将 T 设为一致了，那其相对亮度值也是一致的。我们验证的目的是为了配合后文会提到的 Chroma.js 工具及相对亮度等差数列生成色阶。

2. 完整色阶 首先需要判断一下需要多少个阶梯，通常情况下的阶梯有 7、9、11、13 几种，大家根据自己的需要选择。我们选择了 13 阶梯，一方面可以使色阶过渡细腻一些，另一方面也可以让取色范围更广一些。

其次，谈起色阶就不得不说一下插值。插值的目的是为了获取一个有规律的亮度变化曲线，使色阶过渡均匀。通常的做法就是固定首尾两个点，通过一些算法或工具生成对应的贝塞尔曲线，也可以使用简单的等差数列来完成。

而感知均匀的色彩空间有一个很大的特征就是：它的色彩空间是三维且不规则的，固定 L、C、H 三个变量并从中“切一片”下来放进二维平面中观察，你会发现它的形状是不规则的。固定其中任意两个变量改变第三个变量时，都会影响这个二维平面的形状，三者互相影响。

这里有点儿考验大家的立体几何想象能力。

这就意味着，不管你的亮度曲线是等差数列还是各种高大上的贝塞尔曲线，当你把曲线套进色彩空间中 360° 旋转切换色相生成色阶时，曲线中的某些点说不定会跑出整个三维色彩空间。这就需要联动色度及色相一起做各种矫正工作，对设计师来说学习成本和操作成本是巨大的。

我们想简化整个流程。前面我们定义好了 10 个基色，也得知其相对亮度值均为 0.287 左右，这就相当于定义好了整个色阶中的“中间”阶梯，我们按等差数列向上向下分别取不同数量的阶梯即可，之后借助现成的算法或工具帮助我们去做矫正工作。

为什么基准色阶往右的阶梯要多一些？

主要原因在于基准色阶的相对亮度较低，自然可以往亮处扩展的多一些。那为什么我们不在这个基础上间隔取样，使左右两侧的色阶数量相等看起来对称舒服一些呢？

这是由于我们在扩展分类色板、顺序色板等时发现，经常需要按不同规律来间隔取样，这样划分会使我们的可选择余地多一些，不至于陷入亮色不够用，暗色又用不到的尴尬境地。

通过调研了十几个工具后发现 Chroma.js 正好满足我们的需要。我们只需要选择合适的色彩空间，定义好 Key Color（基准色），定义好相对亮度等差数列即可顺利生成色阶。

受 @少年游 的 文章 启发，这里插播一个知识点：韦伯-费希纳定律，可以解释我们为什么会使用等差数列来设计色阶。

定律现象：人眼对亮色区域的颜色变化敏感度要高于暗色区域。

按照传统的 HSL 色彩空间生成色阶时，需要在亮色区域将阶梯层级设计的细腻一些，也就是亮度变化度（非 L 值的直观体现，需要计算）要小于暗色区域，防止使用亮色区域相邻色阶时造成亮度变化过大的错觉。如图左，浅色按钮之间的变化度为 2.6 倍，而暗色按钮之间的变化度为 1.1 倍。

而我们使用的感知均匀色彩空间就很好的避免了这个问题，只要保证颜色之间相对亮度值的变化量是一样的（等差），那就说明无论是浅色按钮还是暗色按钮他们之间的变化度也是一样的，如图右。

① 基础色阶

基于 Chroma.js，我们生成了大部分颜色的色阶。

② 特殊色阶

而当我们按照同样的规则去生成黄色与橙色色阶时，我们发现整个色阶过于偏“暗”导致可用阶梯非常少。

于是，经过不断地尝试后发现：通过提升黄色与橙色的基准色感知亮度与色度则可以提升整个色阶的亮度与色度，并保持变化均匀。因此，针对黄色与橙色，我们选择基准色色彩矫正前的颜色（2.1.3 步骤中所得出的颜色）做为新的基准色生成色阶。

这个过程由于色彩空间、算法等缺陷会导致部分颜色产生差异，但属于肉眼无法辨别的差异，还可接受。

③ 色彩矫正

现在，我们拥有一套完整的色板了。但仔细观察后发现，个别颜色有些不太符合我们的品牌调性，感知亮度或色度有些过了。

我们手动压一压，微调得到最终的全量色板。（绿色因与主题色过于接近，去之）

这些微调其实属于可以不调的程度，并不会在实际生产过程中影响自动化交付效果。

3. 色彩验证 生成全量色板后不意味着推导工作可以结束了，好的色板是要能经得住考验的，同时也是循环往复来回调整基色的必要过程。

① 相对亮度

验证全量色板中的每层阶梯颜色是否符合相对亮度标准，这也是检验色阶是否过渡均匀的重要手段。

灰度模拟效果还不错，使用 PS 中的灰度模式模拟。

亮度曲线分布一致，使用工具 Huetone 模拟。

② 色差验证

在感知均匀的色彩空间内，验证任意两个基准色之间的色差，其目的是为了保障视力正常的用户能够顺利分辨出两个颜色的不同。我们基于 CIE2000 标准进行验证，Delta E ≥

18 即满足，可用工具 Color Contrast 进行计算。

“18”这个值的说服力有待考证，暂以其为标准。

CIE2000 较 CIE1976（目前使用范围较广） 在算法上进行了优化，描述色差更加准确。

可以发现，部分颜色间的色差是不满足标准的（红字加粗部分）。

首先我们这里校验的基准色都是可以直接拿来用在设计稿中或者用于后期推导其他色板的，所以校验目标颜色的亮度阶梯是固定的，如黄色取亮度 0.6 阶梯，橙色取 0.44 阶梯。

所以，留给我们的选择就是改变色相与色度，通过微调的方式重新生成色板，使被校验的基准色达到色差要求。

经过多次尝试，我们发现：如橙色，满足色差要求的同时整个色阶会偏向红色；而黄色，满足色差要求的同时整合色阶需要偏向绿色，结果会很脏，否则会更加偏向橙色不满足要求。

最主要的原因是：感知均匀的色彩空间并不像传统色彩空间那样可以肆无忌惮的调出想要的颜色，加上工具和算法的限制会导致微调并不起作用，直观的体现就是换了其他相近的颜色但生成的色阶结果还是一样的。

这个时候我们就需要做出取舍了，我们最终选择了保视觉效果而非色差，或许我们后续还有机会回头重新看待这个缺陷。

无法满足 CIE2000 标准的颜色，也尽量保证满足 CIE1976 标准，推荐使用工具 iWantHue 计算。

③ 色度分布

观察所有颜色的色度分布趋势，我们会发现用来生成色阶的基准色刚好处于色度曲线顶点位置处，这是为何？

猜测：根据色度分布曲线我们可以大致推测出 Chroma.js 算法的关键点在于基准色，你输入的基准色的色度会是最高的，然后依次向两侧色阶降低。

那么，基于该结论，我们就可以知道为什么在步骤 2.2.2 中生成的黄、橙色阶是不理想的了。因为你把整个色阶里的最高色度点定的太低了，以至于使整个色阶偏“暗”。这也反向验证了我们选择色彩矫正前的黄、橙色作为新基准色的做法是可行的。

说通俗一点儿就是：选择用于生成色阶的基准色，一定要视觉舒适，要“漂亮”。举个不太恰当的例子，如果你的基准色可以直接拿来用在设计稿中，那么它大概率就是一个合格的基准色。

最后，我们来对比一下我们的可视化色板（CIELch）与设计系统色板（HSB）的色阶过渡效果。

灰度模拟效果。

三、分类色板 用于表示可视化场景中的不同类型的数据。

1. 竞品分析

我们参考知名可视化产品 ColorBrewer2 中的分类色板，通过分析其不同主题中的色彩规则来制定我们的分类色板。

主题一：三套不同亮度的色板，最多 8 种颜色，色相一致，适用于不同场景，同时也适用于不同品牌调性，如清新、沉稳、复古，思路值得借鉴； 主题二：两套不同亮度的色板，最多 9 种颜色，与主题一原理类似，后续扩展主题时可借鉴； 主题三：相邻颜色色相一致但相对亮度明暗交替，最多 12 种颜色，适用于多数据类型的场景，可以借鉴； 主题四：没搞懂原理及用途，先放之； 主题五：整体偏亮，最多 12 种颜色，相邻颜色色相不一致但相对亮度明暗交替，所以也适合多数据类型场景，思路可借鉴。 结合其他可视化产品，我们确定了接下来要做的事情的一些基本思路：

通过某种取色规则制定不同风格的分类色板，根据其效果选择一套适合我们品牌调性的； 分类色板要兼容多数据类型和少数据类型； 少数据类型时，相邻颜色色相不同且明暗交替； 多数据类型时，相邻颜色色相相同且明暗交替。 2. 生成色板

① 风格确定与基础色板

分类色板颜色主要考虑明暗交替变化（兼顾视障用户群体），其次考虑色彩美观度及颜色间的对比是否协调，如黄、橙色不脏，中性色不能太深或太浅等。我们一步步来，先把风格确定一下。

在全量色板上，我们以主题色所在的相对亮度阶梯为基准，通过明暗交替的方式排布取色标准点。

在进行明暗交替取色时，取更暗还是更明，主要取决于色彩美观度及颜色之间协调性。

再以相同的规则，将取色标准点整体向上向下偏移取出相对较亮和较暗两种风格的色板。

当然，如果你想要更亮或者更暗的风格，改变偏移量即可。

较亮。

较暗。

至此，我们得到了三套不同风格的基础分类色板，结合我们的产品调性，并在实际使用场景中进行验证，我们选择了相对沉稳、中立的版本。

灰度模式模拟效果。

色相相对亮度分布示意。

② 扩展色板

前面提到过，分类色板还需要兼容多数据类型场景。如我们现在的基础色板中有 9 种不同的颜色，如果一张图表需要用到 10 种颜色该如何解决？

常用的解决方案是将生成的基础色板颜色循环使用，如 Echarts，但这种方案有一个很大的弊端就是会出现首尾颜色相接无法正常区分的情况。

因此，我们决定基于基础色板按相邻颜色色相相同但明暗交替的规则衍生出一套扩展色板。

注意观察，基础色板中的蓝、红、青、粉色相对亮度值为 0.36，而扩展色板中却为 0.287。这是由于基础色板颜色需要满足明暗交替原则，而对应到扩展色板中时，相邻颜色已为明暗交替的同色相颜色，因此无需再将所有暗色都处理成明暗交替。

扩展色板使用效果。

③ 关于使用顺序

在风格确定步骤中，大家可能会有疑问：取色标准点怎么排布看懂了，但要得出分类色板，还差一个必要条件，那就是不同色阶的摆放顺序。

其实这个摆放顺序就是分类色板中的颜色使用顺序，这个顺序至关重要，为何？

首先，无需过多解释的就是：顺序不一样，意味着分类色板不一样，这是不同可视化产品之间差异化体现的重要途径，也就是我们前面提过的 体现整个可视化色彩体系贴近品牌调性的另一关键步骤。

其次，基于分类色板的特性我们可以明确的一点就是：这个顺序是固定的，不能随意更改，否则会破坏整个产品的视觉和谐度。你不能说环形图用顺序 1，玫瑰图用顺序 2，或者这个页面环形图用顺序 1，另一个页面环形图又用顺序 2。

最后，这个顺序会直接影响取色标准点的排布。顺序的不同，意味着原本应该取的暗色却变成了亮色，导致整个分类色板明暗变化产生差异。

看到这里大家可能会发现，这正是用来生成不同主题的好手段啊！

至于如何决定这个顺序，应该是仁者见仁智者见智并无对错的，这里只阐述一下我们的确立依据：

第一位是主题色绿，其次为蓝色。一方面考虑使用绿、蓝等偏中性的颜色可以保证大多数图表在页面中不会突兀，另一方面也能够兼容大多数 B 端产品的色彩基调。

其次为避免页面过于单调冷淡，所以加入暖色--黄色中和。

约定成俗的语义色就是红、黄、蓝、绿，所以考虑将红色也加进来。不过红、黄色相邻的话会使色板变得过暖，可以在其中间加入偏暖的中性色-紫色来使其过渡均匀。

此时整个色板呈现冷-暖变化趋势，紧接着需要回到冷趋势，同样为了避免发生冷暖突变，我们加入绝对中性色--灰色来中和，顺位往下走就只剩青色可选了。

接着就是暖色橙色，而粉色是个轻佻暧昧的颜色，使用时稍有不慎就会轻易打破整个页面的风格，所以放在最后，整个色板的顺序就定下来了。

此外，除了考虑颜色自身冷暖属性、语义属性外，还需要考虑识别度、视觉歧义、视障等因素。如从识别度角度考虑会使橙、黄色不相邻，绿、青色不相邻；如从视障角度考虑会使红、绿不相邻，粉、青色不相邻等。

最后，需要申明的观点就是：

可视化场景仅靠颜色是解决不了所有问题的，这其中需要设计师有能力将复杂的视觉问题和交互问题进行简化、合理化，如使用恰当的图表，使用纹理图形辅助识别，重组数据便于理解等。

图片源自：Matplotlib。

3. 色彩验证

① 视障验证

视觉障碍用户群体主要是色盲色弱用户，根据 Color Oracle 的统计，全世界人类中，绿色盲占比 5%，红绿色盲占比 2.5%，蓝黄色盲占比 0.5%。我们需要保证的就是尽可能让这部分群体也能够无障碍使用我们的产品，无障碍解读数据。

② 色差验证

步骤 2.3.2 中详细介绍了色差的验证方式以及验证目的，这里不赘述。

4. 应用

不在实际业务场景中验证颜色的行为个人认为就是在耍流氓。

① 使用规范

实际应用时发现，图表类型众多样式差异巨大，统一使用全量分类色板中的 9 个颜色并不合适。

如折线图，其图形（线段）视觉占比非常小，通常是 1～2px 粗细的线段。使用全量分类色板时，部分颜色（如橙色与黄色，红色与粉色，绿色与青色）虽能顺利辨识，但长时间查看会产生视觉疲劳导致辨识困难。

此外，在 Dashboard 或 BI 等场景中，通常会遇到数据量大，图表类型繁多，数据类型繁多的情况，此时的页面视觉效果将是灾难级的（使用 Echarts 主题定制工具模拟）。

因此，针对常规场景，遵循少即是多原则，我们去除了可能会无法辨识的颜色，将可用颜色数量限制为 6 个。特殊场景不做限制，如桑基图。

超出 6 种数据类型时，使用分类色板扩展色板，共 18 个。

超出 18 种数据类型时，使用强调色板。

② 应用效果

这里使用屏幕截图，所以效果会出现些许偏差。

四、顺序色板 通过亮度变化均匀的一组颜色表示具有顺序、梯度、频率等关系的数据。

1. 固定色板

顾名思义，固定色板即色阶数量有限的色板，用于数据阶梯较少的场景。可基于两个准则确定顺序色板：

色阶亮度层次拉开； 色阶使用顺序明确。 因此，从全量色板中选取色阶时需要注意，亮色区域间隔取色，保证数据阶梯之间能够清晰分辨。

基于此，确定我们的 7 阶固定色板。

最亮阶梯不满足对比度要求，用于图表中可能无法识别；最暗阶梯无法顺利辨别多个颜色之间的区别，也应避免使用。

而明确色阶使用顺序时，除要考虑遵循规律（方便开发实现）外，还要考虑页面和谐。通常的做法是从最亮阶梯开始往上取，当数据阶梯比较少时，其效果其实并不是我们想要的。

因此，我们改变一下这个顺序：从中间阶梯（主题色所在的阶梯）开始往下取，取完再依次往上取。

该方案仅供参考，目前尚未与研发同学达成共识验证其可行性。

最终，我们得到一个包含使用顺序的色板（从左往右依次对应数据阶梯数量）。

应用效果（以主题色为例）。

2. 动态色板

动态色板主要应对数据阶梯量大且不可预知的场景，因此需要借助算法根据数据分布阶梯自动生成对应的色阶。

设计师仅需提供最亮、中间及最暗的三个颜色即可。

因应用场景区别于固定色板的应用场景，所以动态色板会使用到全量色板中的最亮和最暗阶梯。当然你也可以选择使用与固定色板相对应的最亮、最暗阶梯，本质上设计师提供的三个颜色都是可以自定义的。

应用效果（以主题色为例）。

五、强调色板 与分类色板相对应，当分类数据较多时，或需对比数据时，通常会使用强调色板强调数据，弱化无关数据。

1. 取色规则

基于全量色板，以基准色作为强调色，向下扩展对应的弱化颜色。

注意，与分类基础色板不同的是，通常情况下的强调色不会同时出现，因此无需考虑明暗交替；其次，与分类扩展色板不同的是，因分类扩展色板需要考虑对比度，这里则需要尽量弱化，所以弱化色亮度要高于分类扩展色板。

2. 应用效果

六、发散色板 用来表示具有正负、高低、涨跌等关系的数据，拥有临界中间值，因此通常使用一对冷暖色来呈现。

1. 取色规则

首先，根据发散色板表达数据对立关系的特性，我们在选取对立冷暖色时，可以通过模拟视障效果来排除掉一些可能会出现问题的颜色。

我们选取了既可以表达冷暖关系又不会出现问题的三组颜色，以及表达中立的一组颜色。

其次，由于发散色板的使用场景与顺序色板类似，因此我们可以基于全量色板扩展出对应的固定色板。并使用 Chroma.js - chroma.mix 工具将对立相接的两个颜色进行混合，使其过渡更加均匀。

视障用户效果模拟，既不能混淆颜色，又不能改变原冷暖关系映射。

而为了应对数据阶梯量大且不可预知的场景，我们可以基于固定色板扩展出动态色板，与顺序色板动态色板原理类似，本质上是一组渐变色板，数据阶梯分布区间有多少，则可以在渐变色板上插对应数量的值。

此处再次体现感知均匀色彩空间的优势，渐变色过渡也是非常自然的。

2. 应用效果

可视化效果使用 Datawrapper 模拟。

3. 色相偏移

关于发散色板的生成，其实还有一种使用范围更广的色相偏移色板，相对无色相偏移色板来说过渡更加自然，更加符合人类对色温的认知。也就是常说的随着色阶的变化冷色会更冷，暖色会更暖。先来看下对比效果：

我们的方法是取三种不同暖色中的关键色与三组不同冷色中的关键色，使用 Chroma.js Color Palette Helper 进行混合，生成新的色相偏移色板。

但使用该方案并不能生成所有想要的色板，因为我们的一个大前提是所有颜色取至全量色板。如在生成红-蓝发散色板时发现，并没有合适的三组暖色供我们选择用来取出关键色，这就会导致生成的色板偏色严重无法使用。

所以，个人猜测，未来一方面应该向更科学合理的色相偏移方案探索，另一方面在该场景中不应将取色标准局限于全量色板。

由于我们的产品中很小概率会使用到发散色板，所以这里不做深入研究，也避免误导大家，就此打住。

七、语义色板 可视化场景中不受主题、风格影响的颜色，是约定成俗具有特定寓意的颜色，通常用于表示告警等级、正负关系等。

1. 取色规则

关于语义色板的取色来源颇受争议，一种方案是直接选取设计系统中的语义色，另一种是从可视化全量色板中选取并重新定义。其实两种方案各有优劣，关键在于如何客观评判。我们选择从可视化色板中选取并重新定义的理由如下：

设计系统色板的色彩空间与可视化有本质区别，无法做到统一； 设计系统中定义的语义色感官上饱和度及亮度与可视化色彩不统一，融入可视化场景中不和谐； 图表中的元素形状面积通常占比较大，与其他颜色的元素搭配时，使用可视化色彩会更协调； 设计系统中的语义色从使用场景、设计思路等角度考虑的话，会与可视化场景有细微差别，解耦设计更合理一些。 注意灰色语义色取至中性色板，后面会解释原因。

2. 应用效果

八、中性色板 中性色板用于可视化图表中的标题、轴线、文字等场景，与设计系统中性色板保持一致，这里不做特殊定制。上文提到过，为何中性色板区别于语义色板，可以与设计系统共用呢？

首先中性色板本质上都是中性色，应该区别于“有色彩”的颜色。那么，从其使用场景上来看，中性色板可以不受系统限制，独立于设计系统或者可视化组件库以外，成为一套公共的色板； 其次，从使用者角度来考虑，中性色板可以说是使用范围最广的，这就形成了肌肉记忆，不再适合重新开辟一套来给大家造成记忆负担； 再其次，从页面效果来看，理想状态还是所有中性色保持一致，不能说承载图表的卡片标题是一个颜色，而同级别非图表卡片标题又是另一个颜色； 最后，从底层色彩空间来看，中性色是不受色彩空间限制的，可以通用于各种不同色彩空间搭建的系统中是必然的。

九、总结 总之就一句话，关于颜色的探索是永无止境的，随着探索的不断深入，越发觉得距离踏入门槛是越来越远了。

如何从 0 到 1 搭建一套适合产品发展的体验度量指标模型？ 本文将分析产品阶段、业务属性、取数方式对于指标模型的影响，以及该如何拆分细化指标。搭建一套合适的体验度量模型，不仅能帮我们将“用户体验”这个概念具象化，用一套分数体系来衡量一段时间内的体验质量变化，更能将定性定量的数据结合起来，指导我们针对关键问题进行...

如何从 0 到 1 搭建一套适合产品发展的体验度量指标模型？ 本文将分析产品阶段、业务属性、取数方式对于指标模型的影响，以及该如何拆分细化指标。

搭建一套合适的 体验度量 模型，不仅能帮我们将“用户体验”这个概念具象化，用一套分数体系来衡量一段时间内的体验质量变化，更能将定性定量的数据结合起来，指导我们针对关键问题进行优化迭代。

下面就结合往期经验，和大家聊一聊在实际项目中，如何从 0 到 1 建设 体验指标模型 。

更多体验 设计模型 ：

设计高手都在用的双钻模型和5E体验模型，看完这篇立刻学会！ 编者按：设计模型中最常见的2个：双钻模型和5E体验模型，看完这篇帮你掌握！

阅读文章 >

一、产品阶段与体验度量 第一步我们应该审视自己产品的发展阶段，这是为了确定整个体验度量项目的宏观目标。

对于不同阶段的产品而言，发展策略和目标的差异会很大。一般来说，各类型产品都会经历下图所示的几个阶段。随着自身的发展、竞争环境的变化，从启动逐渐走向成熟，进而寻求更大突破。因此，用户度量的目标也会随之变化。

1. 冷启动 — 探索期

业务目标：功能快速上线，用户数量快速增长；

体验目标：无需过多指标，借机推进简单的用户调研，以发现定性问题为主要目的；

具体举措：利用现有资源让项目上线并正常运转。快速上线不重体验，快速接触用户，验证产品价值，探索产品定位及发展方向，在产品体验上不必花费太多精力。

2. 深耕期 — 打磨期

业务目标：用户体量逐渐增加，功能趋近完善，追齐主流竞品；

体验目标：逐渐完善指标体系，埋点取数准备，以长期客观数据监测为主；

具体举措：基于确定的方向深挖，打造产品壁垒。体验问题走查，优化遗留问题。

3. 突破期

业务目标：用户增长逐渐见顶，寻找新的突破点；

体验目标：在原有指标体系基础上，通过长期的体验数据洞察趋势变化；

具体举措：成立专项研究小组，团队模块分工，深入分析，细化人群，挖掘用户潜在需求。

二、业务类型与维度选取 确定了整体的方向，下一步进行度量维度的选取。那究竟哪些维度是适合自身产品的呢？

上图列举了常见的维度，主要分为三类：用户主观感受、用户客观行为、产品系统表现。

选取具体体验维度也跟产品的业务属性息息相关，B 端和 C 端产品的侧重点并不相同。

1. B 端产品

代表维度：任务效率、一致性、易用性、性能

工具类产品较多，重视核心流程的任务效率。需要的是既快又好，容易理解，操作简单，流程顺畅。一致性有利于降低认知成本，易用性有助于提高工作效率，性能更是保障一切的基础。

2. C 端产品

代表维度：满意度、净推荐值、忠诚度

同类型产品的核心功能相近，因此产品的差异化吸引力相对更加重要。用户的态度就更需要被重视。当然核心流程的转化率、经营性指标也很关键，但这些业务指标受到的波动因素也很多，对于长期的用户体验提升而言，参考价值不大。

三、常用取数方式 确定了一级维度，我们需要从更加落地的角度去选取合适的取数方式，这里介绍两类较为常见的取数方式。

1. 用户主动反馈

这种方式更容易获得定性的数据，也就是上面提到的用户主观感受，但需要定期投入较大的人力成本，比如每个月投放一次问卷或每个季度实施一轮用户访谈，以及后期的问题归纳梳理等。

这种方式更适用于发现、定位问题，只要在做访谈或者问卷调研时，对问题再进行细节上的追问，很容易找到问题的原因，以及解决的切入点。

2. 后台系统记录

这种方式更适合获得长期的定量数据，短期内可能无法精准定位问题，需要不断下钻。并且对于波动较大的指标，很难确定合适的标准值范围。

因此，这种方式前期投入的数据开发成本较多，但一旦数据趋于稳定，后期维护成本较低，能够起到实时监测作用。在出现异常数据时，能够及时预警，便于问题排查。

很多产品在发展初期，并没有为系统化监测做准备，所以很多后台数据是不完善的。比如性能数据，一般都是研发工程师关注的。而任务效率可能需要做相应的埋点开发，短期内可能难以看到成效。

因此，一期体验度量项目，大都以获取用户主观数据为主。通过实施 2-3 轮细致的用户访谈和更大样本量的问卷调研，来获取满意度和易用性的主观数据。同时，也能获得较为详细的问题列表，定位较为常见的用户问题。而在后台取数方面，针对任务效率、性能等维度，也会逐步开始数据的后台开发、补充埋点等。在二期、三期的项目里，再实现系统化的体验管理。

四、细项指标选取 度量模型的框架已经基本构建完成，那接下来又该如何在框架上补充细节，选取二级、三级指标呢？

下面介绍三类较为通用的选取逻辑。

1. 按照用户使用流程划分

任务效率需要把用户使用的流程环节拆解。比如线上购物可以拆分为：搜索商品、浏览商详页、加入购物车、下单结算、支付、确认收货、评价这些环节；

2. 按照页面功能模块划分

完整性需要把核心页面进行拆解。如首页可以拆分为搜索、频道区、运营位、秒杀区、直播区、推荐榜单、推荐商品等模块；

3. 直接看整体，不再细分

在详细指标并不是特别完善的情况下，也可以看产品的整体情况。如性能，可以看整体 APP 的冷启动耗时、热启动耗时、崩溃率、页面卡顿率等指标。

五、如何计算分数 现在，体验度量的项目已经完成了一大半，剩下的就是统一“度量衡”，进行算分了。

在这么一个综合的体验度量体系中，每一个维度、每一项指标都有不同的单位。

随便举几个例子，任务耗时单位为秒，首屏耗时的单位为毫秒，参与度维度下人均访问频次的单位为次/人日，完整性的维度又以%来计算……如何用一把标尺来衡量这些天差地别的指标呢？

1. 换算百分制

像满意度、易用性这类指标，本身就是按照百分制/十分制或其他分数制度来打分的，简单来说就是这些指标有一个明确标准的满分。这些指标的换算相对较为简单，可以将它们统一换算为百分制。

2. 设定标准值

另一类指标则没有固定的标准，比如性能下的各个指标，首页加载耗时多久视为满分？崩溃率降到多低视为满分？

这些指标通常需要各方沟通讨论，确定标准值（最低分和最高分），再计算当前值在这两个值之间的百分序列。换句话说，就是把标准值之间的数切割成 100 份，看看当前这个周期的平均值落在 100 份里的哪个位置。

那怎么确定合适的门槛值和目标值呢？有些数据我们可以参考行业的标准，像性能指标就可以参考 google chrome 的一些标准（加载时长、交互性、视觉稳定性都有较为详细的指标）。

如果没有任何参考，则建议选取产品自身较长时间周期的数据，因为短期的数据往往波动较大，很难准确定义标准值。通过计算周期中位数和标准差，将上一个时间周期的标准值作为现阶段的参考，就可以将波动范围进一步缩小。

在实际项目里，我们又发现了另一个问题，起步分值定得太低了，即使达到了门槛，也可能只有 20 几分。所以，我们在后期将门槛值对应的分数调整为 60 分。当然，多制定几个标准值，也能在一定程度上，更加精准地统计分数。比如，门槛值=60 分，目标值=80 分，挑战值=100 分。

六、常见问题及相关参考 Q：为什么要做体验度量？业界有哪些较为成熟的体验度量模型？

A：看这篇：

如何做好用户体验度量？京东设计师总结了五个步骤！ 体验度量是什么？

阅读文章 >

以上，大致梳理了搭建数据指标的几个重要步骤，希望对大家有所帮助！

欢迎关注「JellyDesign」的小程序：

如何从 0 到 1 搭建一套适合产品发展的体验度量指标模型？ 本文将分析产品阶段、业务属性、取数方式对于指标模型的影响，以及该如何拆分细化指标。搭建一套合适的体验度量模型，不仅能帮我们将“用户体验”这个概念具象化，用一套分数体系来衡量一段时间内的体验质量变化，更能将定性定量的数据结合起来，指导我们针对关键问题进行...

如何从 0 到 1 搭建一套适合产品发展的体验度量指标模型？ 本文将分析产品阶段、业务属性、取数方式对于指标模型的影响，以及该如何拆分细化指标。

搭建一套合适的 体验度量 模型，不仅能帮我们将“用户体验”这个概念具象化，用一套分数体系来衡量一段时间内的体验质量变化，更能将定性定量的数据结合起来，指导我们针对关键问题进行优化迭代。

下面就结合往期经验，和大家聊一聊在实际项目中，如何从 0 到 1 建设 体验指标模型 。

更多体验 设计模型 ：

设计高手都在用的双钻模型和5E体验模型，看完这篇立刻学会！ 编者按：设计模型中最常见的2个：双钻模型和5E体验模型，看完这篇帮你掌握！

阅读文章 >

一、产品阶段与体验度量 第一步我们应该审视自己产品的发展阶段，这是为了确定整个体验度量项目的宏观目标。

对于不同阶段的产品而言，发展策略和目标的差异会很大。一般来说，各类型产品都会经历下图所示的几个阶段。随着自身的发展、竞争环境的变化，从启动逐渐走向成熟，进而寻求更大突破。因此，用户度量的目标也会随之变化。

1. 冷启动 — 探索期

业务目标：功能快速上线，用户数量快速增长；

体验目标：无需过多指标，借机推进简单的用户调研，以发现定性问题为主要目的；

具体举措：利用现有资源让项目上线并正常运转。快速上线不重体验，快速接触用户，验证产品价值，探索产品定位及发展方向，在产品体验上不必花费太多精力。

2. 深耕期 — 打磨期

业务目标：用户体量逐渐增加，功能趋近完善，追齐主流竞品；

体验目标：逐渐完善指标体系，埋点取数准备，以长期客观数据监测为主；

具体举措：基于确定的方向深挖，打造产品壁垒。体验问题走查，优化遗留问题。

3. 突破期

业务目标：用户增长逐渐见顶，寻找新的突破点；

体验目标：在原有指标体系基础上，通过长期的体验数据洞察趋势变化；

具体举措：成立专项研究小组，团队模块分工，深入分析，细化人群，挖掘用户潜在需求。

二、业务类型与维度选取 确定了整体的方向，下一步进行度量维度的选取。那究竟哪些维度是适合自身产品的呢？

上图列举了常见的维度，主要分为三类：用户主观感受、用户客观行为、产品系统表现。

选取具体体验维度也跟产品的业务属性息息相关，B 端和 C 端产品的侧重点并不相同。

1. B 端产品

代表维度：任务效率、一致性、易用性、性能

工具类产品较多，重视核心流程的任务效率。需要的是既快又好，容易理解，操作简单，流程顺畅。一致性有利于降低认知成本，易用性有助于提高工作效率，性能更是保障一切的基础。

2. C 端产品

代表维度：满意度、净推荐值、忠诚度

同类型产品的核心功能相近，因此产品的差异化吸引力相对更加重要。用户的态度就更需要被重视。当然核心流程的转化率、经营性指标也很关键，但这些业务指标受到的波动因素也很多，对于长期的用户体验提升而言，参考价值不大。

三、常用取数方式 确定了一级维度，我们需要从更加落地的角度去选取合适的取数方式，这里介绍两类较为常见的取数方式。

1. 用户主动反馈

这种方式更容易获得定性的数据，也就是上面提到的用户主观感受，但需要定期投入较大的人力成本，比如每个月投放一次问卷或每个季度实施一轮用户访谈，以及后期的问题归纳梳理等。

这种方式更适用于发现、定位问题，只要在做访谈或者问卷调研时，对问题再进行细节上的追问，很容易找到问题的原因，以及解决的切入点。

2. 后台系统记录

这种方式更适合获得长期的定量数据，短期内可能无法精准定位问题，需要不断下钻。并且对于波动较大的指标，很难确定合适的标准值范围。

因此，这种方式前期投入的数据开发成本较多，但一旦数据趋于稳定，后期维护成本较低，能够起到实时监测作用。在出现异常数据时，能够及时预警，便于问题排查。

很多产品在发展初期，并没有为系统化监测做准备，所以很多后台数据是不完善的。比如性能数据，一般都是研发工程师关注的。而任务效率可能需要做相应的埋点开发，短期内可能难以看到成效。

因此，一期体验度量项目，大都以获取用户主观数据为主。通过实施 2-3 轮细致的用户访谈和更大样本量的问卷调研，来获取满意度和易用性的主观数据。同时，也能获得较为详细的问题列表，定位较为常见的用户问题。而在后台取数方面，针对任务效率、性能等维度，也会逐步开始数据的后台开发、补充埋点等。在二期、三期的项目里，再实现系统化的体验管理。

四、细项指标选取 度量模型的框架已经基本构建完成，那接下来又该如何在框架上补充细节，选取二级、三级指标呢？

下面介绍三类较为通用的选取逻辑。

1. 按照用户使用流程划分

任务效率需要把用户使用的流程环节拆解。比如线上购物可以拆分为：搜索商品、浏览商详页、加入购物车、下单结算、支付、确认收货、评价这些环节；

2. 按照页面功能模块划分

完整性需要把核心页面进行拆解。如首页可以拆分为搜索、频道区、运营位、秒杀区、直播区、推荐榜单、推荐商品等模块；

3. 直接看整体，不再细分

在详细指标并不是特别完善的情况下，也可以看产品的整体情况。如性能，可以看整体 APP 的冷启动耗时、热启动耗时、崩溃率、页面卡顿率等指标。

五、如何计算分数 现在，体验度量的项目已经完成了一大半，剩下的就是统一“度量衡”，进行算分了。

在这么一个综合的体验度量体系中，每一个维度、每一项指标都有不同的单位。

随便举几个例子，任务耗时单位为秒，首屏耗时的单位为毫秒，参与度维度下人均访问频次的单位为次/人日，完整性的维度又以%来计算……如何用一把标尺来衡量这些天差地别的指标呢？

1. 换算百分制

像满意度、易用性这类指标，本身就是按照百分制/十分制或其他分数制度来打分的，简单来说就是这些指标有一个明确标准的满分。这些指标的换算相对较为简单，可以将它们统一换算为百分制。

2. 设定标准值

另一类指标则没有固定的标准，比如性能下的各个指标，首页加载耗时多久视为满分？崩溃率降到多低视为满分？

这些指标通常需要各方沟通讨论，确定标准值（最低分和最高分），再计算当前值在这两个值之间的百分序列。换句话说，就是把标准值之间的数切割成 100 份，看看当前这个周期的平均值落在 100 份里的哪个位置。

那怎么确定合适的门槛值和目标值呢？有些数据我们可以参考行业的标准，像性能指标就可以参考 google chrome 的一些标准（加载时长、交互性、视觉稳定性都有较为详细的指标）。

如果没有任何参考，则建议选取产品自身较长时间周期的数据，因为短期的数据往往波动较大，很难准确定义标准值。通过计算周期中位数和标准差，将上一个时间周期的标准值作为现阶段的参考，就可以将波动范围进一步缩小。

在实际项目里，我们又发现了另一个问题，起步分值定得太低了，即使达到了门槛，也可能只有 20 几分。所以，我们在后期将门槛值对应的分数调整为 60 分。当然，多制定几个标准值，也能在一定程度上，更加精准地统计分数。比如，门槛值=60 分，目标值=80 分，挑战值=100 分。

六、常见问题及相关参考 Q：为什么要做体验度量？业界有哪些较为成熟的体验度量模型？

A：看这篇：

如何做好用户体验度量？京东设计师总结了五个步骤！ 体验度量是什么？

阅读文章 >

以上，大致梳理了搭建数据指标的几个重要步骤，希望对大家有所帮助！

欢迎关注「JellyDesign」的小程序：

我们将常规的基础通用手势进行打散重组、结合实践案例梳理出组合手势设计模型，探索如何在视频场景中构建便捷高效的进阶手势体验。手势设计干货：超多案例！交互手势全解析（三）：多指类和组合类多指类手势 之前的文章讲解位移类手势和点击类手势的时候，提到过不同的描述维度会让手势产生不同的变种，比如触发时机、 按下次数、 阈值...

我们将常规的基础通用手势进行打散重组、结合实践案例梳理出组合手势设计模型，探索如何在视频场景中构建便捷高效的进阶手势体验。

手势设计 干货：

超多案例！交互手势全解析（三）：多指类和组合类 多指类手势 之前的文章讲解位移类手势和点击类手势的时候，提到过不同的描述维度会让手势产生不同的变种，比如触发时机、 按下次数、 阈值类型等。

阅读文章 >

一、前言 视频播放器中承载着极其丰富的内容画面和播控功能，尤其是在寸土寸金的移动端视频播放器中，为使内容更沉浸消费，需尽可能克制界面中的功能元素/入口直接外露。基于此种场景下，合理的手势设计不但可为界面“减负”，还可帮助用户更快捷触达功能、提升操控便捷性。

视频场景中目前已有部分的常规单向手势已被用户广泛接受并形成习惯认知，如「单击 →暂停」、「双击→点赞」、「长按→快进」、「横滑→ 导航 」、「纵滑→切视频」、「双指捏合→缩放视窗」等通用手势。

那么如何在保留用户对于常规通用手势认知的基础上，进一步对视频场景中的手势交互进行扩容升级？这也是我们接下来在手势进阶交互上的重点探索方向。

本次针对百度 APP 中的视频播放器场景，为提升手势操控效率，我们试图将常规的基础通用手势进行打散重组、并结合实践案例梳理出「组合手势」设计模型，以探索如何在视频场景中构建便捷高效的进阶手势体验设计。

二、什么是「组合手势」 「组合手势」是基于常规手势的组合扩展，其通常由两种或两种以上的常规基础手势所构成，若组合方式及使用场景得当，可助力用户更便捷的触达功能。

以前述的视频场景常规手势为例，其触发机制一般可分为两个阶段：step1 交互信号 → step2执行任务，即用户通过某一基础手势发出交互信号，系统收到信号确认后便可立即执行任务，但整个过程是线性的，手势扩展性十分有限且难以满足视频场景对于手势扩容的诉求。

于是我们在现有常规手势两阶段触发机制的基础上，尝试引入「意图识别」环节，并梳理出「组合手势」的设计模型，以探索不同基础手势相互组合后的扩展可行性。

「组合手势」触发一般可分为三个阶段：step1 交互信号→step2意图识别→step3执行任务，前两阶段均可由对应的基础分支手势构成并进行组合搭配、以寻求最高效的手势组合触发路径。

由于「组合手势」并不像常规手势那样早已被系统定义为可供直接调用的接口，因此，其差异化创新具有较大设计灵活度，尤其需根据具体的使用场景进行综合考量。

三、「长按组合手势」激活快捷菜单 1. 项目背景

百度 APP 视频场景早期的播控功能较少，如“视频下载”等个别特色功能入口一般都融合于基础菜单之中。

随着后续视频场景的功能建设日渐完善，我们便在基础菜单面板中拓展了一行视频菜单，专门用于承载视频场景特有的播控功能。但当前播控功能已达 10 余项，菜单面板弹出后还需左滑才可露出后面的功能入口，因此也常收到用户反馈找不到常用功能、菜单面板功能排布无章且触发成本高。

2. 竞品调研及选型

通过对竞品进行调研，我们发现竞品均有使用长按手势作为切入口以触发相关播控功能、并归纳出“视频播控触发”目前主流的三种长按交互选型， 分别为：长按触发独立播控面板、长按触发浮层播控选项、长按触发特定播控功能。

选型 A

「长按触发独立播控面板」：通过长按手势可激活从屏幕底部弹出的独立播控面板，此方案扩展性较强，但对视频沉浸观感体验有一定的打断感；

选型 B

「长按触发浮层播控选项」：通过长按手势可触发置于视窗上层的浮层选项入口，一定程度上可延续视频观看的沉浸体验，但浮层扩展性有限；

选型 C

「长按触发特定播控功能」：通过长按手势触发特定的某个播控功能（如长按“快进”），一定程度上可满足此功能的重度用户，但对于长按手势的使用效率较低；

3. 设计方案

① 长按手势交互扩容

针对目前视频播控菜单存在的问题，经过和业务对上述三种长按交互选型方案进行综合考量，最终决定聚焦于以方案“选型 B”的「长按触发浮层播控选项」作为设计切入点。我们意图将部分高频播控功能从基础菜单中拿出进行前置，并探索一套更便捷的触发机制，以此对视频场景中的播控菜单进行设计升级。

但随之而来的难点是我们目前播放器中的长按手势已被“快进”功能占据，用户对此功能的使用频率高、并已形成较深的操控认知，若直接下线“快进”功能则会对用户使用习惯产生较大影响，尤其是视频场景的重度用户。

那么如何在兼容用户已有长按操作习惯的基础上再拓展“快捷菜单”呢？是否有可能将“快进”和“快捷菜单”进行融合？这也是本次项目对于便捷手势体验的重要设计探索点。

基于此，我们决定尝试使用「组合手势」设计模型来对视频播放器中的长按手势进行重新定义，通过「长按+滑选」的机制触发快捷菜单功能项，以缩短视频常用功能路径。对应到设计模型的三个阶段分别为：

step1：以“长按手势”创建一个新模式，即发出交互信号并唤出浮层菜单；

step2：若用户未松开手指，则系统默认开始识别用户意图，是否有以“拖拽手势”滑选至目标功能项以选择功能；

step3：用户滑选锚定至目标功能后，松手释放即可完成最后的功能执行确认。

「长按+向上滑选」快捷触发对应功能项；

「长按+向下滑选」快捷触发“快进”（一定程度上兼容老用户对于此功能的使用习惯）。

② 容错性兼容

在设定「长按+滑选」组合手势的同时，考虑到兼容主流的长按习惯、以及对于滑选手势需要有一定的适应过程，我们同时也支持点选的操作模式，即用户长按后若未产生滑选行为便松手，则松手后依然可通过点选的方式触发对应播控功能项。

③ 易用性打磨

差异化的创新设计形式在前期总会面临质疑和挑战，本次项目也不例外。我们担心用户能否接受并认知「长按+滑选」组合手势的操作形式，于是在 DEMO 开发完成后便进行了一次小范围内的定性可用性测试，以预期在上线前可先收集一波体验问题进行快速打磨优化。

我们根据测试目标、用户类别、测试前序准备及测试步骤等环节提前拟好必要的测试脚本，并邀请了 10+名不同年龄段的目标用户进行访谈测试。

测试访谈的过程中，被测用户在进行 1 至 2 次尝试操作之后，均可掌握如何使用「长按+滑选」的组合手势，这也为我们增添了不少信心。

同时，我们通过观察用户操作行为及用户主动反馈，发现仍有部分易用性细节可进一步打磨优化。

扩展触发热区：

考虑到单手握持手机的使用场景，可尽可能扩大定义长按手势的触发热区，屏幕中除顶/底 bar 框架区以及本身就自带长按事件的按钮入口之外，其它大面积区域热区均可支持长按触发快捷菜单，以降低触发难度、提升易用性。

支持跟手触发：

长按后浮出的快捷功能项，其浮出位置支持跟随手指的纵向触发位置而浮出，可减少手指在屏幕上的位移距离、操控更便捷。

实时提示及响应反馈：

灵活判断当前手势触控状态（如滑入选择 / 松手触发），在界面中即时给出相对应的引导提示或振感反馈，以帮助用户快速适应新的手势触发机制。

方案上线及验证

以 AB 实验对本次设计方案进行定量测试验证：

「对照组」效果：长按触发“快进”（各播控功能入口仍归置于基础菜单面板之中）； 「实验组」效果：长按触发“快捷菜单”选项（支持滑选和点选模式）； 小流量实验上线后，经过近半个月的观察，大盘指标稳定、播放完成率等满意度指标稳步提升。

「实验组」长按快捷菜单中的功能使用率相对「对照组」均有大幅提升，说明用户对部分高频功能的确有很强的快捷触发诉求。 「实验组」的“快进”虽多了一步触发步长，实验前期“快进”使用率不及「对照组」，但随着用户对于「长按+滑选」手势整体的使用占比持续走高，通过滑选触发“快进”的操作习惯也快速被培养起来，对于用户来说，长按快捷菜单带来的整体收益是大于折损的。

二期扩展方案

随着长按快捷菜单的上线推全，长按手势的渗透率也持续走高，用户逐渐对视频场景更多的播控功能有了长按触发的诉求，于是我们对长按菜单进行了二期的设计升级，在长按浮层最右侧新增“更多”快捷入口以承接视频场景所有的播控功能，用户通过长按后的可选播控项增多，播控功能整体的使用量得到进一步提升。

四、「组合手势」拓展探索 手势交互是用户在现实世界行为的映射，无论是基础手势还是组合类高级手势，都须符合用户认知习惯、并融入具体的使用场景中进行设计。

以「组合手势」设计模型为指导基础、并结合具体的项目实践，我们进一步对视频播放器中更多功能场景进行了便捷手势的设计扩容探索。

1.「右滑返回手势」激活“小窗播放”

“小窗播放”旨在退出当前视频落地页、并可将当前视频切换成以悬浮视窗的形式进行延续消费。

基于用户的此种操控意图，我们以“右滑返回手势”发出交互信号而触发浮出小窗入口，随后系统根据用户“纵向拖拽手势”的行为来判断其是否有激活小窗的意图，若有短距上滑拖拽行为，松手释放即可快捷激活视频小窗，以提升观看体验的连续性。

2.「双指手势」激活“满屏播放”

“双指拖拽手势”可拖拽并清屏视窗画面，以此手势发出交互信号，若在“双指拖拽手势”基础上有识别到“双指扩张手势”行为，则松手释放即可快捷激活“满屏播放”，以满足更沉浸视频浏览体验。

五、结语 便捷手势的设计出发点是为提升操控效率、缩减功能触发路径，从而使视频内容更沉浸消费。希望本次基于视频播放器场景的手势体验设计实践能给大家带来帮助和启发，后续我们也将持续深耕视频领域、并进一步探索更贴合用户使用场景的手势交互体验。

我们将常规的基础通用手势进行打散重组、结合实践案例梳理出组合手势设计模型，探索如何在视频场景中构建便捷高效的进阶手势体验。手势设计干货：超多案例！交互手势全解析（三）：多指类和组合类多指类手势 之前的文章讲解位移类手势和点击类手势的时候，提到过不同的描述维度会让手势产生不同的变种，比如触发时机、 按下次数、 阈值...

我们将常规的基础通用手势进行打散重组、结合实践案例梳理出组合手势设计模型，探索如何在视频场景中构建便捷高效的进阶手势体验。

手势设计 干货：

超多案例！交互手势全解析（三）：多指类和组合类 多指类手势 之前的文章讲解位移类手势和点击类手势的时候，提到过不同的描述维度会让手势产生不同的变种，比如触发时机、 按下次数、 阈值类型等。

阅读文章 >

一、前言 视频播放器中承载着极其丰富的内容画面和播控功能，尤其是在寸土寸金的移动端视频播放器中，为使内容更沉浸消费，需尽可能克制界面中的功能元素/入口直接外露。基于此种场景下，合理的手势设计不但可为界面“减负”，还可帮助用户更快捷触达功能、提升操控便捷性。

视频场景中目前已有部分的常规单向手势已被用户广泛接受并形成习惯认知，如「单击 →暂停」、「双击→点赞」、「长按→快进」、「横滑→ 导航 」、「纵滑→切视频」、「双指捏合→缩放视窗」等通用手势。

那么如何在保留用户对于常规通用手势认知的基础上，进一步对视频场景中的手势交互进行扩容升级？这也是我们接下来在手势进阶交互上的重点探索方向。

本次针对百度 APP 中的视频播放器场景，为提升手势操控效率，我们试图将常规的基础通用手势进行打散重组、并结合实践案例梳理出「组合手势」设计模型，以探索如何在视频场景中构建便捷高效的进阶手势体验设计。

二、什么是「组合手势」 「组合手势」是基于常规手势的组合扩展，其通常由两种或两种以上的常规基础手势所构成，若组合方式及使用场景得当，可助力用户更便捷的触达功能。

以前述的视频场景常规手势为例，其触发机制一般可分为两个阶段：step1 交互信号 → step2执行任务，即用户通过某一基础手势发出交互信号，系统收到信号确认后便可立即执行任务，但整个过程是线性的，手势扩展性十分有限且难以满足视频场景对于手势扩容的诉求。

于是我们在现有常规手势两阶段触发机制的基础上，尝试引入「意图识别」环节，并梳理出「组合手势」的设计模型，以探索不同基础手势相互组合后的扩展可行性。

「组合手势」触发一般可分为三个阶段：step1 交互信号→step2意图识别→step3执行任务，前两阶段均可由对应的基础分支手势构成并进行组合搭配、以寻求最高效的手势组合触发路径。

由于「组合手势」并不像常规手势那样早已被系统定义为可供直接调用的接口，因此，其差异化创新具有较大设计灵活度，尤其需根据具体的使用场景进行综合考量。

三、「长按组合手势」激活快捷菜单 1. 项目背景

百度 APP 视频场景早期的播控功能较少，如“视频下载”等个别特色功能入口一般都融合于基础菜单之中。

随着后续视频场景的功能建设日渐完善，我们便在基础菜单面板中拓展了一行视频菜单，专门用于承载视频场景特有的播控功能。但当前播控功能已达 10 余项，菜单面板弹出后还需左滑才可露出后面的功能入口，因此也常收到用户反馈找不到常用功能、菜单面板功能排布无章且触发成本高。

2. 竞品调研及选型

通过对竞品进行调研，我们发现竞品均有使用长按手势作为切入口以触发相关播控功能、并归纳出“视频播控触发”目前主流的三种长按交互选型， 分别为：长按触发独立播控面板、长按触发浮层播控选项、长按触发特定播控功能。

选型 A

「长按触发独立播控面板」：通过长按手势可激活从屏幕底部弹出的独立播控面板，此方案扩展性较强，但对视频沉浸观感体验有一定的打断感；

选型 B

「长按触发浮层播控选项」：通过长按手势可触发置于视窗上层的浮层选项入口，一定程度上可延续视频观看的沉浸体验，但浮层扩展性有限；

选型 C

「长按触发特定播控功能」：通过长按手势触发特定的某个播控功能（如长按“快进”），一定程度上可满足此功能的重度用户，但对于长按手势的使用效率较低；

3. 设计方案

① 长按手势交互扩容

针对目前视频播控菜单存在的问题，经过和业务对上述三种长按交互选型方案进行综合考量，最终决定聚焦于以方案“选型 B”的「长按触发浮层播控选项」作为设计切入点。我们意图将部分高频播控功能从基础菜单中拿出进行前置，并探索一套更便捷的触发机制，以此对视频场景中的播控菜单进行设计升级。

但随之而来的难点是我们目前播放器中的长按手势已被“快进”功能占据，用户对此功能的使用频率高、并已形成较深的操控认知，若直接下线“快进”功能则会对用户使用习惯产生较大影响，尤其是视频场景的重度用户。

那么如何在兼容用户已有长按操作习惯的基础上再拓展“快捷菜单”呢？是否有可能将“快进”和“快捷菜单”进行融合？这也是本次项目对于便捷手势体验的重要设计探索点。

基于此，我们决定尝试使用「组合手势」设计模型来对视频播放器中的长按手势进行重新定义，通过「长按+滑选」的机制触发快捷菜单功能项，以缩短视频常用功能路径。对应到设计模型的三个阶段分别为：

step1：以“长按手势”创建一个新模式，即发出交互信号并唤出浮层菜单；

step2：若用户未松开手指，则系统默认开始识别用户意图，是否有以“拖拽手势”滑选至目标功能项以选择功能；

step3：用户滑选锚定至目标功能后，松手释放即可完成最后的功能执行确认。

「长按+向上滑选」快捷触发对应功能项；

「长按+向下滑选」快捷触发“快进”（一定程度上兼容老用户对于此功能的使用习惯）。

② 容错性兼容

在设定「长按+滑选」组合手势的同时，考虑到兼容主流的长按习惯、以及对于滑选手势需要有一定的适应过程，我们同时也支持点选的操作模式，即用户长按后若未产生滑选行为便松手，则松手后依然可通过点选的方式触发对应播控功能项。

③ 易用性打磨

差异化的创新设计形式在前期总会面临质疑和挑战，本次项目也不例外。我们担心用户能否接受并认知「长按+滑选」组合手势的操作形式，于是在 DEMO 开发完成后便进行了一次小范围内的定性可用性测试，以预期在上线前可先收集一波体验问题进行快速打磨优化。

我们根据测试目标、用户类别、测试前序准备及测试步骤等环节提前拟好必要的测试脚本，并邀请了 10+名不同年龄段的目标用户进行访谈测试。

测试访谈的过程中，被测用户在进行 1 至 2 次尝试操作之后，均可掌握如何使用「长按+滑选」的组合手势，这也为我们增添了不少信心。

同时，我们通过观察用户操作行为及用户主动反馈，发现仍有部分易用性细节可进一步打磨优化。

扩展触发热区：

考虑到单手握持手机的使用场景，可尽可能扩大定义长按手势的触发热区，屏幕中除顶/底 bar 框架区以及本身就自带长按事件的按钮入口之外，其它大面积区域热区均可支持长按触发快捷菜单，以降低触发难度、提升易用性。

支持跟手触发：

长按后浮出的快捷功能项，其浮出位置支持跟随手指的纵向触发位置而浮出，可减少手指在屏幕上的位移距离、操控更便捷。

实时提示及响应反馈：

灵活判断当前手势触控状态（如滑入选择 / 松手触发），在界面中即时给出相对应的引导提示或振感反馈，以帮助用户快速适应新的手势触发机制。

方案上线及验证

以 AB 实验对本次设计方案进行定量测试验证：

「对照组」效果：长按触发“快进”（各播控功能入口仍归置于基础菜单面板之中）； 「实验组」效果：长按触发“快捷菜单”选项（支持滑选和点选模式）； 小流量实验上线后，经过近半个月的观察，大盘指标稳定、播放完成率等满意度指标稳步提升。

「实验组」长按快捷菜单中的功能使用率相对「对照组」均有大幅提升，说明用户对部分高频功能的确有很强的快捷触发诉求。 「实验组」的“快进”虽多了一步触发步长，实验前期“快进”使用率不及「对照组」，但随着用户对于「长按+滑选」手势整体的使用占比持续走高，通过滑选触发“快进”的操作习惯也快速被培养起来，对于用户来说，长按快捷菜单带来的整体收益是大于折损的。

二期扩展方案

随着长按快捷菜单的上线推全，长按手势的渗透率也持续走高，用户逐渐对视频场景更多的播控功能有了长按触发的诉求，于是我们对长按菜单进行了二期的设计升级，在长按浮层最右侧新增“更多”快捷入口以承接视频场景所有的播控功能，用户通过长按后的可选播控项增多，播控功能整体的使用量得到进一步提升。

四、「组合手势」拓展探索 手势交互是用户在现实世界行为的映射，无论是基础手势还是组合类高级手势，都须符合用户认知习惯、并融入具体的使用场景中进行设计。

以「组合手势」设计模型为指导基础、并结合具体的项目实践，我们进一步对视频播放器中更多功能场景进行了便捷手势的设计扩容探索。

1.「右滑返回手势」激活“小窗播放”

“小窗播放”旨在退出当前视频落地页、并可将当前视频切换成以悬浮视窗的形式进行延续消费。

基于用户的此种操控意图，我们以“右滑返回手势”发出交互信号而触发浮出小窗入口，随后系统根据用户“纵向拖拽手势”的行为来判断其是否有激活小窗的意图，若有短距上滑拖拽行为，松手释放即可快捷激活视频小窗，以提升观看体验的连续性。

2.「双指手势」激活“满屏播放”

“双指拖拽手势”可拖拽并清屏视窗画面，以此手势发出交互信号，若在“双指拖拽手势”基础上有识别到“双指扩张手势”行为，则松手释放即可快捷激活“满屏播放”，以满足更沉浸视频浏览体验。

五、结语 便捷手势的设计出发点是为提升操控效率、缩减功能触发路径，从而使视频内容更沉浸消费。希望本次基于视频播放器场景的手势体验设计实践能给大家带来帮助和启发，后续我们也将持续深耕视频领域、并进一步探索更贴合用户使用场景的手势交互体验。

编者按：UXtools 每年都会针对流行的设计工具进行统计，从而了解设计师是如何使用设计工具，以及哪些设计工具在过去的一年里又占据主流了，以此从侧面了解目前UX设计行业的现状。整个调研报告针对不同的设计环节、设计职能划分出不同的调研门类，其中有针对整个 UX 设计领域的，也有细分到 UI 设计或者用户测试的独立流...

编者按： UXtools 每年都会针对流行的设计工具进行统计 ，从而了解 设计师 是如何使用设计工具，以及哪些 设计工具 在过去的一年里又占据主流了，以此从侧面了解目前UX设计行业的现状。

整个调研报告针对不同的设计环节、设计职能划分出不同的调研门类，其中有针对整个 UX 设计领域的，也有细分到 UI 设计或者用户测试的独立流程的。

这次的设计工具调研问卷总计有 4260 份，调研对象千差万别，来自不同的国家不同规模不同类型的设计师和团队，从统计学的角度上来说，样本的数量足够多，覆盖的区域足够大，类型也相当丰富，所呈现出的结果也比较有代表性。

2022年设计趋势回顾：

回顾2022年，我总结了最受欢迎的 9 个平面设计趋势 编者按：Confetti Design Studio 是一家来自印度的设计工作室，屡获殊荣，客户遍及世界各地。

阅读文章 >

1、概况 在「哪个头衔最能描述你的角色」这个项目当中，我们发现头衔命名混乱的情况依然存在，和前几年相比，UX/UI设计师 的位置上移了，似乎越来越多的设计师也同样对自己的角色感到迷惑。

80% 的受访者反映他们是全职设计师。

在公司规模的调查项目中，绝大多数的设计师都供职于人数超过 10 人的公司，这一点和往年保持一致。

而在设计团队规模的调研当中发现，「2-10人」仍然是最典型的设计团队的人数规模。

在「工作年限」的调研中，我们发现支撑起这个行业的主体依然是较为初级的设计人才，不过工作年限 10+ 的设计师依然保持有不小的比例。

25% 的受访者供职于设计机构，这种环境下各种需求可能会促使他们不断探索和发掘不同的设计工具。

大概有40%的受访者处于团队领导职位，他们倾向于为团队选取并决定使用什么样的工具。

有意思的地方在于，处于领导地位的受访者不一定有权做出采购决策，往往决定是否购买软件的，另有其人。

虽然时常有人认为移动端 APP 华而不实，但是绝大多数的团队和设计师都致力于开发移动端 APP 和 web APP。

绝大多数的设计师和团队依然选择在 Mac 上做设计。不过，Windows 平台的用户比例从去年的 15%上升到今年的 27%，这应该和越来越多设计工具基于浏览器研发有关系。

在工作状态的调研当中，虽然雇主们一直在推动大家「重返办公室」，但是远程工作依然占据主流。

2、界面设计 93% 的受访者都在使用 UI 设计软件，而绝大多数不做 UI 设计的受访者，都是和 UX 相关的职业（比如产品经理，工程师，平面设计师等）。

Figma 处于统治地位一点都不令人意外，而今年 Ai 和 Ps 在几乎所有的门类当中，位置都明显下调了，处于次要地位，他们之所以依然存在，很大程度上是因为他们依然具有一些 Figma 无法取代的编辑功能。

从付费购买的数据来看，Figma 确实不算虚高，虽然免费用户是存在的，但是他们并没有大幅拉高 Figma 的实际占比。Lunacy 其实是一款免费工具，部分被调研用户可能将其和同一公司的另一付费软件弄混了。

在使用操作系统这一选项当中，由于受访者会优先填写操作系统而非特定的工具，这让我们对于整个生态有了一个大致的了解。

而这个基于时间的设计工具调研则清晰地反映出 Figma 崛起的过程。Adobe XD 在今年之前增长都很缓慢，最后的下跌可能和 Figma 被收购有关系。

3、基础原型设计 基础的原型设计和 UI 的交叉度很高，在数据上和 UI 设计的数据高度类似。

91% 的受访者直接用 Figam 制作原型，还有 21%的受访者使用的是 Sketch + InVision 的组合来设计原型，这个组合在几年前还是非常流行的。

许多受访者使用 ProtoPie ，他们从中获得不少价值。这里的 Code 指的是自己使用代码编写的工具来替代专门的软件。

4、高级原型设计 高级原型设计通常会利用逻辑和变量以及其他数据动态输入，借此制作逼真的原型。

大概有 5% 的受访者不确定他们是否制作过高级原型。这个是今年新加入的调研内容。

87% 的受访者使用 ProtoPie 来制作高级原型。值得注意的是，2021 年以来使用自己写的代码来制作原型的设计师比例从 7.7% 上升到了 12.5%。

5、白板工具 数字白板工具是前两年随着疫情而开始崛起的工具。

Figma 和 FigJam 两者结合共同主导了白板设计的领域，但是 Miro、Mural 和 Whimsical 依然是强有力的替代者。

之前这些白板工具仅仅只是看起来有用的工具，但是随着疫情的发展，它们已经成为了日常协同工具中不可或缺的部分，而且正如我们所看到的，它们当中绝大多数都是由雇主购买给设计师使用。

虽然每种工具都会被远程使用或者个人使用、混合使用，但是我们注意到，Mural 被混合使用的比例最高。

6、设计系统 设计系统有助于维持设计元素的交互、视觉样式的统一性，不过我们认为设计系统还没有抵达它真正意义上的「拐点」，所以每年我们对它仅仅是维持观察的状态。

有大概 471 名受访者会使用软件以外的东西来管理他们的设计系统，到底为什么，以及如何维系，这都是值得后续观察的问题。

Figma 可能是设计系统的起点，但是绝对不是终点。有一部分设计师在使用 Notion 和 Confluence 这样的百科类的工具，但是很少有人会使用代码工具。

绝大多数的管理工具依然是团队和公司支付。

在这些流行的工具当中，来自大公司的受访者似乎更有可能使用 Zeroheight 或者 Sketch 来管理设计系统。大公司有时候会有更加严格的工具审核流程。

7、用户测试 用户测试所用到的软件，会尽量让真实的人参与到原型、概念设计、调查研究 和真实的产品体验当中来。

56% 的受访者会使用软件来协助进行用户测试，这个数据和去年几乎是完全一致的。

Maze 是最受欢迎的用户测试工具。值得注意的是，在使用软件进行用户测试的人当中，大概有 三分之一 正在使用网络会议工具（Zoom、Google Meet 和 Microsoft Teams ）来进行用户调研。

去年我们注意到很多设计师和团队不进行用户测试，所以在今年的调研当中，我们加入了这个问题：「为什么不进行用户测试」。

我们注意到，团队内不进行用户测试的受访者当中，大多带有「UX」和「产品设计师」的标签。剩余不做用户调研的人头衔就千奇百怪了。

喜欢面对面进行用户测试的团队，更有可能会选择 Google Meet 和 Microsoft Teams。在混合工作环境中，他们更倾向于使用 Lookback。

8、作品集 作品集工具可以帮助设计师建立个人网站来展示自己的项目。我们注意到，22% 的受访者没有自己的作品集网站，20% 的受访者使用 PDF、PPT 或者其他的静态媒体来呈现他们的作品集。

14% 的受访者会自己使用代码来构建自己的作品集。webflow 是目前最受欢迎的作品集搭建工具。

使用代码来构建作品集的，大多是有超过 10 年工作经验的老手，而仅有1-2 年工作经验的设计师，则倾向于使用 Notion 来构建作品集。

9、主要工具 下面汇总了每个类别下，使用率前三的设计工具：

10、2023预测 每次调研的最后，我们都会询问设计师他们在接下来的一年最感兴趣的工具是什么，通过这种方式我们可以大概了解用户的偏好。其中 Figma 毫不意外地排到了第一。但是更有意思的地方在于，有 111 个受访的设计师同时写下了 Adobe 和 Figma，可见大家对于这俩合体之后能走多远，充满了好奇心。

选择对于 B 端系统来说究竟意味着什么？如果将下图两个组件摆在设计师面前，它们唯一的差别便是 一个有着右侧的下拉箭头、一个右侧没有下拉箭头。当听到了这种解释时，我也就只能摇摇头，一方面感觉很多设计师的基础薄弱，同时又觉得需要和咱们读者来讲讲，关于选择这一大类，对于我们设计师究竟有什么意义？

选择对于 B 端系统来说究竟意味着什么？

如果将下图两个组件摆在 设计师 面前，它们唯一的差别便是 一个有着右侧的下拉箭头、一个右侧没有下拉箭头。

当听到了这种解释时，我也就只能摇摇头，一方面感觉很多设计师的基础薄弱，同时又觉得需要和咱们读者来讲讲，关于选择这一大类，对于我们设计师究竟有什么意义？

首先，选择类的组件对于我们来说已经非常常见，比如简单的：单选框、复选框，难一点的：级联选择、层级选择、树形选择，这些都是我们选择类组件的一个大的范围。

同样的输入也是，输入通常会包含有 输入框、网址输入、特定规则输入 等多种输入方式，这些都是我们输入类组件的一个大的范围。

那先来了解一下选择和输入当中的差别。

往期 B端设计 干货：

5000字干货！超全面的B端设计指南：消息通知 消息通知在我们设计的过程当中非常重要，因为它作为系统与用户之间沟通的桥梁，能够帮助我们提示用户：“目前的操作状态、系统的公告、用户之间的互动内容”，而不同的消息内容，我们需要使用不同的消息通知组件来进行反馈，比如用户与用户之间的互动应该采取什么互动方式？

阅读文章 >

一、生活当中 输入与选择 的差别 想要理解 输入与选择 的差别，我们先来理解生活当中关于输入选择的差别。

举一个生活当中的例子，图片当中的这个物体是什么？

我相信大家给我的回答一定不会相同。比如：有的人可能会说是它是苹果；而有些人则会说是红苹果、红富士、大苹果 等等...

也就导致虽然大家说的都是苹果相关的词汇，但是这些词语往往都会存在细微的差别。

那假设同样一张图片，我们提问的方式是，图片当中的物体是下列四个选项当中的哪一个？

A.香蕉 B.苹果 C.西瓜 D.火龙果

这时候你会发现，得到的结果大多数都是选择的「B.苹果」

而上面讲到的便是我们输入和选择的一个差异，从结果上来看我们就会发现 输入要更难一些、选择则会更加的容易。

这就像我们在学生时代做的卷子，选择题往往还能动动笔，而到了填空题完全就是一头雾水。

二、实际项目当中的例子 这种情况，在日常的工作当中，有非常多的例子，比如在一个 CRM 系统当中，我们会有一个叫做客户类型的字段。假设最开始把它设定输入框，这时候销售将二次购买的客户录入系统当中，那不同的销售录入出来的结果完全不同。

销售 A：二次客户

销售 B：复购客户

销售 C：老客户

而数据在整个系统当中非常重要，因为我们录入数据的最终目的都是在各个地方使用数据。比如在数据分析页面、数据筛选页面，由于出现了上诉提到的混乱的结果，系统的数据无法正常使用，在管理上就会出现很多问题。

假设把客户类型的字段换做是选择，那这些数据就能够正常使用，并且能够在系统当中我们就能够合理的在各个页面当中利用。

三、输入与选择的定义 通过上面两个例子，我们会发现输入与选择的意义是完全不同的。我们就来看看，输入与选择究竟存在什么定义上的差别。

1. 录入方式上的差异

输入就是提供给用户进行无规则的信息录入，也就是用户想输入什么就可以进行填写。而在输入的过程当中，通常都是通过键盘的方式进行进行的数据提交，这也就意味着输入的难度较大。

选择则是系统预设好的条件提供给用户进行规则的录入，并且在组件的展示当中，都是以鼠标点击的方式来进行的信息录入，它的难度更低，但是选择在系统当中是预设好的情况，也就意味着需要提前预设。如果是一个灵活的 B 端系统，就一定需要在管理后台对于预设的系统进行配置，否则整个系统就缺乏灵活性。

这就是在 飞书 的管理后台系统当中，我们需要单独的配置一些自定义的信息，其中就可以定义选择录入的选项。

当然为了保证系统的灵活性，我们还会为组件去设定一些小心思，就是选择录入时，底部会有自定义选择项的功能，这就叫能够保证用户都有自己想要的选项。

2. 字段属性上的差异

关于两个字段，其实在字段属性上也会存在不同。

首先是输入类型的字段，在整个系统当中，主要针对的是：名称、手机号、地址、邮箱 等，系统本身无法规则化的字段，这时候只能采取输入的形式。

而 选择字段 ，主要是针对的字段是：类型、属性、状态 等，用户能够快速选择的字段，两者在字段设定上存在差异，因此并不相同。

四、选择与输入的作用 关于作用，问大家这样一个问题，你们认为在 B 端系统当中是输入更多，还是选择更多？

我想看完文章过后大家都会觉得输入的限制过多、过于麻烦，因此输入在整个 B 端系统里 录入难度高、规则复杂，只会使用在少数位置来进行使用。同样的逻辑选择则会更为高频使用。

字段，其实是涉及到 前台、后台的页面信息，也就造成关于字段的影响，我们不能单纯从表单一个页面来进行看待。

而表单、表格、详情页本身是一个整体，这些字段的差别，会影响到后面的页面的展示。

比如在表格页面当中，会什么要采取 搜索 而非 筛选？

其实这就是在表单页面当中，如果选择了输入，那在检索的时候一定是 搜索的方式。那如果是选择，那在检索的时候一定是 筛选的方式。

那在其他页面呢？详情页？这个咱们就不多说了。

这其实就是字段的对应关系，在整个系统当中是一个链接的整体，我们在去看待组件的时候，要关注的并不只是组件的样式，而更应该在乎的是组件背后之间的关系。

如果觉得文章还不错，也别忘了点赞转发~

我们下篇文章，再聊~

欢迎关注作者的微信公众号： CE青年Youthce