设计平台;To G行业三大平台设计思路,一文掌握

西西木科技-专业的shopify liquid开发机构-前端JS丨react后端丨API接口丨shopify plus外贸独立站

To G行业主要有数据平台、业务中台、运营平台三大平台。 不同平台的侧重点和设计是不同的。 在这篇文章中,作者总结了自己的设计经验,并阐述了如何通过平台来支持产品设计和开发。

当你做产品时间长了,你会有一种感觉:业务需求像滚雪球一样越滚越大,产品功能设计也不断拓展,销售需求变得比翻书还快。 单一产品? 呵呵,根本满足不了市面的大胃王啊! 老板往往一句话就能把你打回原形:“这个产品和之前的差不多,快给我做吧!”

因此,随着产品开发的进展,我们开始进入平台的设计范畴,利用平台来支持产品的设计和开发。

那么,G端行业主要涉及哪些平台做产品呢? 笔者将给大家分享一些我们曾经做过的平台,总结一些设计经验,让大家少走弯路,走更美的路!

1.数据平台设计——有的东西需要有,有的东西需要亮,有的东西需要用 1.所有系统都必须配备数据平台

对于政府领域的信息产品来说,付费者不是使用者。

因此,就会出现两类对产品有不同需求的用户。 业务部门的产品需求自然不用细说。 产品应该易于使用,不应该增加他们的工作量或给他们带来麻烦。 领导层(也就是决定买单的人)并不太关心产品是否好用。 毕竟他不会用。 他更关心产品是否能被看到,能否体现政治表现。

购买的硬件产品是看得见、摸得着的; 施工室、办案室可参观体验; 只是软件产品没有实物,只是一个网站账号,领导很难感知到这个东西的好处。

业务系统虽然只是为业务部门服务,但只要很好地完成产品功能即可。 很多产品经理都有这种“最终用户”思维,这也是一种纯粹的“工匠思维”。 不能说这种思路不好,只能说比较适合C端产品。 G端产品会有一些差异。 如何“包装”产品,让领导直观地感受到shopify搭建,对于政府机构的客户来说,“好看”比“好用”更重要。

我曾经很奇怪,为什么有些客户的微信公众号发布的都是内容。 即使我拿着无人机出去飞来飞去,也没有收集到有效的线索,也没有针对某个案件取证。 其实只是拿出一架无人机到处飞而已。 仅仅这样的事情就需要两张照片才能写一篇新闻文章。 在单位公众号发出。 后来我想通了:做一件事,一定要让大家都知道,一定要让领导看到。

回到产品设计的角度,只要你在做某个业务系统设计,就必须考虑规划数据平台。 这个数据平台可能对业务部门用处不大,但对领导特别有用。

数据平台不仅可以让工作成果让单位领导看到,还可以让单位领导向外部巡视的领导介绍成果。

当然,部门领导也有业务监督管理的需求。 有能够客观、直观呈现的数据就方便多了。 可以及时发现风险并主动干预,也可以作为分析和决策的依据,也可以方便进行绩效报告。 一石多鸟。 你看,数据平台已经成为“刚需”。

2. 3D炫酷——这就是你想要的效果

在TOG市场设计平台;To G行业三大平台设计思路,一文掌握,客户不再满足于二维数据图表,开始涌向秉承“数字孪生”理念,虚实动静相结合的3D数据可视化。

从以往向客户进行产品演示的反馈以及近年来各厂商所做的数据平台案例来看,数据平台设计含义清晰、尺寸正确、布局合理,具有高端炫酷的可视化效果。 ,会更容易赢得用户的关注,获得他们的好评,在产品竞争中脱颖而出,成功中标。

那么,如何让数据平台体现出炫酷的效果呢?

根据我见过的各种可视化数据平台,我总结了一些共同的特点:

出色的视觉呈现是确保数据平台炫酷的关键,但这也意味着使用各种有价值的技术来支持呈现。 下面一段话可以用来介绍数据平台,达到“让领导摸不着头脑、看不懂”的效果。

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

3、不要只追求花哨,要注重实用性

数据平台不仅仅是展示各种炫酷的效果,也不是简单地列出数据图表,而是通过数据分析挖掘出数据中蕴含的模式、趋势和结论。 有效帮助客户发现隐藏在数据背后的问题,预测业务发展的潜在模式。

因此,在设计数据平台之前,需要充分的客户调研,弄清楚:需要建设什么样的数据平台? 数据平台希望解决什么问题,有什么效果,达到什么目的?

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

1)数据分析统计:数据统计的主要目的是帮助领导通过数据全面了解业务,做出科学决策。 在做功能设计的时候,需要根据客户的目的和需要解决的问题来思考用哪些数据指标可以达到用户想要的效果。

2)流程监控和预警:在G端场景中,可以通过对业务异常数据的监控和分析,提供预警和分析定位,帮助领导及时采取控制措施,即确保业务损失得到控制。影响最小化,影响范围也最小化。

可能的监控场景有哪些?

3)实时业务指挥:包括实时指挥调度、任务生成与分发、任意跟踪与执行情况反馈等功能。 可支持文档、图像、音视频等多种命令方式,并可为外部系统数据访问提供标准通信协议。

可以使用哪些设备进行指挥调度?

2、业务中台设计——业务组件化、组件服务化 1、业务中台设计不紧急但很重要

对于推出一年的G端产品来说,迭代成本会逐年增加(当然,一年多没有卖出几套的产品不在我这个话题的讨论范围之内) 。 而且,保证产品内部跨业务线的产品功能的一致性也变得越来越困难。 为了解决这个问题,中间平台和组件将是您的最佳选择。

业务中台的建设就是对各业务线的产品进行抽象和设计,让产品像搭积木一样灵活组装。 基于现成产品组件的复用,可以快速组装新产品,从而节省产品开发成本,高效支持新业务线产品的开发。

由于互联网行业多年来信奉的“快鱼吃慢鱼”的模式设计平台,当人们优先考虑产品功能时,往往会做那些商业价值最明显、能够快速上线带来产品收入的事情。 商务中心是一件重要但不紧急的事情,自然不在大家的任务序列之内。

那么,为什么我们还需要设计商务中心呢? 以下是一些想法:

带来能力积累:软件公司的“固定资产”如何体现? 商务中心就是将多年来积累的产品设计经验,转化为宝贵的“虚拟资产”。 实现快速响应:市场环境瞬息万变,我们不能保证每次都能领先竞争对手一步。 当新业务出现时,即使信息落后于竞争对手,我们也必须能够快速响应并推出新产品。 保证产品稳定性:当一款产品设计的功能模块越来越多时,需要降低模块之间的耦合度,避免某个功能模块出现问题,导致整个产品无法使用,带来灾难性的后果。 提高协作效率:基于业务模块化设计和管理,可以为每个业务产品提供统一的功能模块,无需每个产品经理重新发明轮子,减少产品与研发之间的交互。 2、兼顾业务发展和产品迭代效率

在业务中台产品设计初期,无需针对未来不确定的事件提前进行过多布局。 适度的业务逻辑抽象和灵活的可复用功能设计就足够了。 因为很有可能以后就根本用不到,陷入过度设计的坑了。

在产品利益不明确的情况下,强行采用中端概念设计,不仅会导致业务系统设计过于复杂,还可能导致产品难以使用,增加客户反感情绪。 地面爆炸了。

具体应该做什么?

构建高度包容的产品框架。 业务中心在各个产品框架中应该位于哪里? 与其他功能模块有何关系? 如何支持多种产品、多种应用、多种角色、多种业务业态的功能使用? 这些问题必须建立在充分了解公司业务产品线、梳理整个产品的业务结构、对业务中心进行合理设计的基础上。 用于构建通用性的基本控件和组件。 大多数产品都会涉及到一些通用的功能设计,比如页面导航、数据录入、数据展示、操作按钮、反馈弹窗等组件,大家都可以直接复用。 公共功能模块可以尽快抽象并实现。 例如,基础场馆管理业务线中的产品涉及设备管理、房间管理、拜访管理、远程指挥、记录管理、短信发送、人脸识别、消息提醒、电子签名、系统升级等功能。被提取出来,做成通用的功能模块。 3、用面向服务的思维设计技术架构

这部分内容主要涉及研发人员需要了解的内容。 当然,如果你想成为一名全能的产品经理,能够在认知层面上与研发同学对话,那么你也有必要看看。 。

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

这些服务中心不同于单一系统的模块化。 各个服务中心提供的服务能力不仅仅为前台某个业务系统或场景提供服务,而是支持前台所有场景。

从技术架构设计来看,需要考虑以下几点。

代码和数据库完全隔离。 业务中心和服务中心的代码和数据库独立,通过服务接口实现业务解耦。 这势必针对不同的业务模式和场景具有更好的兼容性和扩展性。 同时可以拥有更快的需求响应能力和更好的产品稳定性。 这极大地避免了代码和数据模型紧耦合导致的应用迭代慢和系统不稳定的问题。 仅提供该业务领域的公共能力。 如果业务领域前端业务的所有需求都在服务中心实现,这些需求必然会夹杂着场景化、个性化的逻辑。 这些个性化需求的逻辑一旦落入服务中心,必然会影响业务对服务中心的扩展。 因此,只有真正具有业务公共共享价值的功能才能融入中台服务中心。 当然,这也需要产品经理尽可能剥离个性化、场景化的需求。 访问仅作为服务提供。 各服务中心提供服务功能接口。 除非有特殊情况,服务中心一般不提供涉及前端用户访问的交互界面。 服务中心之间以及服务与前端应用之间以服务的形式进行交互。 避免用户交互的需要,影响服务中心功能的共享和稳定性。3. 运营平台设计——用配置设计满足多样化需求 1、基于业务多元化发展的流程配置

目前,一些aPaaS厂商,如国内明道云、见道云、氚云等,允许用户无需编码,通过可视化系统页面从头开始构建许多业务逻辑相对简单、通用的企业级应用。 其中,我们常用的钉钉也可以任意组合使用,构建您需要的各种办公审批流程。

零代码或低代码系统设计已成为B端行业应用的主流。 G端其实是B端产品的一个分支。 为此,我们要顺应潮流,与时俱进。 针对业务场景多样化、流程化、可配置化的设计。

设计运营平台时,关键是要理清谁做什么,以及人与物、人与人、物与物之间的联系。 从而输出业务规则和业务流程,不同的业务属性具有不同的任务特征,通过设置业务属性条件可以实现多样化的任务配置。

2、基于客户个性化体验的界面配置

产品在销售过程中,难免会收到各种个性化需求,其中大部分是对产品界面效果、功能布局、文字图标的调整。 毕竟客户不知道如何设计产品功能。 他们只能给几个可见的页面指点一下,打造出与别人不一样的产品效果,这样才能向领导汇报自己的产品采购情况。 也花了很多心思。

因此,在产品(尤其是互联网端产品)的设计中,需要在后台设计界面的个性化配置功能。 这样可以快速满足客户需求,降低研发投入成本,方便产品版本管理。 我们对促销服务云产品实现了PC主页的个性化配置。 未来的指南针产品应该也需要有这样的设计。

可以考虑以下一些界面元素进行自定义配置:

产品/模块名称是可配置的。 对于用户来说,产品要符合当地特色,体现领导喜好,迎合当地政策。 首先要做的就是在产品名称和功能模块名称中反映这一点。 客户基本信息可配置。 对于我们做的G端产品,系统上难免会显示客户单位的名称。 因此,这个客户名牌的配置是必不可少的。 如果涉及到对外宣传介绍的需要,那么客户的资料、地址、联系方式等基本信息必须是可配置的。 页面布局是可配置的。 这个功能对于互联网产品来说更加必要,因为每个人都可以看到互联网产品。 如果界面和其他客户一模一样,难免有些客户会觉得有些不舒服。 当然,并不需要所有的功能页面都是可配置的。 只要人们第一眼看到的登录页面、主页、主菜单页面等主入口页面是可配置的就足够了。

为了减少下发实施的工作量,可以进行一些默认配置。 当然,这些配置功能应该尽可能在我们内部的操作系统上。 不让客户做配置操作,减少了客户的工作量,方便我们集中管理。

3、基于产品灵活销售的功能配置

目前G端市场上的产品大多分为基础版、标准版、高级版两三种型号,甚至还有基于功能模块任意组合的定制版本。 这样做的主要目的是方便制定不同档次的产品报价,满足省、市、区县不同级别客户的采购需求。

要满足这种多版本销售,关键是在产品功能上区分不同版本。 因此shopify搭建,产品的功能模块必须设计成支持定制配置。

定制产品功能配置需要把握以下原则:

如果产品需要分不同版本销售,则必须在产品设计之初就完成功能菜单的配置设计。

最后的话

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

没有“一招打天下”的玩法,只有不断踩坑后得到的一些教训。

西西木科技是shopify官方合作伙伴,通过了Shopify Partner Academy认证,具备多年shopify lic主题开发经验,熟悉Liquid和各项计算机语言。

发表评论