当前位置: 澳门新豪天地3559 > 互联网 > 正文

后台产品设计的那点事

时间:2019-06-27 02:37来源:互联网
未来商业都是要围绕着人展开的,广义的讲所有业务的产品都可以纳入CRM,CRM将是各大平台或商家适应未来商业环境的基础标配。 ** ▍ ** 一、版本迭代记录** 说到后台产品,总会有几

未来商业都是要围绕着人展开的,广义的讲所有业务的产品都可以纳入CRM,CRM将是各大平台或商家适应未来商业环境的基础标配。


****一、版本迭代记录**

图片 1

说到后台产品,总会有几个绕不开的“问题”:后台也需要产品经理?后台产品也需要用户体验?做后台也需要挖掘需求?

版本迭代记录模板

什么是CRM

从某种意义上而言,这并不是疑问,而是质疑,好像默默无闻的后台产品比起光鲜亮丽的前端,差了几个数量级。但实际上,产品经理要负责的,远远不仅是产品新人句句不离的“用户体验”,后台产品的设计,也是有很多没有真正涉及就难以熟悉的问题。

表格形式记录产品各个版本的需求list,优先级,现在有什么问题,产品如何解决问题,以链接的形式跳转到原型相应位置。如果问答有变更,在需求发生变更出填写并说明变更原因。事实上和下面的文档变更记录是一个作用,你可以自行选择。

CRM管理又称客户关系管理,我们用对象思维解释一下:实体是公司或企业,对象是客户,手段是结果管理和过程管理,目的是转化,结合管理的定义整合成一句话就是对客户全生命周期管理抽象特点,以赋能管理手段扩大管理能力边界和提高管理效能。

而且由于后台产品多为内部使用,很难有竞品参考,更很少有像“用户体验”这样的概念,可以获得后台产品经理外的大众群体的广泛认知,实际上,后台产品入门要比普通产品更难。

图片 2

当前业内CRM分个方向:第一是O2O销售管理内,一般内部使用偏管理;第二是如电商后台客户资源管理类,会有客户管理,会员系统,自动化营销系统等,偏分析和运营类。

关于后台产品的用户体验,常见的的说法是“反正内部用,能用就行了”,所以很多人说后台产品不需要用户体验。然而,用户体验不只是前台让人赏心悦目的视觉设计与炫酷的动效,更在于用户在使用中感受到的流畅与便利。

文档变更记录

未来商业都是要围绕着人展开的,广义的讲所有业务的产品都可以纳入CRM,CRM将是各大平台或商家适应未来商业环境的基础标配。

所以,对于后台产品,最佳的用户体验就是效率。而效率,就来自于产品对于业务流程上的梳理,与系统的易用。所以一个好的后台可能没有良好的视觉体验,但不可能没有良好的用户体验。

如果当前版本有变更,最好单出一个文档需求变更说明(一个版本一个表格),一是自己检查开发是否按自己的需求设计;二是让开发很清楚当前版本需求变更情况,以免发生错误;三是反思变更频繁的原因。

虽然市场的消费水平不断提升,各种触达渠道数不胜数,但是没有对客户精细化的运营,只是不断的讲产品,服务推送给用户的转化是极其惨淡的。

关于后台产品的用户需求,不了解后台产品的人会说,做业务方告诉你们的功能不就可以了?这样的后台产品经理,只能沦为一个业务与技术之间的传话筒。

图片 3

对产品和用户的精耕细作尤为重要,单纯采用流量漏洞的流量思维在当下也显得有些不够用,需要更灵活的标签系统,会员系统,超级会员等不断完善用户画像,通过用户浏览行为数据,购买数据,收藏加车的行为进行汇总,沉淀数据池。

只有深入了解业务,与产品的使用人员去聊,在他们真实的使用环境下观察他们的使用情况,甚至和他们共同反复使用,才能体会到他们最真实的痛点,开发出真正符合用户需求,能够推动并引领业务更快速的发展的后台产品。

****二、产品工作流程**(对应这个查看后面每个阶段产出物)

不同纬度的数据汇集成数据集市,用地域值,时间值和模型值将数据池中的数据抽离出来赋能给应用进行高效的转化。


产品工作流程分为六个阶段,每个阶段的主要角色、重点任务、关键会议、关键产出物如下:

那么CRM的作用在哪?数据采集方式,数据格式化,对用户和产品服务分析后输出模型值赋能给各个应用,提升转化效率的作用。

那么,如何进行后台产品设计呢?我的总结是以下几步:

图片 4

CRM属于前台还是后台

一、业务梳理

通过与需求方交流,了解业务的基本逻辑后,首先要理清业务关系,由于业务关系可能较为复杂,推荐大家分步以流程图的方式进行梳理。

在这里以简单的发布文章并审核发表为例。

****三、原型图示说明**

首先CRM产品一定属于业务线产品,不能单纯的用前台,中台和后台的系统架构思路进行区隔,因为一个优秀的CRM产品都是业务型产品,通过业务架构思维指导产品设计,所以对产品的展示形态没有前台那么高的要求;(但还是要比后台要求高)

1.流程图

通过流程图,明确完整的业务流程,以动作来推动业务流前进。如图中的发布、审核、修改、审核、发表等所需的操作需要一一明确。

对原型的图注进行说明

CRM又不像CMS,ERP,MQ,AMS,FIS,甚至更底层的如订单履约系统等完全属于后台产品架构,不难区分的就是这类系统无论在哪结构都高度相似,会根据公司业务和策略调整但是底层模型不会有大的变化。

2.泳道图

通过泳道图,明确业务动作的责任人,通过设定角色实现权限控制。

如图中的发布、审核、修改等基本操作需要编辑完成,而审核发表的功能只有主编才有权限。

还要注意需要审核过的内容的修改权限,可以拒绝修改,可以限定只有具有审核权限的角色可以修改(主编修改),也可以统一修改后重新审核。

图片 5

所以明白了吗,CRM需要你懂一些前台设计和页面交互逻辑,懂后台架构和系统交互逻辑,一切为了满足业务需求,为什么?看后面实战激动了。

3.分模块泳道图

通过分模块泳道图,明确任务状态,任务的不同状态对应后台的页面也会有所不同,需要分别进行设计。

****四、角色说明**

不啰嗦了,进入实战

二、架构设计

后台产品的架构,主要分为三块:

对参与系统的各个角色进行说明

项目目标

1.总览

后台涉及大量项目数据,总览的页面一般采用表结构,简单清晰。需要展示项目关键字段,并提供排序、筛选、搜索与对应流程的功能入口。

图片 6

项目目标从0-1搭建带有社群管理的CRM系统。

2.项目流程与功能

根据分模块泳道图的任务状态,对于任务的不同状态,设计对应的模块页面,依据流程图的任务流程,确定此时每个角色的功能与对应信息展示。

****五、名词说明**

项目重点没有对产品全貌想清楚,不要动手开始画原型,因为CRM重点在管理,所以各个系统模块之间的交互会比普通产品复杂的多,先想清楚你要管理什么?想清楚你要管理什么;第二步就是你的管理手段和抓手在哪里(是系统自动化判断还是运营支撑);你最后要达到什么效果,也就是目的是什么(重点关注数据层能否满足);管理方案。

3.数据与管理

后台除了要满足对于前台项目管理的需求,还要提供项目总体情况的汇总情况展示,一般以仪表板配合关键数据及数据趋势的方式呈现。

业务相关词汇解释

总结:一切围绕着业务管理,针对你的目标想管理手段,最后想清楚产品方案,看到没有,这时候都没有去想原型有什么,因为还不到时候,此时你最重要的是想清楚产品结构和数据层的设计。

三、原型制作

作为产品,原型制作是基本功,就不详细说明了,在这里只说一下与前台产品的几点重要差异:

图片 7

本次项目系统模块:消息中心,社群管理,客户管理,海域管理,客户跟进。(下一篇会讲管理思路和实战设计内容)

1.表单

后台产品相比前台,数据多,信息量大,普遍采用表单结构,要注意数据的来源,字段,排序,大量数据是否需要筛选与搜索,考虑到系统响应时间是否分页等等。

****六、产品风险**

产品结构之概念模型

2.数据检验

后台经常完成数据录入,一旦格式错误可能会对产生严重后果,所以数据录入时要考虑信息输入的限制与完整性校验。如数字的小数位数、字符串的长度限制、数据的完整填写等等。

记录产品风险的好处是告诉别人这个锅我不背!我不背!!我不背!!!

使用工具:UML。

3.操作与反馈

后台涉及大量操作,考虑操作的权限,针对不同角色呈现不同内容,高危操作时的提醒与二次确认,操作后的成功提示与失败提醒。对于无网络、无内容、无权限情况 的异常处理,清晰提示

描述产品可能存在的风险,比如商务谈判的风险,外部合作的风险(对接的接口有坑?对接方时间不可控);人力风险,一个人多个项目;风险级别为高中低。需要非技术团队的支持。

(内容进行小部分脱敏)

4.通用模块

后台设计的模块通用性较强,为避免避免重复设计,可以采用蚂蚁金服的Ant Design的Axure 部件库,对于页头、页尾、导航等通用模块均有包含,表单、分页器、提醒等基础控件也简单易修改,还有完整页面模板,对于通用页面可以方便的套用。

下载地址:https://ant.design/docs/resource/download-cn


那么,后台产品的设计暂时就到这里了,但是产品的开发才刚刚开始,在与开发沟通中还可能涉及安全性要求、性能要求等一些技术问题,比如并发数、实时性、容灾性等等技术指标,还需要根据产品的数据需求进行评估,反复沟通,共同探索,共同打磨出优秀的后台产品。

图片 8

图片 9

****七、产品总业务流程图**(给RD)

概念模型的核心思路是在确认产品架构后,梳理各模块之间的关联关系,系统交互方式和数据结构层的作用。

业务流程定义

梳理概念模型的时,首先确认我们有哪个系统模块,确认每个模块的拆分合并的意义,每个模块内的数据字段的含义是什么?为什么要有这个字段用来干什么?然后看整个流程是否已经可以跑通,不存在数据断层和数据冗余的问题即可。

百度百科定义:业务流程是为达到特定的价值目标而由不同的人分别共同完成的一系列活动。活动之间不仅有严格的先后顺序限定,而且活动的内容、方式、责任等也都必须有明确的安排和界定,以使不同活动在不同岗位角色之间进行转手交接成为可能。活动与活动之间在时间和空间上的转移可以有较大的跨度。而狭义的业务流程,则认为它仅仅是与客户价值的满足相联系的一系列活动。

最后就是开始删改,为什么?

简单来说,通常会由几个「角色」来组成一条流水线般的工作线。

因为概念模型会让你想的大而全,是否有没必要的模块和流程的其中,流程能否进行优化,简化流程。

表现形式

发现没有?没出原型的时候你已经可以思考优化方案,流程优化的东西了,当你自己在这个阶段都优化完,思考全了,后续产出的东西你还怕被喷被返工吗? 不存在的。

常用泳道图,分为横向和纵向

概念模型梳理完成后开始进入USERCASE阶段。

画流程图前的准备-与业务方确认业务流程

产品数据权限之USERCASE

1.角色/关键角色(对流程中的角色有主要影响)

画USERCASE原因是CRM会为多种角色使用的场景(权限系统参考RBAC模型),所以各角色的数据权限需要思考到位,比如BD能看到什么能用什么功能,BDM/CM能看到什么能用什么功能,甚至财务人员,运营人员等等都需要提前考虑到位。

2.活动:做了什么事情

为了能清晰的表达这之间的管理使用USERCASE最为方便。

3.次序:做这些事情的次序如何,谁是谁的前置条件

图片 10

4.职责(规则):什么情况下做什么事情

USERCASE的核心作用帮你梳理业务边界,在这个阶段每个功能给谁用不给谁用,每个数据给谁展示,展示多少有控制,不给谁展示,为什么不展示等都要去思考到位,并且给自己一个说的过去的业务理由。

画流程图的要素

产品使用之业务流程图

两大维度:一般泳道图的横向为角色,而纵向则作为阶段,时间从上到下发展。如果复杂的泳道图,在任务分解上可以在阶段维度里做一些划分(也可以做横向泳道图)。活动就像一个游泳员一样,游到不同的泳道中去执行任务。

CRM这类产品一定要画业务流程图!!!功能流程图可以不画,画了也是放在详细介绍中。

举例如下:

编辑:互联网 本文来源:后台产品设计的那点事

关键词: www.3559.com