域名频道资讯站
我们一直在努力制造惊吓

产品设计:离用户那么近,业务系统该如何设计?


相比C端产品,B端的业务系统对很多人来说都很陌生。在爬过无数的坡、踩过无数的坑过后,以在线教育业务系统为例,系统分析整理了业务系统产品的相关内容,分享给感兴趣的你,希望你可以少走一些弯路、绕开一些坑。

产品设计:离用户那么近,业务系统该如何设计?

概述

业务系统,通常为:内部产品,与c端产品供广大普通用户使用不同,业务系统的使用者通常是公司内部的销售、客服、技术支持人员或者是一些合作伙伴或商业客户。

业务系统的一大特点,就是:距离使用用户足够“近”。你可能在茶水间或者去洗手间的路上碰到你的用户,可以随时展开需求调研与问题反馈(接受吐槽),获得系统优化的一些点或是一些“灵感”。

“埋雷”与“排雷”

埋雷

做用户调研,千万别忘了用户是会“撒谎”的。如果完全按照用户反馈的内容进行开发,一颗巨大的雷就悄悄的埋下了。

为什么这么说呢?下面让我们来逐层分析,逐步排雷。

排雷

1)确定影响范围

一套完整的业务流程需要不同部门、不同职能属性的用户(角色)一起来完成。如果完全采纳一方的建议,站在当前用户的角色角度是可行的,但对于其他用户角色来说可能是一种负担,对总体流程来说可能也没有很大的优化或提升。

2)确定具体问题

其次,业务部门有需求或反馈,说明他们在实际工作中遇到了一些问题或者使用不便捷的地方。

但我们不能把他们反馈的“功能”或提升的建议作为产品方案,反而需要深度调研业务使用过程中遇到了哪些问题,想要达到什么样的效果,收益是什么,如何衡量相关数据指标。而不是把业务的产品“建议”当做我们的产品“方案”,把我们自己变成了业务部门的“传话筒”。

3)确定产品方案

最后,需要思考当前功能在现有产品功能架构中的定位。从做功能后做模块到做系统,最终主动思考、建立产品架构思维,是一个逐渐成长与沉淀的过程。

将整个业务相关的流程、功能、模块、系统视为一个整体,并以“上帝视角”对它进行剖析、完善,优化总体业务流程,提升办公效率,提高用户体验。

所以,业务产品经理需要倾听用户而不尽信用户,以公司整体业务为目标,培养产品架构思维,深挖用户的每一个诉求,并最终完成较为合格的产品方案。

用户

大家都知道,从一个idea到最终产品落地实现的过程中,做用户调研、用户画像来明确我们的用户目标群体是必不可少的,我们需要了解用户目标群体的年龄、性别、教育程度、地区、职业、等等信息。

但是,业务系统的用户调研与用户确认相比to C类产品更加具象。因为使用的用户可能就是你单位的同事或合作伙伴,你可以随时找他们沟通发起用户调研并收集反馈,就不用费力思考“我的用户在哪里?”这样令人头疼的问题啦。

那么,具体对于业务系统的目标用户该如何确认呢?

1. 深入了解总体的业务流程

也许有的小伙伴会好奇,不是确认目标用户么,怎么扯到业务流程去了?

深入了解业务流程的过程中(业务流程抽象后面文章会讲到),会对业务整体流程有个总体的了解——清楚都有哪些部门哪些人(角色)在哪些节点做哪些事?彼此的互动及反馈是怎样的?这些内容对于后续业务系统的规划与设计尤其重要。

还记得我最初做在线教育业务系统产品经理的时候,前半个月基本都是泡在业务部门,领导还以为我出去浪了(给你个眼神自己体会)。

2. 了解公司的组织机构及各部门职能

了解公司的组织机构及部门职能有助于将视角开阔的足够广,广到可以去清晰的定位边界。

业务的职能边界,往往是业务流程挖坑最多的地方,也是业务本身纠缠不清的地方。打个比方:A部门负责卖蔬菜,B部门负责卖水果,但是西红柿这个产品A、B部门都有售卖。

那么,具体的销量及推广流量的转化率该怎么计算呢?

此外,每个公司的组织机构及部门职能可能会有一些差别,例如:客服,有的公司客服只管投诉建议与反馈,而有的公司客服可能还负责售卖产品。

2. 了解业务系统主要角色的工作内容

说了这么多,终于将话题扯回业务系统。

了解及确认:业务系统都有哪些部门使用?主要需要什么样的功能?部门内部有哪些角色?需要什么样的权限?搞清楚用户对于后续开展业务系统的功能模块设计具有重要的意义。

感兴趣的小伙伴可以去看一下RBAC(Role-Based Access Control——基于角色的访问控制)的相关内容,或许你对于用户角色及系统权限会有不一样的理解。

 

本文素材来自互联网

赞(0)
分享到: 更多 (0)

中国专业的网站域名及网站空间提供商

买域名买空间