在To G行业，有三种大型平台：数据平台、业务中台和运营平台，不同平台的重点和设计都不一样。这篇文章，作者总结了自身的设计经验，给大家讲解如何通过平台来支撑产品的设计和发展。

做产品这事儿，时间长了，你就会有种感觉：业务需求像滚雪球一样越滚越大，产品功能设计也跟着膨胀，销售的需求更是变得比翻书还快。单一的产品？哼，根本满足不了市场这个大胃王！老板经常一句话就把你打回原形：“这个产品和之前那个差不多，赶紧给我做出来！”

于是，随着做产品的深入，我们就开始要进入到平台的设计范畴，通过平台来支撑产品的设计和发展。

那么，G端行业做产品，主要涉及到哪些平台呢？笔者这里就给大家晒晒我们做过的几个平台，顺便总结点设计经验，让大家一起少走弯路，多走花路！

一、数据平台设计——要有的、要亮的、要用的

1.凡是系统必须配有数据平台

政务领域的信息化产品，买单的不是使用的。

为此，就会存在两类用户对产品的不同需求。业务部门的产品需求自然不用多讲，就是产品要好用不要给他增加工作负担，别给他找麻烦。而领导层（也就是决定买单的人）他并不太关心产品是不是好用，毕竟他也不用，他更关心的是产品能不能被看到，能不能体现出政绩成效。

采购硬件产品看得见、摸得着；建设办案用房能参观、能体验；唯独软件产品，没有实体东西，就一个网址账号，很难让领导感知到这东西有啥好。

虽然业务系统只是服务于业务部门，那是不是就只需要把产品功能做好就可以。很多产品经理都是这种“终端用户”思维，也是单纯的“匠人思维”，不能说这种思维不好，只能说更适合C端产品。对于G端产品会有一些不一样，如何把产品“包装”出来，让领导可以直观的感受到，对于政府单位的客户来讲，“看起来不错”比“用起来不错”更重要。

我之前就纳闷，为什么有些客户的微信公众号啥内容都往外发。就是带个无人机出去飞了一圈，没有收集到有效的线索，没有针对某个案件的取证，真的就是带出去飞了一圈，就这么个事情也得整两张照片写篇新闻在单位公众号中发出来。后来我想明白一点，干了活就得让大家知道，就得让领导看到。

回到产品设计的角度来讲，只要你在做某个业务系统设计，就一定要考虑规划上一个数据平台，这个数据平台也许对业务部门没啥卵用，但是对领导特别有用。

数据平台即是让工作成果可以被单位的领导看到，也是让单位的领导可以给外部参观考察的领导做成果介绍。

当然，部门领导也有对业务监督管理的需要，有数据可以客观且直观的呈现出来，还是要方便不少。即可以及时发现风险、主动干预，也可以作为分析决策的依据，还便于作出成绩向上报喜。一举多得。你看，数据平台是不是成了一种“刚需”。

2.3D酷炫——要的就是这种效果

在TOG市场，客户已经不再满足于二维的数据图表，开始对贴合“数字孪生”概念，采用虚实动静结合的3D数据可视化趋之若鹜。

从过往给客户做产品演示收到的反馈，和近些年各厂家做过的数据平台案例来看，数据平台设计在表意清晰、维度正确、布局合理的基础上，高端、炫酷的可视化效果，会更容易博取用户的眼球，获得用户的赞许，在产品竞争中脱颖而出、顺利中标。

那么，怎么让数据平台体现出酷炫的效果呢？

基于看过的各种可视化数据平台，总结出一些共同的特性：

• 采用科技感、科幻感、未来感的颜色搭配，如：紫色、蓝色、深灰色。
• 构建出强烈的空间感，信息填充丰富且饱满。
• 内嵌高精度的3D模型，搭配贴合业务场景的光影。
• 丰富的数据流动、光圈闪烁、远近切换等动画效果。

牛逼的视觉呈现是保障数据平台效果酷炫的首要关键，不过这也意味着要运用各种有含金量的技术来支持呈现。以下这段话可以用来做数据平台介绍的时候，起到给“领导整不会、听不懂”的效果使用。

“通过底层基于光流法的短临预报技术，神经网络深度学习技术，三线性插值的回归算法以及基于WebGL的3D可视化技术，实现数据可视化平台的超酷炫效果。”

3.别只顾着花哨还得注重实用

数据平台不仅仅是展示各种酷炫的效果，也不是简单的进行数据图表的罗列，而是要通过数据分析，挖掘出数据所蕴含的规律、态势、结论。切实帮助客户发现数据背后隐藏的问题，预测业务发展的潜在规律。

因此，在设计数据平台之前，需要充分的客户调研，弄清楚：需要构建什么样的数据平台？构建数据平台希望解决什么问题，起到什么效果，达成什么目的？

我认为，从G端产品过往的设计经验来看，数据平台主要是满足三个方面的需求：数据分析统计、流程监控预警、业务实时指挥。

1）数据分析统计：数据统计的主要目的就是帮助领导通过数据全面了解业务，科学进行决策。在做功能设计的时候，就需要基于客户的目的、需要解决的问题，思考通过那些数据指标可以达到用户想要的东西。

2）流程监控预警：在G端场景中，通过监控实现对业务数据异常预警和分析定位，帮助领导及时采取控制措施，即保障业务损失降至最低，影响范围缩至最小。

可以做到的监控场景有哪些呢？

• 业务监控
• 硬件监控
• 系统监控
• 应用监控
• 网络监控
• 流量监控
• 日志监控
• 安全监控
• 性能监控
• …….

3）业务实时指挥：包括即时指挥调度、任务生成与下发、任何跟踪及执行情况反馈等功能。可以支持文书、图像、音视频等多种指挥手段，可以提供外部系统数据接入的标准通信协议。

可以有哪些设备应用于指挥调度呢？

• 无人机
• 取证车
• 单兵设备
• 对讲机
• 各类场所摄像头
• …….

二、业务中台设计——业务组件化，组件服务化

1.业务中台设计属于不紧急但却很重要的事

上线发展了一年后的G端产品，迭代的成本会逐年增加（当然上线一年多也没卖出去几套的产品，不在我这个话题的讨论范围内）。并且，产品内部要保证各业务线产品功能的一致性也变得越来越不容易。为解决这一问题，中台、组件会是你的不二之选。

业务中台的建设就是针对各业务条线的产品进行抽象和设计，让产品就像搭积木一样灵活组建。基于重复利用现成产品的组件，快速组装出新的产品，从而节约产品开发成本，高效支撑新业务条线产品的开展。

由于互联网行业多年来信奉的“快鱼吃慢鱼”模式，大家在做产品功能优先级排序的时候，往往会倾向于去做业务价值最明显的，可以最快上线带来产品收益的事项。而业务中台属于重要但不紧急的事项，自然就不在大家的任务序列之中。

那么，为什么还要去做业务中台的设计呢？有如下几点思考：

1. 带来能力沉淀：怎么体现出一个软件企业的“固定资产”，业务中台就是把多年积累下来的产品设计经验沉淀下来，变成一个有价值的“虚拟资产”。
2. 实现快速响应：市场环境瞬息万变，我们不能保证每一次都做到领先竞争对手一点，当一个新的业务出现，即使在信息比竞争对手滞后的情况下，也要能够实现快速响应推出新产品。
3. 保障产品稳定：当产品设计的功能模块越来越多，有必要降低各模块之间的耦合性，避免一个功能模块出现问题，导致整个产品无法使用，带来灾难性的后果。
4. 提升协作效率：基于业务模块化的设计和管理，可以对各业务产品提供统一的功能模块，省去每个产品经理重复造轮子的工作，减少产品和研发之间的相互霍霍。

2.既要考虑业务发展也要兼顾产品迭代效率

业务中台产品设计初期，没有必要为未来不确定的事情提前做过多的布局，适度的业务逻辑抽象，弹性的复用功能设计即可。因为很有可能未来根本用不到，掉进了过度设计的坑里。

在没有明确的产品收益的情况下，强行采用中台理念设计，不仅会造成业务系统设计的过于复杂，还可能会给产品的不好用，带来客户怨气值的加压加码，气到原地爆炸。

具体应该怎么做呢？

1. 构建具有高包容性产品框架。业务中台应该位于各产品框架的什么位置？和其他功能模块之间的关系是什么样的？如何支持多个产品、多个应用端、多个角色、多种业态下的功能使用？这些问题，一定是基于对公司各业务产品线有足够的了解，梳理出整个产品的业务架构的基础上，去做出业务中台的合理设计。
2. 建立通用性的基础控件和组件。大部分的产品都会涉及到一些通用的功能设计，比如页面导航、数据录入、数据展示、操作按钮、反馈弹窗等组件，大家就可以直接复用。
3. 共性功能模块可以尽早抽象落地。比如基础场馆管理业务条线上的产品，涉及到的设备管理、用房管理、到访管理、远程指挥、笔录管理、短信发送、人脸识别、消息提醒、电子签名、系统升级等这些功能就可以抽离出来，做成通用功能模块。

3.运用服务化的思维进行技术架构的设计

这部分内容主要是涉及到研发人员需要了解的，当然，如果你想要成为一个全能型的产品经理，能够和研发同学在一个认知水平上展开对话，那么，你就有必要也看一看。

在业务流转过程中，通过对业务对象模型的梳理和提取，建立不同的服务中心，通过各服务中心提供的服务能力支撑前台各类业务场景。

这些服务中心不同于单个系统的模块化，每个服务中心所提供的服务能力并不是单单给前台的某一个业务系统或场景使用提供服务，而是对前台所有的场景进行支撑。

从技术架构设计上，需要考虑到如下几点。

1. 代码和数据库完全隔离。业务中台与服务中心的代码、数据库各自独立，以服务接口的方式实现业务解耦。这样势必能对不同的业务模式、场景有更好的兼容性和扩展性。同时，可以拥有更快的需求响应能力和更好的产品稳定性。大大避免出现因为代码、数据模型紧耦合带来的应用迭代慢和系统不稳定的问题。
2. 仅提供该业务领域的公共能力。如果将前台业务中对业务领域所有的需求都在该服务中心实现，这些需求中不可避免会参杂着具有场景化、个性化的逻辑，一旦这些个性需求的逻辑落入服务中心，势必会影响到服务中心的业务扩展性。所以，只有在业务上真正具备公共、共享价值的功能才能沉淀到中台服务中心。当然，这也需要产品经理尽可能将个性化、场景化的需求剥离干净。
3. 仅以服务方式对外提供访问。各服务中心之间提供服务功能接口，没有特殊的情况，服务中心一般不提供涉及前台用户访问的交互界面，服务中心之间及服务与前台应用间均采用服务的方式进行交互。避免用户交互的需求影响服务中心功能的共享性和稳定性。

三、运营平台设计——用配置化设计，满足多样化需求

1.基于业务多样化发展进行流程配置

当前一些aPaaS厂商，如国内的明道云、简道云、氚云等，用户通过可视化的系统页面，无需代码即可从零搭建出许多业务逻辑比较简单且通用的企业级应用。包括，我们常用的钉钉，也是可以任何组合搭建出你需要的各种办公审批流程。

零代码或低代码的系统设计已经成为了做B端行业应用的主流，G端其实也属于B端产品的一个分支，为此，我们应该适应潮流、跟上时代，对于存在多样化业务场景的流程，进行可配置化设计。

做运营平台的设计，关键要梳理清楚哪些人做哪些事，以及人和事、人和人、事和事之间的联系。从而输出业务规则和业务流程，不同业务属性，有不同的任务特性，通过业务属性条件的设置来实现多样化的任务配置。

2.基于客户个性化体验进行界面配置

在产品的销售过程中，不可避免的会收到各种个性化的需求，其中绝大部分的需求都是对产品界面效果、功能布局、文字图标的调整。毕竟客户也不懂怎么设计产品功能，只能是对看得到的页面指点几下，做出和别人不一样的产品效果，好给领导汇报自己选购产品也是费了不少心思。

因此，在产品的设计上（特别是互联网端的产品），就有必要在后台设计界面的个性化配置功能。这样既可以快速满足客户的需求，也可以减少研发投入的成本，还便于做产品的版本管理。我们在宣传服务云产品上，已经实现了PC端首页的个性化配置。指南针产品，接下来应该也需要做这样的设计。

如下的一些界面元素可以考虑做自定义配置：

1. 产品/模块名称可配置。对用户而言，产品要符合本地的特色，要体现领导的喜好，要迎合地方的政策，首当其冲要在产品名称及功能模块名称上体现出来。
2. 客户基本信息可配置。我们做的G端产品，系统上不可避免要展示出客户单位的名称，因此，这个客户名牌的配置就必不可少。如果涉及到需要对外宣传介绍，那么对于客户的简介、地址、联系方式等基本信息都得做到可配置化的支持。
3. 页面排版布局可配置。这个功能对于互联网产品来讲，必要性会更大，因为互联网产品大家都可以看到，如果界面和其他客户完全一样的话，有些客户难免会感觉有点膈应。当然，也不是需要所有的功能页面都支持可配置，只要做到登录页、首页、主菜单页等第一眼让人看到的主要入口页面实现可配置就差不多了。

为了减少交付实施的工作量，可以做好一些默认的配置。当然，这些配置的功能尽可能都要在我们内部的运营系统上，不要让客户去做配置的操作，减少客户的工作，也是便于我们做集中的管理。

3.基于产品的灵活销售进行功能配置

当前G端市场上的绝大多数产品都是划分了基础版、标准版、高级版两个或三个型号版本，甚至还有基于功能模块任意组合搭配的自定义版本。这样做的目的主要是便于制定出不同档次的产品报价，以便于满足省级、市级和区县级不同级别客户的采购需要。

要满足这样的多版本销售，关键还是在产品功能上做出不同版本的区分，因此，就得设计好产品的功能模块要支持自定义配置。

要做好产品功能的自定义配置，需要把握住如下几个原则：

• 每个可选择的功能都要具有价值。
• 功能之间不重叠、不相互依赖。
• 选择的功能可以保障系统完整正常的运行。
• 未选择的功能在界面的呈现上要不影响到展示效果。

如果产品需要区分出不同的版本销售，在产品设计之初就得做好功能菜单的配置化设计。

最后的话

政务信息化产品的设计不仅要满足业务部门的实际需求，更要从领导层的视角出发，打造出直观、酷炫且实用的数据平台。同时，通过业务中台的组件化和服务化设计，实现产品的快速响应和稳定迭代。最后，运营平台的配置化设计将满足客户的多样化需求和个性化体验，为产品的灵活销售提供有力支持。

没有“一招吃遍天”的打法，只有不断踩坑之后总结出来的一些教训。