Red Design Darkmode Exploring

yhmnin

🙋🏻‍♂️ Start Now ・开场白

今天，我们来和各位探讨下 Red Design Darkmode 背后的故事，说说我们这些日子做这件事情所思考的点，在满足产品目标的前提下选择合适的设计方案进行快速落地。

众所周知，随着 iOS 13 和 Android Q 的相继发布，对于 Darkmode 的支持变成了应用层的一个特性。通过对 Apple 和 Android 规范的梳理和已适配深色模式的产品分析进行系统性总结，探索输出能够满足小红书深色模式的整体定义和色彩规范文件，有序的开展 Darkmode 的适配工作。

首先，需要明确做 Darkmode 的出发点是什么，是追赶潮流还是注重体验，是为了所谓的省电还是想要用户更加沉浸式的来体验你们的 App，这一切的前提和目标先明确下来，我们再动手来做方案也不迟。

其次，我们需要明确 Darkmode 到底是什么，是所谓的主题变色还是真的从功能特性上出发去做些在暗色场景下更符合的沉浸式设计体验。

小红书对于 Darkmode 适配方案的考虑并非只针对于夜晚等暗色场景，更希望的能够营造一种能够满足于用户需求 light 和 dark 模式随时切换的色彩体验方案。

🤔 How to do・如何做?

从设计侧出发去做这件事情，对于资源的合理配置及整体项目节奏的把控，以及团队人员承担的角色和责任都需要在前期明确下来。此外需要避免角色边界的问题，以项目经理或是产品经理的思维方式来做好沟通和决策作用，确定各端人员排期时间和上线计划，起到团队内部的良好沟通和快速决策的作用。

从设计方案到落地的过程中，项目阶段大致拆分为设计提案 → 设计方案评审 → 技术方案调研并确定 → 技术侧方案的前期落地 → 设计侧的设计走查验证 → 测试走查并修复 → 产品上线并后续迭代等多个环节，接下来我们来实际还原这各个环节的应对方案。

👨🏻‍💻 Design Proposal・设计提案

1. Design Analyses・设计分析

在明确设计目标的前提下，对知乎、Telegram、Instapaper、简书、微信阅读、Bear 等 IM、阅读写作类产品深色模式的分析，明确了 深色模式的场景可以营造沉浸式的阅读体验和独特的视觉美感。无论是 Apple 的 Darkmode 还是 Material 的 Dark Theme，对于 Light 和 Dark 模式下的细节处理需要设计师格外注意。

Apple ・Dark Mode

Apple 在系统色彩方案上定义 Semantic Color 动态色彩方案进行映射调整，并细化色彩使用场景，对于信息层级的分离提供 Materials 材质的方式进行处理，支持 Thick、Regular、Thin、Ultrathin 四种材质，并定义 Base and Elevated 的色彩梯度场景，通过色彩层级关系将内容操作方式呈现更加直观。

iOS 13 提供了新类型 Sheet，目前对于非拍照、录像、修图、文件编辑等场景下，使用 Sheet 能够保证用户信息内容可感知。

Material・Dark Theme

Light 模式通过阴影来构建层级，Dark 模式下通过色彩亮度的方式来构建层次问题（比如叠加不同透明度的白色），同时避免大面积使用用来强调的主题色，并满足 WCAG 的色彩标准规范，保证颜色的可识别性。

2. Design Principle・设计原则

Principle 01

色彩方案需要符合 WCAG 色彩通用性标准：关注特殊人群（视障人群）的使用需求，保证内容的可识别性。需要保证足够的对比度，因为深色背景会吸收其他部分元素的亮度，元素之间要有足够的负空间。文本视觉呈现以及文本图像至少有 7:1（AAA） 的对比度，动态背景下也尽量确保颜色之间的对比度不低于 4.5：1（AA），确保可读性和清晰度。

Principle 02

保证主题色的克制使用：由于界面使用大面积的深色，对于主题色的选用会在整体深色效果下变得视觉比重更大，避免直接使用大面积有明显色彩倾向的背景色。

Principle 03

对于 Dark 模式下的白色元素可以添加黑色透明度遮罩：如小红书商城白色商品图和未做色彩映射的商品详情页和购物车等白色页面需提供统一透明度遮罩的处理方式，保证用户在黑色和白色页面之间切换的体验一致性。

Principle 04

半透明和动态背景效果：使用透明度模糊的处理方式，使前景内容在任何状态下能够保证清晰度。并能够做到跟随背景内容更好的融合，对于内容的呈现和用户心理预期都有一定的帮助。

Principle 05

弱化白色背景颜色：如果必须在黑色背景上使用白色背景，请尽量采用稍暗的白色，防止纯白造成的环境光溢出。尽量避免在深色背景上使用纯白文字，并注意行间距和字间距。Sans-Serif （无衬线体）通常更易读，而 Serif（衬线体）字体看起来更优雅，需要根据实际情况来判断。

Principle 06

需要测试 light 和 Dark 场景下设计方案的兼容性，通过定义色彩名来避免二种模式下的色彩标注，并对一些特殊场景进行定制化的处理方案。

3. Usage・色彩定义和运用

色彩定义

iOS上的默认颜色空间是标准RGB（sRGB）。为确保颜色正确匹配此颜色空间，请确保输出的设计文件使用 sRGB 的颜色配置文件。（Mac 显示器可以将颜色使用 sRGB IEC61966-2.1 显示描述文件。）
对于特定设备，并希望使用的更鲜艳的颜色，或者项目是照片或视频密集型项目，可以使用 P3 颜色配置文件。

参考 Apple、Material、Atlassian、Wechat 和其他一些竞品的灰阶色彩方案，并结合 Darkmode 上对于 Hue 的定义的二种情况，一种是无色彩倾向的配色方案，一种是有色彩倾向的配色方案（Hue 的值为 200-240 之间的蓝色倾向的方案），并在 L 值上进行调整。

小红书 Darkmode 的色彩定义基于 Light 和 Dark 二种模式下的替换关系，并在开发现有色彩命名基础上进行对齐，避免开发的全局替换成本。
并按照场景使用频次定义了 Primary、Secondary、Neutral 三个部分的色彩，并基于 HSL 色彩模型定义了色彩曲线的关系呈现形式，保证了在 Dark 模式下的色彩映射关系的分离度和数量能够满足复杂性的页面使用场景。

色彩运用方式

为了保证全局色彩使用的一致性，在使用规则上也进行了统一的梳理，定义了 Sketch 和 Figma 软件层色彩运用方式的具体规则。

Figma 的色彩 Style 面板通过 Description 来定义描述字段，明确色彩色值和具体使用场景，保证设计师在使用时对于色彩能有全局认知。面对 Light 和 Dark 二种模式下设计，手动标注色值的方式耗时耗力，通过定义 colorName 的方式来进行最终的交付，减少标注和研发理解成本。

色彩方案尝试

在前期定义的色彩映射方案基础上，对小红书主场景页面进行了 Dark 模式下的快速测试，并对正文字段通过一定的色彩调整，兼顾图文笔记长文的阅读体验。

以首页发现 Tab 为例，做了 Light 和 Dark 的映射对比，并通过色彩 Style 的良好定义，保证了方案测试的高效性

🚦定制化规则和其他方式处理

商城和商品图处理方式

1. 大促场景思考

对于商城的双十一、双十二等大促场景样式，对于大促场景下的 Banner 在 Light 视觉的统一性上是相对合理的，但 Dark 模式下整体的视觉样式的呈现就需要重新考虑适配方案，尤其是视觉样式的呈现形式上需要考虑整体的视觉展示形式。对于原先 Light 活动场景下使用大面积红色来营造氛围感的方式，我们将底色按照正常的映射关系调整，并就运营位 Banner 和平面同学就处理方式进行统一协调。

2. 商品图的处理

我们希望全局页面切换和用户体验上能够达到一致性，商城作为主模块之一，需要对其中白色图片上的商品素材进行优化抠图处理，能够保证图片在多色背景下的良好显示。

对于 Dark 模式下商品图的处理，各家电商内 App 没有办法做到背景和商品图很好的分离，我们通过对商家的图片上传要求并结合算法抠图保证了在 Light 模式下商品图视觉的一致性，目前白底图能够有比较大的资源池。

我们尝试了 PS 通道抠图的方式进行步骤还原，并和研发同学就抠图的细节进行讨论，暂时在脚本实现的效果不理想情况下（商品图边缘的处理复杂度以及和背景色的区分界线模糊），目前对商品图通过全局增加透明度遮罩的方式来保证 Dark 模式下的显示效果。

沉浸式的视频和非沉浸的体验统一性

我们暂时将视频、动态图片、全屏大图定义为非必要映射的沉浸式页面场景，将基础页面模块的部分定义为非沉浸式页面需要做色彩映射关系。系统组件进行统一拆分考虑。

视频场景下保留原先的白色的图标和文字的配色方案，并通过在基础灰度色之外增加补丁色满足于视频等 light 和 dark 场景下颜色统一映射的实际需求。

设计流程的重新优化

由于 Darkmode 作为一个新的特性出现在 App 内，需要从设计方案上兼顾二个模式下的设计样式，在图标方案上，我们通过自建图标平台满足于研发在使用二套资源方案上的需求，并将颜色名作为色彩标注方式交付研发，走查环节也需要相对兼顾二种模式下映射关系的正确性

🕵🏻 Design Review・设计验证走查

设计走查阶段为了方便公司整体团队对于走查的节奏和交付方式统一，明确各端的的项目排期，保证整体进度的可控性。

1. 前期设计走查

前期在走查流程的环节上让各端参与的人员能够明确项目的背景，将设计探索的文档进行输出，在设计方案确定并给出相对应色彩映射方案基础上，Native 和 RN 以及 H5 项目研发负责人整体进行全局色彩的统一规范和调整

2. 中期设计走查

该阶段组内设计师根据各自负责的模块进行设计走查，为了保证交付的一致性，在文档和交付流程上前期进行了统一，并制作 Markkit & Flowkit 来规范化手动标注的场景需求，并对标注个格式进行了规范化的文件输出，方便团队成员的格式统一，减少后期的理解成本问题。

需要在各个页面维度上，去拆分系统级控件和页面级控件控件，并对视频和普通页面进行规则的定制处理。并通过定期会有进行进度的 Check，对于项目进度和难点进行集中的记录和讨论。

3. 后期设计走查

在项目将要发布上线的阶段，通过组织测试人员对整体 App 的主流程和边界场景进行测试走查，并记录问题进行修复，在整体最终的设计走查后，和产品侧对发版的节奏和上线的计划进行讨论。

🧠 Design Thinking・设计思考

1. 项目侧

在项目初始阶段，由于产品形态以及工作方式的差异性，需要各个部们就整体项目的成本及必要性做一定的说明，可以将设计说明文档和适配方案进行同步。

由于是从设计侧出发做这件事情，所以需要项目的设计负责人做好各阶段的信息同步和设计决策，各部们在有效沟通的基础上协作来进行整体项目的推进工作。

2. 团队协作

在整个项目的过程当中，需要前期对项目周期、项目排期和固定的研发讨论明确下来，由于涉及到 App 全局性的调整，对于项目过程中遇到的走查环节、测试环节、修复环节中出现的问题，需要时刻注意并给出相应的解决方案。

3. 设计规范

在 Darkmode 的适配上，由于方案的特殊性，所以组件和色彩规定的完整性相对显得比较重要，制定符合公司产品的 Design Guideline 显得尤为重要，通过组件的复用和交付方式的改善，可以在一定程度上保证二种模式下适配和走查的高效性。

🐌 FYI ・题外话

• 在小红书整体项目进程中，对于启动页、服务条款、商城页未做映射的白色页面等场景，因为版本节奏和技术选型方案的问题，会通过后期的不断迭代修复来进行处理
• 由于各产品形态和公司节奏的不同，流程上可能有所差异，这个自身决策就好，本文所述仅当项目落地参考。
• 对于运营性质的活动主题页面或者是运营位 Banner 需要和平面同学在设计表达方式上注意 Dark 模式下视觉呈现的统一性。

🎉 One More Thing

最后，感谢在这过程当中参与的各位产品、设计和研发和测试同学，是你们这几个月的努力让我们能够看到 Darkmode 的真正落地。期待看到过更多适配 Darkmode 的 App，真正体验一键感受新的视觉体验。