腾讯云小微 · 智能增长套件

一、C、B 两端联动的设计策略

随着 20 年腾讯组织的调整，架构上来到腾讯云智能产品部体验设计团队，广义上的 ToB 的设计开始多了起来。继续担任 leader 的段时间，我也一直思考如何围绕 C 和 B 两个层面，更好的去解决问题，其中设计管理决策的比例占到近六成。

但我一直认为无论哪种产品设计最终都应该服务好 ToC 的每一位用户个体，ToB 则是在角色层面增加了一个更具挑战的客户维度。

第一层面是 ToB 的数据智能 SaaS 套件产品设计。 它是腾讯自研的产品，设计是产设研中的一环。

第二层面是 ToC 的数智化营销设计服务。 我们作为体验设计团队，为这个套件所覆盖的客户旅程，提供进一步的体验设计优化服务。

两层的先后关系是：先有数据智能 SaaS 产品去服务目标客户——以一汽大众为例；在交付给客户的过程中，我们发现客户自己的 ToC 环节也存在体验问题。于是设计团队介入，补上这一段。

所以这两层是同一件事的两步，不是两个项目。一句话总结：以标准化设计交付为宗旨，打造产品 + 服务、售前 + 交付的双闭环，用设计价值助力业务目标达成与客户成功。

我先讲第一层：这个产品是什么、我在里面诊断出什么问题、怎么解的。

二、什么是数据智能增长套件

先说产品本身。它的全称是腾讯云小微数据智能增长套件，是腾讯云智能产品部整合「腾讯灯塔」和「TAB 实验平台」两支研发团队，打造的全新产品矩阵。产品定义是：覆盖企业全触点，实现数据采集、增长分析、智能洞察和实验优化——腾讯自研，赋能企业用户增长。

它解决的是企业用数据时的三件难事。

洞察难：分析报表看不懂，数据价值挖掘难，可视化组件繁多。
分析难：埋点采集成本高，自建系统周期长，业务诉求多而杂。
实验难：实验准备成本高，实验效果不准确，实验难以规模化。

一次完整的使用分三个阶段：准备数据、创建分析、查看结果。对应两类完全不同的人——

运维人员、数据开发人员、数据分析师，走的是前两个阶段；产品经理、市场、运营，以及最后看结果的老板，走的是后两个阶段。

这个划分很关键，后面设计策略里最重要的两步，都是围绕它展开的：前一类是专业用户，后一类不是。

三、体验诊断与改进对策

我介入的时候，这个产品已经存在一段时间了。摸底之后，问题被归纳成「三低一高」。

品牌认知度低——客户记不住我们是谁。

体验一致性低——套件里几个产品各长各的。AB 实验、数据看板、人群画像原先分属不同研发团队自研，体验流程、界面语言完全不一样——拿出去售卖，体验像四个软件。

标准化程度低——每交付一个客户就重新设计一次，复制不了。

应用门槛较高——存在理解度和易用度问题，一套系统买回去，真正能用起来的人太少。

这四个问题里，有三件产品侧其实看得到，但没有人把它们放在一起，说成"这是这个产品的体验问题"。我做的第一步是诊断：先把问题说清楚，再谈怎么解。问题在哪一层被定义，后面团队的讨论就落在哪一层——如果它一直散在"这个按钮要不要挪一挪"这一层，就长不出一套策略。

诊断之后是四个改进方向：专业化、民主化、标准化、品牌化。每一个都对应前面诊断出来的具体问题，不是四件并列的事。

四、专业化 - 可视化图表的信息设计是核心

第一个改进方向是专业化，它服务于前一类用户——分析师和数据开发。

数据产品有一个跟其他产品不同的地方：可视化图表就是产品本身。用户拿到的结论，是在图表上读出来的；同一份分析结果，用什么图、怎么标、数据多了少了怎么响应，直接决定读图的人能不能拿到准确的结论。它不像别的界面元素，画错了顶多不好看——这里呈现偏了，决策就跟着偏。

在教育和出行行业，我们一边迭代项目交付，一边开展以下三个专项来推进「专业化」的落实。

4.1 确立可视化图表的设计原则

首先是，确立可视化图表的设计原则：直观、准确、多维、易懂。 什么数据用什么图、什么情况下不能用什么图，定死。但原则落不了地，真正起作用的是把原则变成可执行的规则，我举三个例子。

第一个例子：柱状图的宽窄策略。这不是随手调的，它有一条公式：柱宽 D、系列个数 N、网格宽度 W、维度个数 N' 之间满足 D×(N+2) + 1/8D×(N−1) = W/N'，系列间距固定为 1/8D。定完之后还要推敲它是不是通用兼容——多维度、多维度多系列、极少维度、卡片压到最小、卡片拉到最大，五种极端情况都得成立。

第二个例子：轴标签的响应策略。做之前我们看了竞品，结论是分类轴和连续轴要分开处理，而且要看空间够不够：维度是类别的，空间充足就正常显示、不够就换行或倾斜旋转，实在放不下才隐藏或转化；维度是连续数值的，用缩略轴、垂直旋转加省略。有一条是踩过坑才写进去的——维度名是英文的时候，换行会让可用性变差，这条要单独排除。

第三个例子：系统构建交互行为。我们用了穷举—归纳—演绎：先把图表上可能发生的交互全列出来，再以"符合直觉、易于理解"为出发点，定义每个交互的触发动作、触发对象、反馈对象和反馈样式——鼠标移入悬停，图形轻微突出；点击图例过滤某个系列，图形不显示、图例变灰；地图框选放大，比例尺跟着变。然后把这些归纳成一套视觉语言，化繁为简。

这三件事背后的判断是同一个：不只为特定的数据做设计，而要系统地建立一套通用、兼容的展示规则。 一个图表组件要能吃下任意业务的数据，靠的不是设计师每次手工调，是规则本身站得住。

4.2 从专业用户视角出发优化体验

其次是，从分析师的视角反过来优化图表本身。 规则定完，还要回到用的人身上验证——我们访谈了一批分析师，问的很具体：这个数据，你习惯看什么图、你现在看的这张哪里别扭、你想拿它说明什么。举两个来自车厂项目的例子。

TGI 人群偏好分析。 原来的问题是图表不符合分析心智、变量叠加使用不当：在数值比较的场景里，往图形上再叠加位置和面积变量，辨别每个指标的成本增加，数值表达的准确性反而降低。我们给出分面、多层、双 Y 轴三种方案，按开发成本和交付速度评估取舍；单人群视图里，用多维布局把最大的版面留给 TGI，用饱和度较高的位置变量突出它，再用色彩标出偏好高低；对比人群视图里，用分面加双轴线，让 TGI 和人群占比两组对比都足够显著。

会话情绪分析。 它的指标是算出来的——比如"情绪倾向"，由正面情绪人数除以特征情绪人数得出，取值零到四——用户看不懂口径，也容易把满意度得分和情绪值混在一起。解法是：凡是经过计算加工的指标，必须给出统计口径的解释，说清这个数是什么、什么数值代表什么情况；色彩语义对齐真实语义，原来中性情绪用黄色，改掉；满意度得分和情绪趋势分开呈现，再建立相关性。

这两个例子里是同一个动作：从分析师的分析心智出发，反过来约束图表的设计。 它解决的是"专业用户能不能看懂、能不能用对"——一个数据产品连专业用户都用不对，谈别的都是空的。

4.3 普及数据可视化设计理论知识

最后是，把数据可视化的理论知识辐射到整个团队。 团队里不是每个人都懂数据可视化，所以沉淀了一门《数据可视化图表普及课》，在设计团队全员分享学习，项目结束后再复盘总结。图表规范能不能落地，取决于设计的人懂不懂，不取决于文档写得好不好。

到这里，专业化讲完了。它服务的是第一类用户：让专业的人，在专业的场景里，拿到准确的结论。

五、民主化 - 让非专业用户也更易用

第二个改进方向是民主化，它服务于后一类用户——产品经理、市场、运营、老板。这两步不能倒过来：先让专业用户用得对，才谈得上让非专业用户用得了。

民主化做了两件事。

5.1 抽象概念图形化

AB 实验、人群画像这些概念是抽象的，客户在官网上看产品介绍，想象不出它能干什么。我们把这些抽象的分析概念做成图示，有的做成动态图，放在官网和产品介绍里——例如 AB 实验官网，可视化编辑、多网址实验、AI 控流这些能力各配一张插图，还有套件产品的系列插图，让人一眼知道这个东西是干什么的。

这里有个取舍：为什么有的要做成动态图，静态图其实也讲得清楚。因为静态图能说明结构，说明不了过程和变化。AB 实验的关键不是它长什么样，是它是怎么跑的——流量怎么分、结果怎么出来、结论怎么用于决策。这个过程用一张静态图讲，用户还是得靠想象；做成动态，一眼就懂。

5.2 专业术语人性化

文案设计也是产品体验中的重要环节，「 专业术语人性化 」要解决的就是「 不一致、不严谨、不专业、不简化、不理解 」这几类混杂在一起的文案问题。

我们逐个产品建了一张审计表，把四个产品过了一遍，每一条都写清楚：原来叫什么、问题属于哪一类、行业和竞品怎么描述、最后要改成什么。举两个典型的例子：

例如：概念叫法不统一。同一类东西在不同产品、不同页面里各叫各的。一会儿叫"用户"、一会儿叫"人群""用户人群""人群包"，四种叫法统一成"人群包"；"分析人群""对照人群"混着用，统一成行业通用的"目标人群"和"对比人群"——对齐的是友盟、神策这些行业已经在用的提法，不是我们自己拍的。

例如：概念解释有问题。要么根本没有解释，要么技术术语堆在一起看不懂，要么解释得冗长啰嗦，要么表意不严谨、跟行业竞品差别大，显得不够专业。"基准人群"这个概念原来没有任何解释，我们补上一句话，既说清概念是什么，也说清功能是什么；"人群相似度"原来的解释方向不对，改成"对比人群与目标人群的相似程度，百分比越高，两类人群越相似"。

几轮筛查下来，共统计优化了 16 处概念：其中技术术语难理解 7 项、概念叫法不一致 4 项、表意不严谨 2 项、专业度较低 2 项、表达冗长啰嗦 1 项。数字不大，但它说明这件事不是凭感觉改了几个词，是有一张表在管。

另外，还有一个细节：有些字段后面加一个 information 的 i 图标，鼠标 hover 上去就能看到释义，不用点开。点开和 hover 的差别看起来很小，实则是一个判断：点开是一次打断，用户要离开当前任务，看完还要回来；而释义这种东西，用户要的是零成本取用——我想知道的时候马上知道，不知道的时候它不打扰我。

六、标准化 - 产品体验和设计资产的标准化

第三个改进方向是标准化，它对应两个不同的问题，所以我把它拆成两件事。

6.1 产品体验标准化 - 业务层

前面说的体验一致性低，指的是套件里几个产品各长各的——产品框架、交互行为、相似的操作流程和路径，每个团队都按自己的习惯做了一遍。我们做的是把这些共性抽出来，统一掉：产品框架怎么搭、同类任务的交互行为怎么定义、相似流程能不能走同一条路径。

落到具体项目上，四类动作：整合既有产品，把分散的能力收进统一的自研平台，提升搭建效率；把公用流程和原子能力封装成统一插件，供各业务调用；通过标准化建设，把一类业务做成可配置的套件；把控制台层面的通用能力统一。做下来最直接的变化是——拿出去售卖的体验，从像四个软件，变成一个统一套件的体验。

6.2 设计资产标准化 - 原子层

它分两层：原子级的通用组件、控件，和行业级的业务组件。

原子级这一层，我们参与了中心级《ToB 中后台控件设计经验指南》的建设。起因是一个很实际的问题：B 端传统的组件库有局限——它告诉你有什么组件，但不告诉你什么场景该用哪个、为什么。设计师拿着组件库照样会犯错，相似的问题每次都要重新讨论一遍。所以我们换了一种沉淀方式：不只收组件，把使用场景和踩过的经验一起写进去。比如表单，写清楚它包含标题、标签、输入控件、占位符、帮助信息、反馈、行动按钮这些基础要素；按钮文案尽量用"添加""提交""删除"这类确切的词，少用"确定"这种中性的；选填必填怎么标——用户看到表单预期就是"要填"，所以只标选填就够，如果一个表单选填比必填还多，那这个表单的设计本身就有问题；标签对齐也不是一刀切——效率型表单里，顶部标签优于右对齐、右对齐优于左对齐。这样沉淀下来，设计师能直接查阅，不用每次从头争一遍。

行业级这一层，我们参与了公司级 TDesign 的设计组件化建设。TDesign 后来成为开源的企业级设计体系，腾讯各大事业群都在用。同时我们把高复用度的业务组件抽出来——比如智能客服的场景化问答节点、会话列表、节点配置、会话质检标注、欢迎卡片配置——沉淀成组件和流程设计，供同业务、同场景的自研产品复用提效。

内部标准，变成了对外规范。

为什么要拆开讲？因为这两件事性质不同：一个改变的是产品体验交付出来的形态，一个沉淀下来的是可以复用的设计资产。

七、品牌化 - 重塑产品矩阵的 DNA

第四个改进方向是品牌化。套件里六个产品（含未来两个）——DataHub、DataInsight、DataTalk、TAB、DataLink、MixQuery 原先各有各的 logo，各说各的话。品牌化做了三件事：品牌矩阵 logo、品牌视觉物料、品牌宣传动画。

方法上分四步：立调性、定风格、统一语言、沉淀标准范式。先做竞品设计分析和风格定位，把我们的位置钉在"专业严谨、简洁抽象"的象限里，定下品牌调性——智能、专业、可靠；视觉风格——凝练、秩序、硬朗。

统一语言是最关键的一步。我们从一套共性图形元素出发：一个"原子"形，变出正立、倾斜、扭曲、弯折几种变体，六个产品的 logo 全部从这个母形里生成——同源，不同形。每个 logo 同时是产品的隐喻：柱状图是 BI，眼睛是洞察，闪电是引擎。色彩也分三层：增长与动力、智能与极客、专业与可靠，对应三档产品。

这套语言后来用在官网、助销物料和品牌宣传片上——用图形传达产品的愿景，让六个产品对外拧成一股绳。

八、总结回顾

到这里，数据智能增长套件产品设计的故事讲完了。

回顾一下：从"三低一高"的诊断出发，走了四个改进方向——专业化，让专业用户在图表上拿到准确的结论；民主化，把抽象概念图形化、把专业术语人性化，让非专业用户也用得起来；标准化，一头统一产品能力、一头沉淀设计资产；品牌化，把六个产品拧成一张脸。作完之后，这个套件从"几个各长各的产品"，变成了一个对外一致的 SaaS 产品。

但要讲的事到这里只完成了一半。

因为在这一层里，我们已经开始做一些不属于产品体验的东西了：抽象概念图形化做的是官网和产品介绍物料，品牌宣传动画、助销物料也是——那不是产品体验，那是售前物料。换句话说，设计已经在帮这个产品卖自己了。

而更重要的信号来自交付现场。当我们带着这套产品去服务一汽大众这样的客户时，会发现客户的体验问题不止存在于我们交付的那部分——他们自己的官网、小程序、展厅，那些直接面向消费者的环节，问题同样明显，而且是这套数据分析产品够不到、也解决不了的。

所以接下来要做的动作，是沿着同一批客户往前再走一步：把设计从"做好我们自己的产品体验"，延伸到"解决客户旅程上那一段没人负责的体验"。这是第二层，也是下一篇要讲的。