B端产品设计中用户体验可能不是重点

时 间:2020-07-03 09:46    

    

  本文作者依据工作中项目实践的所思所想,结合案例等分享了B端产品设计的相关流程以及过程中需要注意的关键问题,供大家一同参考和学习。

  为什么写这篇文章,是因为由我参与的一个系统正式投入市场后,经过几次的迭代,亲自接触了客户,获得了认可,有些真实的感受想和大家分享。

  大部分产品经理的职业成功之是成为某个领域的产品专家,而做B端产品经理是一条成功率极高的,这就是我选择B端的原因。

  现在是负责设计一款SaaS型培训系统,你要问我对这个行业了解多深,完全是从一个小白开始的,经过一年多的深度实践,现在可以用我设计的系统帮助客户做信息化,帮助客户实现线上线下混合式培训。

  这就是B端产品,Business,即商业,帮助客户实现战略需求,从线下已有的运行业务进行信息化、系统化、高效的处理。

  B端产品基本模块由用户管理、权限管理、OA管理、CRM管理、营销管理、订单管理面、报表统计等组成,几乎覆盖B端客户能应用的管理场景和运营场景。

  一个行业经过几十年的发展,才形成行业标准,一款成熟的系统本几乎覆盖提到的产品模块,面对这样一个错综复杂的场景,产品经理最好的做法是循序渐进,从最粗略的业务目标开始,然后分析业务流程,到各职位的工作内容,最后才是数据、报表的细节。

  从理论知识,到具体的设计,到部署上线,再到客户使用,这整个过程中我将踩过的雷在这里跟大家说说。

  先说一说,我接手这款产品的背景,据说已经做了6年了,是从一个纯线上学习平台过来的,底层结构固化,客户使用者个位数。

  随着教育信息化的普及,互联网的高效、便捷的特点,让市场需求越来越大,客户付费的意识越来越强烈。

  面对日益丢失的市场,可想而知,公司面临着很大的压力,我们这些干活的自然而然有了压力,从市场业务人员,运维人员,产品团队,技术团队对客户的需求有了清晰的认识,这款产品到了不得不改的地步了。

  我们这款产品已经有用户在使用了,为了满足这些客户未来发展的需要,降低运维成本,一款SaaS型产品最大的好处就是可复制,一星期就能就能完成新租户系统部署上线。

  在开始做产品规划之前,首先要对产品进行定位, 这就要求多问自己几个问题,这都是吃过亏总结下的:

  这些问题能帮助我们搞清楚产品的目标与价值,找出系统的关键受众,列出他们要解决的问题,分析业务,寻找产品范围,最终针对特性,提出系统用例细化功能需求和非功能需求

  第一阶段的任务是对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标与、组织架构、岗位划分等方面开展研究,这就是产品背景分析。

  做背景分析的目的:要对我们的产品要重新定位,从原本模糊的客户变成针对某一个行业,某一类的客户,这样能帮助我们明确目标,缩小业务范围,这样我们更好的深入了解业务,更好匹配客户需求。

  虽然第一层次并不足以让我们了解业务具体运转的逻辑,但是通过业务架构描绘出的一幅业务全景,对于进一步了解需求帮助巨大,这样就不会迷失在茂密的需求森林中。

  每个产品都有特定的用户群体,B端产品也不例外。背景分析的第一步,首先我们要搞清楚,产品到底是卖给谁?

  做C端产品时,我们习“用户故事”帮助我们定义用户类型;做B端产品,同样我们可以用一个“企业故事”帮助我们理清目标群体的需要。

  目标客户是一家___客户,没有用我们产品之前,他们是这样工作的:_____当前客户在工作方式上出现了____问题,因此需要借助我们产品解决____需要,期望达到___的需要。通过这个企业故事,我们可以定位到产品针对什么行业、什么规模的企业,然后明确了这类公司的核心,将来在能与设计的时候可以围绕着这个核心展开,也是产品不断更新迭代的方向。

  被动获取资料的行业,一般市场上已经有这样的产品,客户有了明确的要求,产品经理只要根据这些描述,基本上能还原业务场景,然后做需求分析。

  但这样的需求分析是有缺陷的,因为这里面一些需求是客户定制化的,不能代表同行业其他客户的需求,这就需要产品经理收集更多的资料,从中抽离出共性。

  你要寻找这个行业规模做的比较大,组织机构健全的客户,因为大家都会相互学习,相互模仿,谁做的好,他的管理方法逐渐被其他客户了解,并效仿,你做的产品才能迎合这些潜在客户的需求,才能获得更好的口碑。

  在这个寻找标杆客户的策略上,我们就走了弯,选择了一个规模不大的客户,重管理不重运营,导致产品目标跑偏了,系统耦合严重,操作繁琐,不仅没有获得市场认可,反而还让竞争对手反超了,就因为标杆客户选择的比我们的更精准。我们花了一年的时间进行修正,终于回到正轨上,很多研发资源都投入到这个系统上,这个代价是很大的。

  在做C端产品时,最重要的步骤是需求梳理,也就是思考什么类型的用户在什么场景下遇到了什么问题。

  这个看似简单的问题并不那么好回答,很多人认为的B端需求就是帮助用户完成业务流程所需要做的事情。但这样的理解并不完整,

  需求分析并不是在分析系统如何实现用户的需求,而是选择一种业务导向的将零散的需求起来,形成一个体系完整、内容清晰的框架,为下一阶段的产品设计工作做准备

  用户经常从自身角度出发得出问题的解决方案。因为对产品定位、设计的依据等情况不了解,他们的很多时候并不是该功能的最好实现方式,也就不足以直接作为产品规划的直接依据。如果根据表面需求来设计产品的话,很可能会出现“头痛医头,脚痛医脚”的情况。

  依据用户想解决的根本问题,得出的更好的问题解决方案。解决方案可以理解为一个产品,一个功能或服务,一个活动。

  这里重点分析一下需求的过程,叫需求透视,即透过现象看本质,我相信这是每个产品经理必须具有的产品能力。

  主要任务是梳理清楚目标客户所有的业务类型。为不同的业务类型划分界限。并梳理出每个业务类型中所有的需求,也就是需求透视的过程。

  做好需求透视第一步就是要做业务流程分析,就是针对每一项业务事件,分析业务活动的特点,并确定业务活动之间的关系。具体要做的事情是:

  B端客户的核心价值就是对外部用户的进行处理,在为用户创造价值的同时,为B端客户创造价值。

  为了方便大家理解,这里我以亲身实践的一个客户培训来举例:某省农业农村局委托某高校承办全省乡村第一参加某线上直播培训。

  第一种方案:市场部告知项目管理部有某个培训要组织,项目管理部在平台创建培训班,有组织方分享给受训方自己线名,班主任直接看后台数据就可以了。

  第二种方案:有组织方报名名单给项目管理部,项目管理部在平台创建培训班,导入用户名单,生产用户账号,发送报名成功的信息给用户就可以了。

  在B端客户实际业务中,根据业务流程的目标可以将其分成不同的类型,一般我们可以分为生产流程、管理流程以及支撑流程三类。

  在本次培训过程中,高校培训部作为承办方,在进行项目申报、培训方案制定、培训班创建等这类环节都属于生产流程。

  在这个主流程以外,每一个环节都有相应的审核操作,以及培训过程中进行签到、考核等这种流程属于管理流程。

  在培训过程中,需要合同审批,项目备案、后勤管理等这些流程属于支持流程,有这些功能更好,没有功能能实现,客户自己线下也能实现。

  做好需求透视第二步就是要做角色与使用场景分析,这个是很重要的分析过程,一个功能脱离了用户使用场景,用户就会感到很不爽,甚至直接放弃使用。

  用户故事是指某种类型的用户为了完成某特定目标所执行的一系列操作。在描述层面我们可以暂时忽略业务目标,因此一条用户故事包含两个元素:参与者、做什么事。

  例如,班主任要求学生完成签到,就会遇到很多应用场景:有在现场报名时签到,有每次线下上课前进行签到,有每次线上上课前进行签到等等。

  可有了这些签到方式,常常还是有客户抱怨太难用,很难理解系统的意思,也不知道从哪里去找需要的功能。

  因为在传统的结构化分析与设计方法中,对事物的分析视角都是站在解决方案层面思考的,即这个系统需要有什么,从系统的角度出发能规划。

  而以“用户故事”驱动的需求分析方法,是一种更侧重于“从用户的角度出发,将系统当做一个黑盒子”的视角,这种方法能够有效解决上述问题。

  以线上学习每次班主任发起数字签到为例,因为每次培训正式开始前,班主任都会创建微信群,方便总要信息及时通知。这个场景下班主任和特别依赖微信群。如果班主任发起签到能直接分享签到链接到微信群,在微信群里直接打开完成签到操作。不用在平台之间直接跳来跳去,切换操作。

  这样一个分享的操作,即减轻了班主任给反复解释操作流程的工作量,也简化了的操作流程。这样用户就会感觉很爽,班主任也没有负担。

  从另外一个角度来说,用户故事的关键点在于发现使用系统的用户,了解并梳理这些用户如何使用系统,从而达到“以人为本”的需求分析。

  面对一个陌生的领域,一个经历了多年发展变化的业务流程,要在短时间内弄清楚的确是一个不小的挑战。用户场景分析的意义在于帮助产品经理在短时间内从结构、整体上了解业务构成。产品不断迭代的前提就是建立在用户场景不断优化、不断调整的过程中。

  但不管用户怎么回答,似乎都很难让我们满意。客户提不出需求,你会觉得我们的客户对这事好像也没那么上心;更多的时候是客户提的需求都是不痛不痒,或者你感觉极具个性化,让你感觉做也不也是不做也不是;

  和C端场景一样,B端场景中的用户需求也像是一个冰山,有很大一部分信息是埋藏在海平面之下,这就对需求调研工作带来很大的困扰。

  调研的客户毕竟不是技术专家,只是普通的业务人员,因此他们没有办法对其工作提出产生变革的解决方案。因此需要产品经理对问题充分理解的前提下,选择合适的实现方式以创造出用户未想到的功能;

  我在本次产品过程这些场景,也经常遇到,其中一个经费审批表导出就改了无数回,最终还是不满意。

  我们照客户的要求实现,我们满心欢喜地给到客户时,客户说这功能还是不实用,发现在实际工作中,有的文字内容过多,表格显示不全,导致分页显示,客户表示不满意,我们后来改回了word格式。

  客户反馈他们需要导出每个审批步骤和审批结果,我们照客户的要求实现,发现在实际工作中,他们增加了审批步骤,还是导致分页显示。我们后来我们改成了审批流程自定义导出。

  这样一个很小的功能,导致我们投入很多的开发资源,深挖客户需求原来是:客户从线下审批到线上审批需要过渡,需要平台 数据导出数据以备年度领导审查,备案需要。

  实际上B端产品的需求获取并不难,难的是与用户交流沟通的过程。因为我们的用户仅仅作为一个使用者,他只是站在自身使用的视角,想让自己的工作方便一些或是在利益分配上对自己更有利,很难站在系统规划的角度考虑全面整体的东西。

  遇到这种情况,最有效的应对策略是需求分析从流程入手,搞清楚业务活动在平时是如何开展的,再逐步过渡到存在什么样的障碍,有什么困难等等。在这个过程中,多问几个为什么,多思考客户背后代表的心里状态与利益冲突。

  所以这一阶段,我们主要做的工作是收集针对业务活动的问题点、需求点。这时候我们获取到的是原始的用户需求。

  实际上,在整个业务分类、需求梳理的大环节中,业务流程分析、角色与使用场景分析、以及获取用户需求都是伴随着用户调研进行的。

  用户调研是一个有计划、循序渐进的过程。具体来说,在针对不用的对象时,的要点也不尽相同,具体的要点参考以下表格:

  除了用户和问卷调查以外,有机会到业务工作中实际现场观摩也是一种很好的需求获取手段,有助于产品经理对业务场景建立更加感性的认识。在对关键任务理解不清晰、很多东西用文字没办法表述时,现场观摩都是一种很好的方式。

  首先,我们按照需求列表按照职责、部门、岗位整理归纳,这样我们能把产品划分成不同的业务板块,在这个层面看哪些系统需求是针对业务事件,确保业务流程正常进行的;哪些系统需求是针对报表的要求,确保流转过程中的数据传递;

  接下来再往更细颗粒的维度整理,梳理哪些系统需求是支持业务步骤的,基于这些业务步骤需要设计什么样的功能点。这样一来所有的系统需求都按照清晰的脉络,层层递进展现在我们面前。

  所谓前置条件是指在用户操作某个功能的时候,用户与系统应处于什么状态。这个状态是系统能够检测并且是有意义的。而后置条件是指在操作结束时,系统应处于什么状态。同样这个状态也是系统能检测到并且有意义的。

  当市场部和组织方达成合作意向,甚至签订协议或合同:这也不是一个好的前置条件,虽然系统可以检测,但是只是一个支持流程,不是主要流程,客户可以选择不用,这个事情所表现出来的意义不大,对我们来说没有帮助;

  在项目申报审核通过:这是一个好的后置条件,当然也要根据客户实际使用情况,但是系统可以检测并且事件对流程有影响;

  项目申报通过后,项目管理部或市场部进行培训班的创建,复用项目申报的一些基础数据,添加培训简介之后对外发布展示。

  一般来说,前置条件通常是一种状态,后置条件可能是一种状态,也可能是一种后续行为。并非所有的业务流程都必须在平台上存在前置条件与后置条件。

  这种结构是以业务流程为整理的主线索,也就是按“事”的角度进行分解。这种方法对于工作流系统以及信息管理系统来说都常适用的方法。

  以上整理需求的方式,是按照业务流程进行整理的。在这个分析过程中,因为我们的需求来自不同的部门不同的岗位,难免会发现有些需求是互相矛盾、互相冲突的。

  因此我们在整理后的列表中需要将这些矛盾的需求全部圈出来,然后快速地找到相关人员,通过进一步的沟通协调来消除矛盾的需求。

  很多时候,需求冲突的真正原因是使用者与管理者之间的冲突。作为使用者,他的核心是方便高效、省事,最好还能在某些方面获得一定的利益;作为管理者,他的是流程规范、过程可追踪,杜绝损害公司利益的事情发生。

  例如,项目管理人员/市场部因为委托方有很多不确定因素,自然希望在项目申报的时候能够更弹性,有一些度。但是作为主管部门领导,他们需要严格执行审批制度、财务报表审批制度等,导致系统上有很多信息是必填项,操作者感觉很繁琐。

  在发生冲突的时候,我的是以客户的生产经营为核心,首先确保经营活动的规范化、流程化进行,在这个基础上增加为普通使用者考虑的易用性设计与情设计,让他们感受到产品不单单是一个反感的工作系统,而是真正帮助他们提高工作效率的产品。

  完成这一步后,才算是将整个产品的系统需求全部整理出来。以后每次迭代就是在业务需求与用户需求的基础上,创建新的系统需求,不断完善、丰富产品。

  大多数C端产品的设计逻辑会把用户体验与效率放在首位,追求极致的简单好用于高效。在整个产品设计上比较侧重用户的感受,精心打磨页面与交互,尽量少让用户做选择,保持产品的易用性与流畅性,都是做C端产品设计的不二。

  很简单的一个例子就能明白:我们按照客户的需求上线CRM模块,不是为了让市场人员更轻松,做业务的时候更“省事”,而是为了将整个客户跟进的流程管理起来,做标准化的流程,为管理者提供更准确科学的决策。

  又比如提到的,班主任和之间的互动基本都是靠微信群进行,这就要求我们产品增加微信一键登录,微信分享机制,来减少的操作径。

  B端产品更多是通过计算机技术实现B端客户的信息化管理,对业务流程进行优化升级,从而达到降本增效的目的。

  由此可以看出来,做C端产品更注重对“人”的理解,要求产品经理具备同理心,用户的能力。而做B端产品更注重对“业务”的理解,要求产品经理具有系统性的逻辑思维,富有地对客户业务进行全面梳理与诊断,给出合理有效的解决方案。

  非常理解,b端产品最重要的是提供一套客户需要的解决方案,对于很多产品经理眼中的亮点功能,比如产品的美观度、可用性,他们真的没有特别大的观感

  看大家对作者的观点站在不同立场各有其道理,我觉得,B端产品先是功能满足,就是作者说的省事,再是好用,也是作者提到的用的舒适。结合这些年B端产品实施经验,大致是这么个情况。但是,需注意是,省事满足,舒适度很差,使用繁琐,那这个B产品可能很难用起来

  文章有标题党嫌疑哦 其实主体都在讲分析使用场景和需求的东西 作为产品新人 学到的是角色和使用场景分析这部分内容 说真的 和UX关系不大 所以楼上的也大可不必

  作为一个UX设计师,对你这个观点持100%反对的态度。B端产品比C端产品更难做,是因为B端产品不仅要以决策者为本,还要以人为本。B端产品的用户体验也不仅仅是使用者,B2B的产品,在与企业合作前、合作中、合作后,都必须使用户体验朝着好的方向去发展,通俗地讲就是合作前把客户陪好也是一种用户体验,客户的体验好了,也能推进合作。

  也许作者将用户体验片面的理解为是操作体验,但同样的,使用B2B网站的业务专业人员也在大量的B2C网站上操作,Jakob Nielsen的互联网用户体验定律指出,用户会从他们访问的大多数网站中形成自己的心理模型期望。

  欢迎大家来拍砖,互联网产品只是工具,SAAS服务盛行,可代替者很多。我在做B端产品经理的同时,兼职着售前工程师的工作,能接触到更多的一线客户,深有体会,我相信任何做B端产品的公司,一定觉得自己的开发资源有限,因为需求永远无法全部满足,怎么在有限的资源上,开发出更符合客户要求的产品,我想良好的用户体验就不是团队的重要方向了,细节当然重要,更重要的是“流程”,如果这个方案搭配着我们的管理和运营系统能让客户原有的业务走的更快,走的更广,即使我们产品页面颜色做的不好看,图标不协调,客户也愿意给我们付费,这就是B端产品的思维,所有B端产品设计都是为“流程”服务的。,所以体验和效率未必是设计的重心。这是本篇文章的观点。谢谢!

  所以你说的是狭义的用户体验,你所说的为“流程”服务,注重“流程”,这个“流程”也是用户体验的一部分

  这篇文章的结论有些片面了。现阶段的B端用户用了太多C端产品后,对B端产品的用户体验的要求也是直线上涨,不但要求功能实用,也强烈要求好看好用。

  文中的这个客户,恰好可能就是对这块要求不算高的客户。也许换一个客户,这个结论就会被直接。

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。


 

Copyright © 2010-2011 广州fun88乐天堂信息科技有限公司 All rights reserved. 冀ICP备15006456号-5 网站地图