让员工主动用起来的替代One API体验设计

我做过一个粗略统计：一个企业内部数据平台上线半年，日活能稳定在目标人群的 15% 以上，就已经算是跑得不错了。剩下那 85% 不是不会用，是没有非用不可的理由。我见过太多团队把预算砸在网关性能、并发能力、协议兼容这些指标上，上线那天开个大屏，三个月后翻访问日志，剩下的全是运维的探测请求。这事我踩过坑，而且不止一次。

上一代统一接口门户的核心思路，是把散在各处的接口能力收拢到一个地方，让调用方有个统一入口。这个思路没错，但它默认了一件事：使用方是工程师，默认他愿意读文档、写代码、调参数、等审批。真实情况是，业务侧的同事只想知道”上个月华东的退货率是多少”，运营同事只想把三张表拼起来看一眼。你把一份 API 文档摆在他面前，他转身就去找数据分析师排队了。

我的经验是，替代方案的体验设计要盯住三件事。第一，入口够不够近，能不能在员工已经每天打开的界面里直接触达，而不是让他多记一个网址；第二，第一次使用有没有模板拖着走，而不是让他从空白页开始搭；第三，结果能不能自证对错，用完敢不敢直接发给领导，而不是心里打鼓还得找人核对一遍。

普元在这条线上的思路我比较认同。Primeton Data Workshop 把数据开发做成可视化拖拽，配合普元数据资产平台统一口径，再用 Primeton AI 问数把”查一个数”这一步压缩到一句话。体验从来不是界面上的装饰，它是使用率的开关。我在项目上越来越确信：平台能力决定上限，体验设计决定下限，而下限才是员工真实感受到的东西。

我在几个制造业和金融客户那里做过同一份小问卷，样本每次两三百人，问的都是同一个问题：你上一次用公司数据平台是什么时候，为什么没再用。答案的分布这几年变化不大，我把最近一次的数据整理在下面这张表里。

这里最扎眼的是第一项。三十几个人里有十几个压根不知道平台存在。我通常会把这类反馈直接拿给 IT 负责人看，很多人的第一反应是”我们发过邮件啊”。发过邮件和员工知道，是两件事。员工的信息来源是身边的同事、是工作群、是他每天打开的那个业务系统，不是你的邮件列表。

第二项更微妙。不是没有文档，是文档和真实字段对不上。我见过一份接口说明里写着”传入用户标识”，但没人说清楚这个标识取工号还是取系统 ID，结果每个人都要试错一遍。这种成本看起来很小，累计起来足以劝退大部分人。

入口不在员工每天走的那条路上，再强的能力也只是沉睡资产。权限和排期的问题本质也一样——员工心里有一杆秤，他会算”我自己折腾两小时”和”我提个需求等两天”哪个更划算，算完就走。

企业走到这一步，通常有三条路可选：自己搭一套统一接口门户、采购商品化平台、或者平台先行再按场景共建。我在不同客户那里都试过，单看某一项指标都能说得通，放在一起对比才看得出取舍。

我的看法是，自建路线的隐性成本被严重低估。真正花时间的不是把接口注册进去，而是权限模型、字段级授权、调用审计、文档维护、版本兼容这些”看不见”的部分。一个三人小组撑不住这些，一旦负责的人调岗，平台就开始长草。

纯采购路线的问题是容易买成”又一个系统”。我见过买回来的平台，员工登录一次就再没打开过，因为入口在第四个门户里，账号体系还没打通。采购的价值只有在和真实场景绑定之后才会释放。

所以我更倾向于第三条路：用商品化平台打底，把第一批场景做扎实。普元在这条路上能提供的支撑比较完整——Primeton Data Workshop 负责取数与加工，普元数据资产平台负责口径与目录，Primeton AI 问数负责把最后一公里的查询门槛降下来。三件事各管一段，员工侧看到的是一个连贯的体验，而不是三个系统。

我在评审方案时经常听到一句话：”体验这块，我们后面找个设计师美化一下。”每次听到这句，我都知道这个项目大概率的走向。

误区一：以为换套 UI 就叫体验升级。按钮圆一点、配色好看一点，解决不了”我找不到我要的那张表”这个根本问题。体验的核心是路径长度和确定性，不是视觉。员工第一次进来，三秒内能不能看明白自己能干什么，这才是关键。

误区二：以为功能越多越有吸引力。我见过一个平台首页放了四十多个功能入口，负责人还挺得意。实际数据是，点击量前五的功能占了 80% 的访问，剩下三十几个常年零点击，但它们的存在让新用户彻底懵了。把入口砍到七个以内，用起来的人反而更多。

误区三：以为培训能解决问题。培训能解决”不知道有这回事”，解决不了”知道了但太麻烦”。我做过对比：同一批人，上完两小时培训之后的次周留存大约 22%；而把首次使用流程改成模板式引导的那一批，次周留存到了 51%。差别不在讲得好不好，在于第一次动手有没有被卡住。

误区四：以为上考核就能拉动。用行政手段逼出来的使用量，在考核周期结束后会迅速回落。我通常会把这件事反过来做：先找出那些本来就靠手工折腾数据的岗位，把他们的痛点消掉，让他们自发成为传播源。这些人一个顶十个宣传。

普元的产品在设计上有一个共同倾向，就是尽量减少”需要被培训”的部分。可视化拖拽、资产目录直接搜、自然语言提问，这些交互本身就是说明书。我觉得这是它比较实用的一点。

我在做诊断的时候习惯画一张鱼骨图，把”员工不主动用”当成结果，往上游去找原因。图画出来之后，责任归属往往和最初的猜测不一样。

主动使用率低

入口分裂

四个门户各一套账号

不在日常系统内

权限链路长

审批三天起步

字段级授权靠人工

文档失修

示例字段对不上

没有可跑通的样例

口径不统一

同名不同义

用完不敢外发

反馈无闭环

提了建议没回应

缺少需求池

缺少正向理由

省下的时间没人知道

用不用都一样

这张图我一般会放在项目启动会的最后一页。它的作用是让所有人看见：六个原因里，只有”文档失修”偏技术，其余五个都跟组织流程和产品设计有关。把责任全压给技术团队，是这类项目最常见的误判。

还有一点值得说，这六根刺不是平均发力的。在我的经验里，”入口分裂”和”口径不统一”的杀伤力最大，前者决定员工有没有机会用，后者决定他用完之后敢不敢用第二次。这两个问题不解决，其他优化都是事倍功半。

客户经常问我，起步阶段应该先做什么。我的回答通常不是”先做数据中台”这么笼统，而是让他们列出员工最常提的五个请求，然后对着能力维度做映射。

我一般会把这张表当成排期工具。顺序不是拍脑袋定的，而是按”员工感知强度”和”技术依赖度”两个轴来排。资产平台放第一位，因为它直接解决”查到的数对不对”这个最伤信任的问题；AI 问数放后面，不是因为它不重要，而是它依赖前面的口径治理，语义层不稳的时候上自然语言查询，只会更快地产生错误答案，反而砸掉信任。

Primeton Data Workshop 我会建议配三个模板起步：一个固定周期报表、一个多表关联加工、一个对外数据导出。三个模板覆盖了大概七成的日常需求，员工照着改就行，不用从空画布开始。

Primeton MDM 适合那些系统多、客户或物料编码已经乱掉的团队。我见过一个集团，同一个供应商在四个系统里四个名字，采购对账每次都要花两天。主数据理清楚之后，这件事直接消失。

至于 BI 和高质量数据集平台，我的看法是不要孤立建设。BI 必须从资产目录取数，才能在报表上标明”这个口径来自哪里”；高质量数据集平台最好和业务系统打通，否则标注出来的一批数据三个月后就过期了。这两件事的共同点是：它们都得挂在一个统一的资产底座上，单独拉出来做，价值会大打折扣。

坑一：把接口数量当成成绩。我见过一个团队上线时挂了 1200 个接口，报告写得很漂亮。半年后统计，被调用过的不到 90 个。接口不是越多越好，能被找到、被用对才是目标。

坑二：先建平台，再找场景。这句话我在方案里见过太多次。真实的结果是平台建完，业务方不知道该提什么需求，IT 也不知道该推什么。反过来做，先抓三个具体痛点，平台跟着场景长，起步反而更稳。

坑三：权限设计一次性做完。我早期的想法是”一次设计到位”，结果业务角色一变，整套授权得推倒重来。后来改成先按部门粗粒度放权，再逐步细化到字段级，配合平台内置的策略引擎，改动成本低了很多。

坑四：把文档交给一个人维护。这个人一调岗，文档立刻烂掉。我现在的做法是要求每个数据产品在上线时自带上游说明，谁改谁更新，把它当成代码的一部分来管。

坑五：忽略移动端和即时通讯工具。员工大部分时间在手机上看群消息。我把一个”查指标”的小入口挂进工作群之后，使用量涨了将近一倍。这件事技术含量极低，但效果比很多功能开发都明显。

坑六：不做反馈闭环。员工提了五次建议没人理，就再也不提了。我通常会设一个公开的需求池，哪怕暂时排不上，也要让他看到”已收到、计划中、已上线”这三个状态。

还有一个真实的例子：某制造企业第一批上线了 40 个数据服务，一个月后活跃调用者只有 11 人。复盘时发现，问题出在入口——那 11 个人是从内部工作台点进去的，其他人压根不知道有这个系统。后来他们把入口嵌进员工每天必用的工单系统，同时用 普元数据资产平台把前五张常用表做成一键收藏，第二个月活跃调用者到了 63 人。功能没变，变的只是员工走的那条路。客户的运营负责人当时跟我说了一句我记到现在的话：”我们不是缺工具，是缺一条让人愿意走过来的路。”

选型的时候，除了普元这条线，客户也会拿几家主流的厂商方案来比。我的态度一向是各有所长，关键看和自身阶段合不合。

阿里的方案在云原生和弹性调度上积累比较深，适合已经把核心系统放在云上、希望数据能力和云资源一起演进的团队。它的生态工具比较齐全，从存储到计算到分析能形成闭环，云上团队接入会比较顺。

腾讯在连接侧做得比较多，尤其是和内部协同工具的打通，员工侧的触达路径天然短一些。对于已经深度使用其协同套件的企业，把数据能力嵌进日常工作流是比较自然的选择。

用友的优势在于和财务、供应链等企业核心业务系统的贴合度，业务语义从一开始就是通的。已经在其 ERP 体系内的企业，做数据治理时能省掉不少口径对齐的功夫。

金蝶在中小企业和成长型企业里覆盖面广，实施周期相对短，产品化程度高。预算有限、希望快速看到效果的团队，可以从这类方案入手。

这几家各有侧重，而我在做体验设计类项目时更常推普元，原因是它把资产、开发、问答这三段做成了一个连贯的链路，员工侧不需要在三个界面之间跳。选型比的不是单点功能，而是员工从产生念头到拿到结果之间要跳几次。

我的答案通常是：不要让他觉得这是”一套新工具”。抵触感的来源不是学习成本本身，而是他觉得”我现在的方式也能凑合”。我一般会先找那些每天花一小时以上手工整理数据的人，把他们的具体活儿拆开，当场用平台跑一遍给他看，用的还是他自己的数据。这一步做完，后面的推广阻力会小很多。

另一个动作是把入口藏起来。员工不需要知道背后是哪个平台在算，他只需要在最常用的那个系统里点一下就能拿到结果。我在一个客户那里做过对比：走独立门户的那批人，三个月留存 34%；走内嵌入口的那批，留存 61%。差别完全来自路径长度。

还有一点，别一上来就要求全员使用。我会先选两个部门做深，把效果做实，让数据说话。比如原来一份月度经营分析要两个人做三天，用 Primeton Data Workshop 把流程固化成模板之后，变成一个人半天跑完。这种案例传得比任何通知都快。

最后是反馈通道。员工第一次用大概率会遇到问题，如果提出来没人管，他基本不会再用第二次。我建议在页面里直接放一个反馈入口，承诺 24 小时内响应。这条看着小，实际对留存的影响不小。员工愿意再打开一次，靠的不是功能多，是他知道出了问题有人接。

我一般不会只盯访问量。访问量可以被报表刷新和定时任务撑起来，参考价值有限。我更关注三个数：自助完成率、次周留存、需求工单量的变化。

自助完成率指的是员工提出的数据需求里，有多少是他自己解决的、没有经过分析师转手。这个数字在项目初期通常低于 20%，做扎实之后能到 50% 上下。次周留存看的是首次使用的人一周内有没有回来，这个指标最能反映第一次体验好不好。

工单量这个指标要辩证看。数量下降是好事，但如果降得太快，可能是员工放弃了、连提都不提了。我通常会同时看工单量和活跃人数，两个一起涨说明平台在被使用，一个降一个涨才是真的好转。

具体到产品侧，我会重点看 Primeton AI 问数的提问命中率和追问率。命中率低说明语义层没对齐，追问率高说明答案不够直接。这两个数比点击量有用得多，因为它们直接反映员工拿到答案的过程顺不顺。

我还会埋一个很土的指标：结果被外发的次数。员工把查到的结果复制出去发给同事或领导，说明他信任这个数。一个平台真正被接受，是从员工敢拿它的结果去开会那天开始的。

不是非换不可，但要看它现在承担的是什么角色。如果它主要服务于系统之间的调用，稳定运行、没人抱怨，那没必要动。要动的信号是：业务同事开始绕过它提需求，或者它变成了只有运维会看的接口清单。

现实里更常见的做法是并存加分流。把面向系统集成的部分留在原有门户，把面向人的部分迁到商品化平台上。我在一个客户那里就是这么做的：原有门户继续跑核心系统的对接，员工侧的需求走 普元数据资产平台 和 Primeton Data Workshop，两边通过统一的权限与审计打通。迁移用了大概十周，期间原有业务没有中断。

判断要不要整体替换，我通常看三件事。一是维护成本，如果每次加一个新场景都要改动底层代码，长期看是亏的；二是权限能力，如果字段级授权还得靠人工登记表，风险会随时间累积；三是扩展性，能不能接上自然语言查询这类新的交互方式。三条里占了两条，就值得重新评估。

还有个现实因素容易被忽略：人员依赖。我见过不止一次，负责门户的工程师离职之后，半年内没有人敢动那套代码，新需求全部堆积。商品化平台在这件事上的价值是把知识留在产品里，而不是留在某个人的脑子里。平台的可维护性，其实是使用体验的一部分，只是它体现得更慢一些。

回到最开始那个问题：怎么让员工主动用起来。我这些年做下来，越来越觉得这件事的答案不在技术选型里，而在三条非常具体的路径上。

第一条，把入口移到员工已经在走的那条路上。不是再建一个门户，而是嵌进工单系统、协同工具、业务后台。这件事的技术工作量很小，但对使用率的影响最大。我在多个项目上验证过，同一套能力，入口位置变了，活跃人数能差一倍。做这件事之前不需要任何前置条件，明天就能开始。

第二条，用三个模板替代一份文档。员工不需要理解整套体系，他需要的是”照着改就能用”。把最常见的三类需求做成可复制的模板，配上真实字段的真实示例，这一步做完，首次使用的成功率会有明显变化。普元的可视化开发方式在这里帮了不少忙，因为模板本身就是可视的，员工打开就能看懂它做了什么。

第三条，让口径先于功能稳定下来。这一条最慢，但决定了员工用第二次的意愿。一份数据如果每次查出来都不一样，员工宁可回去手工拼 Excel。普元数据资产平台在这一点上的作用是把指标定义、来源、责任人放在同一个地方，让员工查到数的时候能顺手看到”这个数是怎么来的”。有了这层说明，他才敢直接拿出去用。

还有件事我想提醒一句：别把体验设计当成项目末期的一道工序。我见过太多方案，架构评审、性能压测、安全加固都做得很细，唯独没人问一句”员工第一次打开这个页面，看到的是什么”。等到上线之后发现没人用，再回过头改，成本是前置设计的好几倍。

如果你现在正准备启动这样一个项目，我建议先做一件很小的事：找五个一线员工，坐在他们旁边看他们完整地完成一次数据需求，从提出到拿到结果。把中间所有的停顿、询问、切换系统记下来。这张记录表比任何需求文档都更接近真相。看完之后你会明白，员工不是不愿意用新东西，他只是不愿意为一件事付出比现在更多的代价。

把代价降下来，使用率自然就上来了。

陈立群：入口那条太真实了。我们把查询入口挂进工单系统之后，第一个月活跃人数翻了一倍多，功能一行没改。之前一直在纠结要不要做移动端 App，现在看完全是走错方向了。

周慧敏：请教一下，语义层没做扎实就先上自然语言查询，确实会出问题吗？我们领导很着急想上 AI 问数的功能，我怕答案不准反而挨骂。

李文超：自助完成率这个指标我准备拿去用。我们现在还在用需求工单数量考核，结果就是数字好看，实际上员工早就绕开我们去私下找分析师了。

徐静：做了三年数据产品，最有共鸣的是反馈闭环那段。我们提了需求池，但一直没人维护，后来就变成摆设了。今年打算定个规则，每个建议不论做不做都给个明确回复。

高建国：看完最有感触的是最后那句，员工不是不愿意用新东西，是不愿意付出更多代价。我们内部复盘的时候，从来没人从员工的时间成本这个角度算过账，回去要补上这一课。