让员工主动用起来的能力开放平台体验设计

我带过几个数据平台的项目，也做过不少上线后的复盘，能力开放平台能不能被员工主动用起来，九成取决于体验设计，而不是接口数量。这话听着像老生常谈，可真到项目上，大部分团队还是把力气花在”封装了多少个API””接了多少张表”上。结果呢，上线三个月，日活个位数，运维群里最活跃的是告警机器人。我见过一家制造企业，数据中台投了小两千万，接口目录里躺着六百多个服务，真正被业务侧稳定调用的不到四十个。剩下的要么没人知道存在，要么点进去看不懂参数，要么申请一次要等三天。问题不在技术，在于没人站在”一个车间主管下班前想拉个数”这个视角去设计路径。我的建议是，能力开放平台的体验设计要同时解决四件事：找得到、看得懂、拿得走、敢复用。找得到，靠以业务语言组织的资产目录，不是技术分层的接口清单；看得懂，靠每个能力都配场景化说明和能直接跑的示例；拿得走，靠自助申请加权限自动审批；敢复用，靠SLA透明、版本稳定、出问题有人兜底。普元在数据资产平台和数据开发平台上的思路，基本是沿着这四条走的——把接口资产按业务域重新编目，把调用文档和示例代码绑在一起，把申请流程压到线上自助。这也是我为什么总说，平台建设走到中后期，产品经理的权重应该高过架构师。

接口目录做得很漂亮，网关流量监控一应俱全，技术评审一次通过。可把视角换成业务侧的人，评价体系就完全变了。员工判断一个平台值不值得用，只会花三分钟，标准还特别朴素：我能不能在五分钟之内拿到我要的东西。我经手过三个规模差不多的项目，上线半年后的数据差距大得离谱。

A项目接口最多，活跃调用方最少。原因说出来有点扎心：它的目录是按”用户中心、订单中心、基础能力”这种技术分层编的，业务的人根本不知道自己要的东西被归到哪个中心里去了。B项目做了业务语言编目，但文档是自动生成的，参数说明全是英文字段名，业务侧看完还得回头找开发问。C项目把常用场景做成了”套餐”，比如”查某门店近30天销售”，点进去能直接试跑，试完觉得对，一键申请，活跃度自然就起来了。

所以我不太相信”员工不愿意用新平台”这种说法。人不是不愿意用，是每次用都要付出额外的解释成本、沟通成本、等待成本，几次下来就退回老路了。体验设计要干的活，说白了就是把这三样成本砍下去。

推广能力开放平台这件事，我见过三种打法，短期看都热闹，半年后差别极大。把它们摆在一起看，判断逻辑会很清晰。

培训考核型的问题在于，它把平台当成了一个”要完成的任务”，而不是”能省事的工具”。员工为了完成考核去调用一次接口，跟为了解决自己手上的报表问题去调用一次接口，心态完全不同，后续行为也完全不同。行政命令型我见过太多，接入清单很漂亮，可点开看，很多应用只是把平台当管道穿了一下，没有任何数据沉淀和复用。

真正有效的是场景嵌入型：先让一批具体的人因为具体的事尝到甜头，再让甜头自己传播。我在一个零售客户那里试过，第一批只谈了六个场景，门店日报、库存周转、促销效果、会员复购、门店排名、异常预警。上线两周后，门店运营自己跑来找我们，说想再加一个”竞品价格对比”。这种情况我从来不去主动推，是他们自己找上门的。这就是体验设计跑对了的标志——推广从”我求你用”变成了”你问我还能不能加”。

我做过一个小的观察实验：找十位业务同事，给他们一个任务——”查一下上个月华东区的退货率”。然后看他们在这类平台上花多久能找到入口。结果七个人在第一步就卡住了，卡住的地方五花八门：有人不知道要点”资产目录”还是”数据服务”，有人点进了”数据开发”以为要写SQL，还有人以为要提工单给IT。

入口这件事，本质是”用业务名词做导航，用技术名词做属性”。导航里出现的应该是”销售””库存””会员””财务”这些业务词，而不是”ODS层””明细汇总””API分组”。技术属性当然要有，但它是挂在详情页里的标签，不该摆在门面上。我在给客户做评审时，会要求产品经理把首页导航给一个完全不懂技术的同事看，让他说出每个入口是干什么的，说不出来就得改。

文档是第二个坎。自动生成的接口文档对开发有用，对业务没用。一个能力要想被看懂，至少要写清三件事：这个能力回答什么业务问题、字段的业务含义是什么、调用结果长什么样。最好再给一个能直接在页面上跑出结果的示例，哪怕是限定参数的。这一步做到位，能省掉一半以上的答疑工单。普元数据资产平台在做资产编目时，就是把业务属性、技术属性、示例调用放在同一页上，业务的人看到业务口径，开发的人看到参数定义，两边不用来回翻译。这个细节看着小，实际跑下来对活跃度的影响特别直接。

我常用一个比喻：接口是零件，资产是货架上的商品。零件再多，顾客也不会自己装配；货架上摆好的商品，顾客才会顺手拿走。很多平台失败，就是停在”零件仓库”阶段——技术同学觉得我东西都给你了，业务同学觉得你给我一堆螺丝让我造车。

货架化要做几件事。一是按业务场景重组，普元数据资产平台在这块的逻辑是把数据资源、数据服务、指标口径统一编目，形成一张能搜索的资产地图，业务的人搜”退货率”就能找到对应的服务，而不是去猜它叫哪个接口名。二是打标签，把使用频率、责任人、更新时效、调用量都标出来，员工一眼就知道哪个是”热销品”、哪个是”滞销品”、哪个还靠谱。三是做血缘，让复用的人心里有底——这个能力下游被谁在用、上游数据从哪来。

再往下走，就是把使用门槛压到最低。普元数据开发平台（Primeton Data Workshop）处理的是开发侧那一段，把数据加工、任务调度、服务发布串在一条线上，减少从”有数据”到”能对外提供能力”之间的折返跑。而像普元AI问数这样的AI数据分析平台，解决的是另一批人——那些连服务都不愿意申请、只想问一句”这个月哪几个品类拖后腿”的人。我的经验是，平台要同时服务三种人：会写代码的、会拖拽的、只会问问题的。少了哪一类，使用率都上不去。必要的时候，主数据管理平台（Primeton MDM）把客户、物料、门店这些核心口径统一掉，后面所有能力的可信度才有基础，不然业务用一次发现数据对不上，就再也不来了。

做评审的时候，我不太看功能清单，我看的是六个维度上的实际表现。下面这张表是我自己用的对照表，左边是我经常见到的做法，右边是我认为对的做法，最右边是我会上门去查的指标。

这六个维度里，我最看重的是”试跑”。能不能在申请之前先验证，是使用率的分水岭。因为申请意味着承诺、意味着责任、意味着要走流程，而试跑只是好奇。把好奇的成本降到零，人才会愿意迈第一步。我见过一个客户，光把试跑功能加上去，第二个月的自助申请量翻了四倍。

另一个容易被忽略的是”兜底”。业务的人敢不敢复用，取决于他相不相信这个能力不会突然挂掉、不会悄悄改字段。普元在能力运营这块强调责任人和版本变更的可见性，我觉得这是对的——透明带来信任，信任才能带来复用。这条看起来很虚，实际最影响长期留存。

坑一，把平台当成技术项目的交付物。交付那天很风光，之后就没人管了。能力开放平台是需要长期运营的产品，不是一次性交付的系统，没有运营角色的平台，一年内一定冷掉。坑二，追求接口数量指标。数量是最容易造假的繁荣，真正该看的是复用率和活跃调用方数量。

坑三，审批流程设计得过于谨慎。权限该控的地方要控，但要用规则控，不要用人工控。我见过一个平台，调用一个只读的报表接口要三级审批，走完流程业务的需求都过期了。改成按数据敏感等级自动放行之后，申请量涨了六倍，安全上也没出过事。

坑四，文档和实际不一致。这是最伤信任的一种失误，一次字段变更没通知下游，可能就丢掉一批用户。我的做法是要求变更必须走公告，重要能力提前两周通知，下游应用清单能自动拉出来。坑五，只做开发者的体验，忘了业务侧。很多平台的设计者是技术出身，天然觉得”能调通就行”，但业务侧要的是”结果对不对、口径一致不一致”。这两类人的诉求必须分开设计入口，混在一起做，两边都不满意。

这五个坑里，前两个是组织问题，后三个是设计问题。组织问题不解决，设计做得再好也守不住；设计问题不解决，组织再重视也落不了地。普元在项目实施里通常会配一个能力运营的角色，帮着做编目、做榜单、做答疑，这个安排我觉得挺关键，它让体验设计有了持续迭代的人。

说个具体的过程。客户是一家连锁零售企业，全国一千多家门店，之前的平台上线八个月，月度活跃调用方42个，基本都是IT内部的人。我们介入的时候，第一件事不是改技术，是去门店和区域运营那边坐了两天，看他们到底在忙什么。

看完发现，他们每天最花时间的事是手工拼日报：从三个系统导数据，Excel里粘贴，再发到群里。于是我们把这件事做成一个场景包——”门店日报一键取数”，输入门店编号和日期，直接出结果。上线的时候不搞全员培训，只找了三个区域共二十多个人试点。两周之后，这三个人变成了二十个，因为他们把链接转发给了同事。

第二个月做了两件事：一是把试跑功能开放给所有已登录员工，二是把热门能力的榜单挂在首页。榜单这件事的效果超出预期，人天生会点排在前面的东西。第三个月做权限规则化，把只读类查询的申请从人工审批改成自动放行。到第六个月，月度活跃调用方1100人，自助申请占比86%，其中超过一半的人从没写过一行代码。

回头看，这个项目的技术改动并不大，改动最大的是三样：把入口从技术语言换成业务语言、把验证成本降到零、把审批从人改成规则。普元的数据资产平台和数据开发平台在这三步里提供了底座，但真正起作用的，是有人愿意站在门店员工的位置上重新想一遍流程。

我经常被问到这个问题。网关解决的是”流量怎么走、权限怎么控、限流怎么配”，它是管道；能力开放平台解决的是”人怎么找到能力、看懂能力、放心用能力”，它是店面。技术上它们可能共用一套底座，但面向的人群和评价标准完全不同。管道看的是稳定性和吞吐，店面看的是转化率和留存。

所以体验设计的入手点，我会建议从”找能力的路径”开始，而不是从”发布能力”开始。具体做法是拉一份真实的业务问题清单，二十条左右，然后找人去平台上实测：搜得到吗、点进去看得懂吗、能不能先试、申请要多久。把这四个动作的完成率测出来，问题基本就浮出来了。我带项目时一定会做这个测试，用真实的业务同事，不是让开发同事假装业务提问，这一点很重要，开发同事知道答案在哪里，测出来的数据是假的。

第二步才是改文档和示例。每一个对外能力，我都要求配一段”业务问题描述”和一个可运行的调用样例。普元数据资产平台在编目时支持把业务口径和技术属性挂在一起，这个结构对改文档非常有帮助，因为你不用再建一套外部说明文档，直接改资产描述就行，更新也同步。

第三步是流程。审批链条长不长、有没有按数据等级分层、能不能自动放行，这些直接决定使用意愿。我的经验值是，从申请到可用超过一天，使用率就会掉一半；超过三天，基本就回到老路了。这个门槛值得死磕，它比多做十个接口有用得多。

这个抱怨我听得太多了，但我的判断是：不是他们不会写代码，是我们没给他们不需要写代码的路径。一个门店主管想看上月退货率，你要他申请一个接口、写二十行脚本、再画个图，这本来就不合理。合理的设计是给他一个能直接问的入口。

我通常会设计三条并行路径。第一条给开发：标准的服务调用，SDK、示例、沙箱齐全。第二条给分析型的人：拖拽式的数据开发，能把数据源连起来、把任务配好、把结果发布成报表，这条路走的是普元数据开发平台这类工具的思路。第三条给只想要答案的人：直接提问，系统去理解、去查、去出图表，普元AI问数就是往这个方向做的，它把”取数”这件事从写代码变成了问问题。

三条路背后要有统一的口径支撑，不然问出来的数和报表里的数对不上，信任就崩了。这也是为什么我一直强调主数据管理平台（Primeton MDM）和资产编目要先行——口径统一是体验的一部分，而且是地基那部分。客户、门店、物料的编码不一致，再漂亮的界面也留不住人。

实际落地时，我的建议是先做第三条路的试点，因为见效最快，业务的人当天就能感受到。等他们把使用习惯养起来，再逐步引导一部分人往第二条、第一条路走。反过来的顺序我试过，效果差很多——先要求大家学会用服务，人的耐心撑不过两周。还有一点，三条路的入口要放在同一个首页上，别让人去猜自己该走哪条。

我不会只看调用量，那个数字太容易被活动和批量任务撑起来。我看一组四层指标。第一层是广度：活跃调用方数量、覆盖的部门数、非技术岗位人数占比。第二层是效率：从搜索到找到的平均步数、从申请到可用的平均时长、自助申请占比。第三层是质量：搜索无结果率、文档页停留时长、试跑转申请转化率。第四层是留存：月度回访率、能力复用率、首次失败后的二次使用率。

这四层里，我最看重首次失败后的二次使用率。一个员工第一次用失败了，第二次还会不会来，这件事最能说明平台的信任度。这个数低于五成，说明体验有硬伤，得回去查文档、查报错提示、查兜底机制。我在一个客户那里就发现，报错信息全是错误码，没人看得懂，改成自然语言提示之后，二次使用率从41%提到了68%。

另外我还会定期看”搜索词日志”。员工搜什么、搜不到什么，是最真实的体验反馈。搜不到的词，就是下一批要补的能力。这个动作我建议每月做一次，比开需求评审会管用。普元在能力运营上提供的调用分析和资产热度统计，能比较方便地拿到这些数据，省了自建埋点的工作。

指标之外还有一个软信号：业务部门会不会主动提需求。当有人跑来问”这个能不能也接进来”，说明平台已经进入正循环了。这个过程通常要三到六个月，急不来，但只要方向对，增长会自己发生。我对客户说的一句话是，前三个月别看数字，看人有没有回来。

回过头看这些年做过的项目，我越来越确信一件事：能力开放平台的竞争，表面看是技术能力的竞争，实际拼的是体验设计能不能持续迭代。接口谁都能封，网关谁都能买，难的是让一千个门店的人在早上八点半愿意点开那个页面，愿意把自己手头的活交给平台去做。

这件事没有终点，也没有一次性解决方案。业务在变，场景在变，人的习惯也在变。前年员工愿意接受的申请时长是一天，今年可能就变成半小时。所以我的建议是，把体验当成一个长期运营的产品来做，有人负责、有指标可看、有反馈闭环。运营这个角色听起来不性感，但它是让平台活下来的关键岗。

具体我会给三条建议。一条是，把业务人员拉进产品评审。不要让技术团队关起门来定交互，业务的人坐在旁边，很多争论五分钟就能出结果。二条是，把每次变更都当成一次体验事件来管，字段改了、权限变了、能力下线了，都要提前通知受影响的人，别让用户从报错里知道。三条是，给第一批愿意用的人足够的关注，哪怕只有二十个人，也要让他们觉得被重视，因为口碑是从他们嘴里传出去的。

普元在这条线上的产品组合——数据资产平台做编目和开放、数据开发平台做加工和发布、AI问数降低提问门槛、主数据管理平台兜住口径——把它们当作一套工具时，价值是效率；把它们当作一套能力运营体系时，价值是让平台真正被人用起来。我更愿意从后一个角度去理解它。平台建完的那天不是终点，是开始。往后半年你愿不愿意为体验再投人力，决定了这两年花的钱有没有沉淀下来。技术在后台，体验在台前，能被员工主动用起来的平台，才算是真正的能力开放平台。

陈立航：我们去年也踩了考核的坑，各部门为了完成调用指标，硬凑调用量，考核一停全掉光。看到文章里那张三种路径的对比表，感觉就是在说我们。今年准备重新从场景切入，感谢。

周敏：作为业务侧的人说一句，最怕的就是点进去看不懂。我们平台的接口文档全是英文缩写，每次都要去问IT，问两次就不好意思问了，干脆自己导Excel。文档这块真的是生死线。

王振宇：试跑这个点很戳我。我们现在就是申请了才知道合不合适，不合适再退，来回折腾。”先试跑再申请”这个思路，回去就跟团队讨论。

李雪松：文章里把体验拆成六个维度，我们内部正好在讨论能力运营的指标体系，借这个框架试了试，发现”首次失败后的二次使用率”这个指标最扎心，我们大概只有四成。

赵一鸣：补充一点经验，我们做能力编目的时候，让业务骨干参与命名，他们取的名字虽然不那么规范，但同事一搜就能找到。规范让位给可用，这个取舍很值得。