前台产品设计和后台产品设计各有什么特点?后台产品设计主要的设计方法是什么?有相关?

产品经理是不是前后台都需很清楚的了解

请先 登录 后评论

1 个回答

xxxxxa

做了几年后台,针对后台来说,我认为这四个能力比较重要:

逻辑思维能力

一种是系统内的逻辑。后端系统在页面设计方面要求不会非常高,只需要做到布局清楚,做好提示减少误操。如同做支付的人经常讲路由和成本,其他后端系统也有类似的考虑,就是信息的路由。

一条请求发过来,不管是要查询信息,还是要执行某个操作,都离不开系统内几个模块的信息流转和同步。这条请求包含哪些数据,对数据需要做哪些处理,处理是人工做还是系统做,如果是人工做,还需要有系统的校验和保存,处理后提供什么要的结果,结果如何展示,是否需要把结果通过接口或批量报表的形式提供给其他后台模块。往往在思考这些问题的时候,一张清晰的数据交互时序图,可以帮助你解决很多问题,也更容易把你的想法传达给开发同事。

另一种是写后台PRD时的逻辑。比如一个功能点,逻辑思维一般的人描述可能就是实现了xxx功能;而一个逻辑思维严谨的人,会清晰的描述出,前置条件,触发因素,产生结果,系统处理规则,默认是什么样,有数是什么样,数据多了是什么样,异常是什么样。总结一下,就是条例清楚的表达出需求的来龙去脉。

充分跟需求方沟通,然后思维导图罗列出功能架构,再基于这些,做逻辑图。思路一定要清晰,否则很难推进下去。一定要尽量想的全面,别到时候需求评审时候,这里有问题,哪里不全面,会被开发笑话的。自己不清楚的时候,别指望别人能清楚的理解你。

熟悉自己在做的业务

熟悉自己在做的业务,是需要对服务体系内的业务流程足够了解的,因为你设计的后台是要去帮助他们更好的处理业务,你对业务流程不够了解的话,设计出来的产品就会不贴合实际的使用场景。

对于业务的理解,可以概括为三点:

  1. 前台有什么,后台管什么,比如最基础的用户管理、商品管理、订单管理、内容管理等等
  2. 对后台系统的管理,比如个人信息管理、权限管理;
  3. 数据管理,一款好的产品一定是用户利益和产品利益的结合体,而最能客观反映产品利益的就是数据,所以平台数据化;其次是逻辑思维,基本业务流程化、特殊场景特殊处理,与前台互动的触发机制等等

以自己在做的代购工具项目,我需要去了解整个代购的接单流程,为此我加了十几个高质量代购群,并且自己把积累的这些认识的核心代购拉了个种子用户群,每日坚持在群里发红包向他们了解最真实的需求。为此我设计的后台中,除了常见的商品管理模块、订单管理模块,在此基础上我加了自建商品库(为了满足代购创建一些销量好,但免税店没有的商品,比如某几类杂志)、委托单管理模块和采购清单管理模块,委托单和采购清单的实际应用场景请自行思考,就当是课后作业。

项目需求管理能力

项目需求管理能力,我认为可以分为两块,需求池管理和明辨真伪需求。

一个比较大的后台项目,可能涉及到多个前端产品的需求,好多功能,比较分散,并且多线并行。这时候需要一个需求池来管理需求,我一般采用excel把负责的需求汇集成一个需求池,并上传公司内网,支持团队内小伙伴的多人在线编辑,随时更新各自跟进的需求的进度。需求池一般需要优先级、提出人、需求进度、预计上线日期等关键字段。

明辨真伪需求的前提,是懂业务!懂业务!懂业务!重要的事情说三遍。业务方的提的要求是一匹可以跑得更快的马,但是实际你要给他的是一辆车。在跟业务方聊天的时候,不一定要记住他要求你做什么,但是你一定要记住他提出来种种的原因和期望实现的目的。

再就是后台除非大版本大改动,否则基本上不会走版本,许多小改动当日改当日上,而且一般后台产品会对接多个业务方,需求排期整理也是个技术活……

另外,有些常见改动模块或者重复类功能,一定要做成灵活可配置,能帮你怼回去N多“白痴”需求。

对后续业务需求和功能的可扩展性

考虑后续业务的扩展,一个后台管理系统,是为了满足老板、运营等角色的管理需求。现在阶段的管理是为了满足现有阶段业务的需要,后续业务量上来了,一定要考虑扩展性。

举一例,运营人员后台上传照片时,如果你简单的想到一个button单张上传,可以满足现有业务的需求。但一旦量大了呢?上千上万张图片,一个一个button的去点么?

请先 登录 后评论