产品设计：离用户那么近，业务系统该如何设计？

　　相比C端产品，B端的业务系统对很多人来说都很陌生。在爬过无数的坡、踩过无数的坑过后，以在线教育业务系统为例，系统分析整理了业务系统产品的相关内容，分享给感兴趣的你，希望你可以少走一些弯路、绕开一些坑。
　　业务系统，通常为：内部产品，与c端产品供广大普通用户使用不同，业务系统的使用者通常是公司内部的销售、客服、技术支持人员或者是一些合作伙伴或商业客户。
　　业务系统的一大特点，就是：距离使用用户足够“近”。你可能在茶水间或者去洗手间的路上碰到你的用户，可以随时展开需求调研与问题反馈（接受吐槽），获得系统优化的一些点或是一些“灵感”。
　　“埋雷”与“排雷”
　　埋雷
　　做用户调研，千万别忘了用户是会“撒谎”的。如果完全按照用户反馈的内容进行开发，一颗巨大的雷就悄悄的埋下了。
　　为什么这么说呢？下面让我们来逐层分析，逐步排雷。
　　排雷
　　1）确定影响范围
　　一套完整的业务流程需要不同部门、不同职能属性的用户（角色）一起来完成。如果完全采纳一方的建议，站在当前用户的角色角度是可行的，但对于其他用户角色来说可能是一种负担，对总体流程来说可能也没有很大的优化或提升。
　　2）确定具体问题
　　其次，业务部门有需求或反馈，说明他们在实际工作中遇到了一些问题或者使用不便捷的地方。
　　但我们不能把他们反馈的“功能”或提升的建议作为产品方案，反而需要深度调研业务使用过程中遇到了哪些问题，想要达到什么样的效果，收益是什么，如何衡量相关数据指标。而不是把业务的产品“建议”当做我们的产品“方案”，把我们自己变成了业务部门的“传话筒”。
　　3）确定产品方案
　　最后，需要思考当前功能在现有产品功能架构中的定位。从做功能后做模块到做系统，最终主动思考、建立产品架构思维，是一个逐渐成长与沉淀的过程。
　　将整个业务相关的流程、功能、模块、系统视为一个整体，并以“上帝视角”对它进行剖析、完善，优化总体业务流程，提升办公效率，提高用户体验。
　　所以，业务产品经理需要倾听用户而不尽信用户，以公司整体业务为目标，培养产品架构思维，深挖用户的每一个诉求，并最终完成较为合格的产品方案。
　　用户
　　大家都知道，从一个idea到最终产品落地实现的过程中，做用户调研、用户画像来明确我们的用户目标群体是必不可少的，我们需要了解用户目标群体的年龄、性别、教育程度、地区、职业、等等信息。
　　但是，业务系统的用户调研与用户确认相比toC类产品更加具象。因为使用的用户可能就是你单位的同事或合作伙伴，你可以随时找他们沟通发起用户调研并收集反馈，就不用费力思考“我的用户在哪里？”这样令人头疼的问题啦。
　　那么，具体对于业务系统的目标用户该如何确认呢？
　　1。深入了解总体的业务流程
　　也许有的小伙伴会好奇，不是确认目标用户么，怎么扯到业务流程去了？
　　深入了解业务流程的过程中（业务流程抽象后面文章会讲到），会对业务整体流程有个总体的了解清楚都有哪些部门哪些人（角色）在哪些节点做哪些事？彼此的互动及反馈是怎样的？这些内容对于后续业务系统的规划与设计尤其重要。
　　还记得我最初做在线教育业务系统产品经理的时候，前半个月基本都是泡在业务部门，领导还以为我出去浪了（给你个眼神自己体会）。
　　2。了解公司的组织机构及各部门职能
　　了解公司的组织机构及部门职能有助于将视角开阔的足够广，广到可以去清晰的定位边界。
　　业务的职能边界，往往是业务流程挖坑最多的地方，也是业务本身纠缠不清的地方。打个比方：A部门负责卖蔬菜，B部门负责卖水果，但是西红柿这个产品A、B部门都有售卖。
　　那么，具体的销量及推广流量的转化率该怎么计算呢？
　　此外，每个公司的组织机构及部门职能可能会有一些差别，例如：客服，有的公司客服只管投诉建议与反馈，而有的公司客服可能还负责售卖产品。
　　3。了解业务系统主要角色的工作内容
　　说了这么多，终于将话题扯回业务系统。
　　了解及确认：业务系统都有哪些部门使用？主要需要什么样的功能？部门内部有哪些角色？需要什么样的权限？搞清楚用户对于后续开展业务系统的功能模块设计具有重要的意义。
　　感兴趣的小伙伴可以去看一下RBAC（RoleBasedAccessControl基于角色的访问控制）的相关内容，或许你对于用户角色及系统权限会有不一样的理解。