文章从整体上对后台系统的特点和设计标准展开剖析,希望对你成长为一名优秀的产品产品经理有所帮助。
在互联网行业,产品经理的类型划分有很多种维度,若按照系统从前到后全链路的运作流程来看,可以笼统的分为前台产品和后台产品。
前台则是用户与之进行交互的平台,比如我们用来购物的淘宝APP,或者浏览资讯的36氪网站;后台则是满足前台功能实现并进行逻辑控制的管理平台,一般是面对服务提供者使用,比如淘宝商家管理后台,或者36氪资讯管理后台。
作为互联网的普通用户,接触最多的就是前台产品,并且在使用上也总是能有一些见解,因而很多校招生或者是互联网新人,总是想着也做一名前台产品经理。
其实后台产品往往有着更多的发展方向和空间,也能再细分为很多类型,本文并不展开细讲,而是从整体上剖析一下后台系统的特点和设计标准,希望对你成长为一名优秀的产品产品经理有所帮助。
前台产品注重用户体验,产品经理要和UED团队一起,打磨产品的每个细节,从而让用户用起来更“爽”,而后台产品因为所面对的用户群体以及定位不同,有着不一样的特点。
前台功能的实现依赖于后台系统的支撑,换个说法理解,当用户在前台触发某个操作时,总是期望能够达到某个想要的结果。而在“触发操作”到“期望结果”之间往往会有很多实施步骤需要处理,这些则是借助后台系统来完成的,所以梳理清晰业务流程对设计后台系统非常重要。
并且不同行业有着不同的业务流程,这也就有了产品经理的另一种维度的类型划分,比如社交产品、电商产品、金融产品等等。对于这些纵深行业来说,业务流程也往往具备非常强的专业性,需要靠项目和时间来积攒经验。另外,同一行业不同公司之间的业务流程也会存在许多差异,这是由公司的发展策略等因素来决定的,比如天猫和京东的订单处理流程。
做好后台产品的一个重要前提,就是要把业务流程梳理透彻,如此才能设计出符合实际需求的系统。
前台产品是对外给用户使用的,只有用起来舒畅,用户才更愿意用,尤其存在竞争对手时,用户往往都会流向体验更好的产品。
后台系统的使用者往往是内部业务人员,更注重的是功能实现,只有满足业务部门的功能,才能开展相应的业务或提供新的服务,而在使用这些功能时,对使用体验的容忍程度则比外部用户要高很多。
当然并不是说完全不注重用户体验,而是重要程度没有这么高,在排期规划或研发成本等综合因素的考虑下,可以舍弃一定的用户体验。
尤其是在快速迭代的项目早期阶段,要优先保障前台核心功能的良好用户体验,而对于后台系统来说,很多功能模块都可以采用开发成本更低的临时方案,哪怕操作效率比较低,体验也不够好,但只要保障功能可以实现,业务可以正常运转即可,这也正是MVP设计理念的体现。
前面提到后台系统也具体分为很多种,那有没有一个比较统一的设计指标能够应用到所有后台系统中?或者说后台系统满足什么样的条件时,才可以称得上好用呢?
用户在使用前台产品时,一般是属于日常生活消遣,所以要讲究好用易用,而内部业务人员在使用后台系统时,一般都属于工作范畴,所以要讲究高效率,如此才能快速高效的完成相应任务,说的更宏观一些,提高效率是减少人工操作成本的一个非常重要的途径和方式。
怎么样才能提高效率呢?一定要深入到各种使用场景中,快速满足使用者的诉求。比如,在需要维护大量数据的情况下,要尽量提供批量的操作方式;在信息和资料经常重复利用时,要尽量提供复制或模板等功能;在某些固定逻辑需要不间断操作时,可以考虑提供系统自动处理选项。
业务部门常常只是局限在当前的场景下提出系统要求,或者是因为策略调整不断更改要求,这也就经常导致需求变更的情况发生。
所以对后台系统来说,在可接受的开发成本下尽量提高系统的灵活性,不仅能满足业务人员更多的使用场景,同时也能在一定程度上提高系统开发的综合效率。
比如,运营同学提出要求,希望系统能够支持某个促销活动固定每周五生效。最直接的解决方案就是提供每周五生效的选项,稍微灵活一点就是可以支持选择固定每周N生效,再灵活一点还可以支持到每月N号生效,更灵活一点的话那就是可以支持自定义多个不连续的时间点或时间段生效。
当然,系统并不是要无限制的提高灵活性,一定是结合系统开发成本以及对日后可预期的使用情况来综合考虑。
上一点提到提高系统的灵活性能够在一定程度上满足更多的使用场景,但是随着业务发展,系统总是在不断迭代中,而且很多功能都是在原有基础上进行更进一步的演变,所以可拓展性也是衡量系统优劣的一个非常重要的指标。
实现可拓展性的基本策略就是要找到设计方案中的基本组成单元或者叫最小设计因子,尽量使其各自独立,如此在后续增加其它设计因子的时候才会更加简便。
比如,运营希望能够对无可用券且未下过单的僵尸用户进行唤醒活动,从此活动角度看,“无券且未下单”是用户群体单元,但是从设计角度来看,“是否有券”和“是否下过单”才是其中两个最小的设计因子,只有在设计方案中将这两个条件独立起来,才能更好的拓展“无券且下过单”等其它用户群体,同时后续再叠加“会员等级”等其它因素时也会更加方便。
再比如,一个营销活动页面内可能包含抽奖、领券、商品等多种元素,如果将其中的每个元素都理解为一个独立的控件,那么就可以通过这些控件不同的排列组合,创造出更多样的页面,同时后续增加其它控件也会更加自然。
前后台产品有着不同的侧重点,系统设计优秀与否也有着不同的衡量标准,那么对于产品经理自身而言,需要有哪些特质才能在后台系统设计更加游刃有余?或者说我们要培养自己哪方面的能力才能做好一名优秀的后台产品经理?
后台系统往往会涉及复杂的业务流程,除了包含正向流程,还会有很多衍生的异常分支流程,这就必然要求产品经理有着比较强的逻辑推理能力,才能够将业务梳理的足够清晰,而将业务流程梳理清晰是设计一个好的后台系统必不可少的基本环节。
设计后台系统时,经常需要将存在于不同实体之间的虚拟流程具象的体现在系统中,或者需要构建一个新的概念和实体来承载相应的功能。而这都要求产品经理有抽象思考能力,才能更顺利的完成对应需求分析。
不同业务之间的实体和概念或许不同,但是很多流程和逻辑都有相通的地方,当对某一个场景有了具体可行的设计思路后,当再遇到类似的问题时,都可以尝试归入到同一套解决方案中。这就像解答同一类型的数学题,万变不离其宗。
最后,说两个比较浅显通俗的学习策略,其不仅仅适用于后台产品经理的学习,也能应用到很多方面。道理虽然浅显易懂,但如果能真正运用起来,起到的效果也是非常显著的。
我们所遇到的大部分问题,早已经有人遇到过并且已经有成熟的解决方案了。在产品设计也是如此,所以无论前后台系统,我们都可以从其它产品中进行借鉴学习。当我们见识到足够多产品之后,遇到某些问题时解决方案很自然就会呼之而出;同时我们也可以带着特定的问题去调研,从而更有针对性的获取灵感。
学会自我总结也是不断成长的一个重要途径,无论是失败的设计方案,还是深受好评的产品功能,都有值得沉淀和积累的知识,而且通过项目实战而学习到的技能会更加深刻。随着工作年限的增加是否能转化成相应有价值的经验,非常重要的一点就是要学会自我总结,如果做不到或做不好的话,增加的可能仅仅是经历而已。
以上,本文是自己关于后台产品经理的一些思考,欢迎交流和指正。
本文由 @刘鹏 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自unsplash,基于CC0协议