SDK 的色彩，应该和宿主端一致还是和主端一致？关于这个问题，或许我们需要从产品战略层进行回答，并根据 SDK 的用户需求与产品目标等维度，来寻求解决方案。本篇文章里，作者便尝试对这一问题做了梳理和解读，一起来看。

SDK，全称是 Software Development Kit，中文为：软件开发工具包，一般都是一些软件工程师为特定的软件包、软件框架、硬件平台、操作系统等建立应用软件时的开发工具的集合。接入方（宿主端）可以借助 SDK 高效率、低成本地实现地图、支付、视频播放、广告、统计等一系列功能。

之前和短视频 SDK 的产品经理们开了一个会，会上提出一个问题：SDK 的色彩到底应该跟宿主端一致还是主端一致，希望设计师从专业的角度给出建议。周末在家梳理了一下思路，给出了我的答案，希望给有类似困惑的小伙伴一些参考。

【资料图】

爱因斯坦说 "问题不能在发生的同一层面得到解答"。所以对于 "SDK 的色彩应该跟主端一致还是宿主端一致？"，我们不能直接从设计的表现层作答，而是要回到产品战略层，根据 SDK 的用户需求和产品目标来寻求答案。

一、用户需求

用户期待 SDK 应该是什么颜色？

通常情况下，SDK 嵌入到宿主端，大多数用户根本分不清哪些功能是 SDK 提供的，哪些功能是宿主端自己开发的。从这个角度来讲，SDK 的功能只是产品功能的一部分，按照系统和 App 设计规范要求，SDK 的颜色应该和宿主端其他功能颜色保持一致。

iOS：色彩应该提供视觉延续性（一致性）；

Android：颜色应该在整个 UI 中应用一致，并与其所代表的品牌兼容；

Origin OS：为用户提供一致的体验，使用统一的视觉表现样式；

App：色彩是第一视觉语言，色彩一致性是最基本的设计原则和要求。

所以，基于用户对 SDK 功能的不可辨识性和产品设计一致性经验，用户期待的 SDK 色彩应该跟宿主端色彩保持一致。

那有没有例外呢？

有。

如果 SDK 存在主端品牌，且主端品牌在行业内拥有数一数二的用户知名度和信誉度，那么，SDK 嵌入到任何产品都可以保留其主端品牌色彩，以符合用户对 SDK 主端品牌的一致性期待。

比如，在移动支付场景中，微信支付和支付宝支付占据了国内约 95% 的市场份额，市场普及率和用户心智都非常强，所以不管宿主端自身的品牌色是什么，在调用微信或支付宝支付时，都会延续支付主端品牌的色彩，以顺应用户心智，如下图所示：

同理，在输入法领域，搜狗的市场份额约 55%，所以任何 App 调用搜狗输入法时，键盘都是搜狗的主题色橙色，这都是匹配用户心智的。

二、产品目标

宿主端接入 SDK 主要是为了低成本高效率的引入 SDK 的功能或服务，完善本品功能和体验，或者获取商业收益。

如果 SDK 主端品牌不直接面向用户，用户知晓度偏低（比如统计类 SDK 友盟、Push 类 SDK 个推，实名认证类 SDK 腾讯人脸识别、广告类 SDK 穿山甲等等），则 SDK 接入到宿主端后，色彩需要跟宿主端保持一致，以避免体验的混乱，如下图所示人脸识别 SDK 和广告 SDK 中的色彩都是跟宿主端保持一致的。

或者 SDK 主端品牌虽然知名，比如语音朗读类 SDK 讯飞和小说类 SDK 掌阅，但可以通过商务合作获取收益，或者希望扩大自己的市场份额，那么他们也会提供色彩定制服务，让 SDK 的色彩跟宿主端保持一致，以鼓励更多宿主端接入。

那有哪些例外情况呢？

一是在某些中小产品上，如果接入（购买）主端品牌色彩的 SDK 成本更低，或者能够带来额外收入，宿主端也可能会牺牲一致性体验来接入 SDK 的主端品牌色彩，以控制成本或增加收益。

二是如果 SDK 主端品牌用户知晓度和信誉度很高，延续 SDK 主端品牌色彩，还可以增加用户对本品的信任感，起到双赢的作用，那就会延续 SDK 主端品牌的色彩，比如前面我们提到的支付类 SDK。

最后小结一下，到底 SDK 的色彩应该跟谁一致呢？

取决于 2 个因素：

产品目标：当 SDK 使用主端品牌色彩，才能满足宿主端产品成本控制和收益目标时，使用 SDK 主端品牌色彩，否则采用宿主端品牌色彩。

好了，关于 SDK 的色彩应该跟谁一致的问题就分析到这里啦。

专栏作家

悦姐聊设计，公众号：悦姐聊设计，人人都是产品经理专栏作家。10 年体验设计经验，崇尚理论指导实践，实践迭代理论，热衷于学习、解构、建构、传播交互设计、服务设计、行为设计等设计相关领域知识。

本文原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。