全方位解析 C 端和 B 端的产品特性

news2024/11/19 0:29:38

近年来,互联网进入下半场,C 端流量红利逐渐消退,很多企业转向了 B 端服务,随之而来的是产品设计者的转型,现在越来越多的 C 端产品设计师开始涉足到 B 端产品的设计,这是一个知识迁移的过程,需要认识到这 2 类产品的特点和区别,你才能够快速适应这个迁移的过程。

在互联网和信息化高度发达的今天,我们都是 B 端和 C 端产品的用户,能切身体会到产品的好坏,那么两个完全不同类别的产品放在一起时,会有什么新发现呢?今天想通过自己的设计历程,来梳理这 2 种产品的区别和价值。

C 全称是 Customer,即消费者(泛指用户)的产品,个人用户或终端用户,使用的是客户端。例如:微信、网易新闻、网易云音乐、有道翻译官、网易考拉等等。

B 全称是 Business,即商家(泛指企业)的产品,通常是企业或商家,为工作或商业目的而使用的系统型软件、工具或平台。例如:京东云、阿里云、网易云、网易有数或企业内部的 ERP 系统等等。

相同点

1. 都要给人使用

小到打车、外卖和购物软件,大到逻辑复杂连产品经理有时候都犯糊涂的企业级业务系统,无论个人用户,还是企业用户,本质都是由人来使用,只不过产品类型不同。

2. 都要兼顾用户体验和业务之间的平衡

既然是给人来使用的产品,就要兼顾用户体验和业务之间的平衡。无论是 C 端或 B 端,谁都不愿意使用一个不好用且耽误效率的产品,当然还是会有一些用户体验较差,用户又不得不使用的产品存在,因为它可能具有一定的垄断性质,或者在某些场景下被强迫使用,用户本身是别无选择的。但不能说用户体验就不重要,只能说对于业务更复杂、为工作而生的 B 端产品来说,想要做好这一点会比 C 端更困难。

3. 都要坚守做产品设计的核心思想

对于每一个产品设计者来说,「在什么场景下为怎样的用户(客户)采取什么方法解决哪些问题」,这句话是再熟悉不过了,也是经常讨论或挂在嘴边的话。可是面对工作中蜂拥而至、突如其来的事情时,却又常常容易忽略掉。就像是一个人如果太饿了,只顾着吃饭填饱肚子,却忘记了吃了什么。

不同点


 

1. 目标用户

首先,我们明确一下 C 端产品和 B 端产品的用户是谁,产品给哪些人用?

 

C端

产品是面向个人用户,服务于每个脱离「企业」场景之外的人,也就是生活场景。他需要做更细致的用户画像,比如:用户的年龄、职业、文化程度、收入水平、工作单位、个人喜好等都会影响到功能设计,每个人都可以对产品提出优化意见,这个意见只代表个人,而不是任何社会群体,但这些意见只要被产品经理验证是可以提升产品价值的,就可能会排进迭代周期内。

相对来说,C 端产品不管从服务范围、渗透力、密度都远远超过 B 端,原因是因为它面向的用户群体更广泛,用一个核心功能解决大多数人的一个主要诉求,我们每个人随时随地都可以成为 C 端用户,可选用的产品也非常多,产品团队更多的思考是让我们更长时间的停留在产品上面,让用户有更高的粘性和活跃度,需要利用产品的特色功能和优质体验来吸引我们,并解决我们在生活便利和情绪方面的问题,让我们享受这些服务并为此买单。

B端

产品则是服务于企业用户,这个「企业」可以是一个组织、商家、团队,是某种经营的主体,当然使用者也是个人,不过这个「个人」是代表了组织中的某个角色而已。这类人无论性别、年龄、地区有何差异,他们都是一类角色,比如企业中的项目总监、项目经理、项目顾问,我们的产品要提供给这类角色使用,而不是某个人使用。假设我们做一个项目管理系统,主要提供给项目经理使用,张三和李四都是产品的用户,也许张三在工作之外是个活泼少女,喜欢刷短视频、购物、旅游,被简约的界面风格所折服;李四却是个内向宅男,喜欢宅在家里打游戏、看书,喜欢炫酷的界面风格,但他们的个人喜好都无法影响系统功能的设计。这里说的功能设计的主要依据就是企业对项目经理这个角色的业务定位和考核目标,他们共同的角色都是项目经理,所以系统只需要提供项目经理相应的功能和体验即可。

所以功能设计需要是多个业务功能满足特定人群的多个需求、多个场景,他所面对的用户具有特定的职业属性,也就是说他的用户只会在「工作」的场景下使用他,有些还是强制使用,个人没有选择余地,因为付费者是企业领导,而不是基层员工,而使用最多的反而是基层员工,所以 B 端产品的用户关系会比 C 端更集中、更垂直,做功能设计时,要权衡付费者和使用者之间的利弊,他们要求产品的时效性,注重如何满足企业用户的既定目标。

2. 使用场景

C端

它会存在于生活中的各种场景下,而且自由度非常高,当然也包含工作场景,比如我在坐地铁时刷一下朋友圈、在睡前打开网易云听歌、在工作间隙上点了一份外卖、周末变身肥宅吃了一天鸡等等,所以 C 端产品的使用场景是碎片化的,用户并不会连续几个小时一直盯着同一个 APP,而是在多个应用之间随意切换。比如落地成盒了会打开微信回复消息,歌听乏了去看看电子书等等,所以我们看到一些比较优秀的产品,他们都在内容和用户体验上下足了功夫,目的就是为了留存用户,减少跳出率。因此 C 端产品更讲究操作直接,信息简洁,有娱乐性、社交性、可倾诉性,是为了解决生活上的问题而生,寄生于我们的情绪之中,被产品的情感化设计所折服。

B端

与 C 端正好相反,他们是为了工作而使用这个产品,因此他们必然要长时间使用产品,而且是沉浸式使用,同时使用频率是可预测的,他们并不能带着个人喜好去使用,不能说这个产品太难用了,我就可以不用了。比如上下班打卡,公司要求用 A 产品,你觉得不好用,就推荐大家使用 B 产品,对不起,虽然你是产品真正的使用者,但决策权和付费者是高层领导。个人的情绪左右不了使用场景。所以 B 端产品更讲究严谨的流程设计、贴近现实的场景面积、低风险、高效率、数据精准。它是为了解决工作上的问题而生,寄生于企业制度之中,被产品的用户体验影响着工作效率。

3. 业务和本质

 

C端

满足自我情绪。

比如社交类产品就是构建「聊天」方式,这个聊天可以是语音、文字、图片、分享等形式,解决个人在情感、空间、工作、虚荣、欲望等情绪问题。在核心功能之外还可以附加一些「增值功能」,比如设置好友查看权限、购买 VIP 等,这都是为了提高产品的使用价值和盈利口径。

因此 C 端产品通常只有一个核心功能(比如音乐类 app 的核心功能就是听音乐,阅读类 app 的核心功能就是阅读,游戏类 app 的核心功能就是游戏),多个辅助功能,核心功能影响着产品的特色、定位、调性,而合理的辅助功能则会让产品保值增值、增强产品与产品之间的差异化,如果去除这些附加功能,产品的体验会受到一定影响,但实际上并不会阻碍用户使用核心功能。例如:去除了评论功能,但用户依旧可以听音乐;去除了打赏功能,同样也不影响用户阅读文章和作者写文章;去除了分享,用户还是可以愉快地吃鸡。

所以 C 端产品的特性可以归纳为「分享」,前面所提到的「评论」、「打赏」其实都基于「分享」的场景下,即:让他人听见「我」的声音、看见「我」的想法、赞同「我」的观点,满足双方的情绪设定。

盈利方式:内容付费、广告付费、平台抽成、增值服务(VIP、卡券、权限等)。

B端

共同完成一个目标。

日常使用产品工作的人,自己是无法独立完成一个任务的,他需要和周围的人协同完成一个任务流程的闭环,比如我发起一个请假申请,以「完成」和「打回」作为流程结点,根据企业制度设定,这个流程中会涉及到 3 种角色:发起人(我)、审核人(上级)、归档人(人事或行政)。

B 端产品的业务逻辑是复杂和多变的,尤其是权限系统,往往每个人都是流程中一个非常小的部分,就如上段所说,需要进行协作使用,这里不能穷举出每个业务,因为不同的公司业务则完全不一样,公司可以对该产品当中的功能选择性购买或租赁。而对实际用户来说,这个产品没有功能的层级,自己负责哪一块,哪一块就是他的主要任务、经常使用的功能。也就是说,从功能架构上看,这些核心功能都是扁平的,他们分配到各种使用角色的手中,没有先后排名。

而 B 端产品的本质则是满足用户的工作需要,但这从来不是单一的功能就可以满足的,这里一定包括了多项功能的组合及嵌套应用支持。当用户需要绘制多种不同类型的图表时,产品就绝不能只提供单项类型的图表功能。比如:甲公司的产品只能画柱状图,而乙公司的产品却能画 10 种甚至更多不同类型的图表,以适应不同需求场景,若你是客户,你会选择购买哪个产品呢?

盈利方式:按功能模块付费、按使用人数付费、需求付费、后期维护费用。

4. 产品需求

C端

更多满足使用者的日常生活需求,所以需求来源会多样化一些,因为目的都是拉新、促活、留存、转化、裂变。像竞品分析、数据分析、用户行为分析都可能帮助挖掘出有价值的需求。我们也有很多时候因为朋友在用这个产品,或者看到产品的广告才下载这个应用,但下载以后用来干什么,那只有等我们有诉求的时候才会再次打开应用,这个诉求可能是空虚、无聊、想购物了等等。所以很多普通用户根本不知道自己的真实需求是什么,甚至有时阴差阳错打开某应用,然后被里面的买家秀、活动促销等运营模块所吸引,最后产生购买欲望。

因此,C 端产品就是站在上帝的视角,需求直接来源于用户的行为和反馈,从用户这里获取最真实的诉求。产品设计者则需要关注市场流行趋势,关注用户偏好及意见,将有效的分析结果转化为产品需求,再输出功能,引导用户产生共鸣,并通过一些运营手段,增加转化(变现)概率和裂变的辐射面积。

B端

B 端产品更多是基于已有的「业务」形态,把传统线下工作,通过程序化、系统化、信息化转换为线上行为,使业务的流转效率更高,办公成本更低。所以更要求产品设计者能熟练掌握相应的行业知识、捋清业务逻辑。

需求一般来源于产品战略定位、各部门对接、租户(客户、外部付费者)的个性需求,有些靠销售企业软件盈利的公司为了把职责再细分,通常会配置指定的一线顾问来对接租户的需求及跟进服务,然后再将需求反馈到负责这个产品的产品经理,产品经理在这里就是负责收集需求、分析、规划、设定开发优先级,然后交由开发团队进行接下来的产品设计等工作。

B 端产品的客户可能不在网上,而是在全国各地的企业里,往往需要通过老板和销售才能接触到客户,这会造成不能获取真实的客户需求,我把这种现象叫做「需求断层」。所以最好的调研方式就是做一个「面对面」的用户访谈,可以真实的面对面、也可以是视频或者电话沟通,这能容易把复制的需求沟通清楚,而不是通过邮件和文字。因为目标用户有固定的职业领域,有时候你所设计的流程你认为最合理,但和他们实际使用起来却有很大的差异,所以和真实用户面对面聊聊他们的工作习惯和业务规则,这一定能够帮助到你设计产品。

很多时候,做的产品只是为了满足付费者(即高层领导)的需求,而不是实际用户(即基层工作者),导致实际用户吐槽产品易用性差,其实是改变了他们的工作习惯而引发的抱怨,然而领导却达到了监控和实时获取数据的目的。因此在收集这些需求时,会受到来自付费者和真实用户 2 种角色声音的影响,这就需要产品设计者具有更理性的思考方式和处理手段。

5. 产品思维

 

C端-流量思维

做 C 端产品设计,我们一切行为的出发点,都是流量,流量直接影响着变现,无论是外部的流量引入、各环节的转化、留存策略,还是产品体验的提升、流程的优化、资源的投入,我们都是在为提升流量、转化流量服务。我们经常做的各种活动专题、分析各类数据,去追求所谓的情怀、情感化设计,其根本还是为了引流,想方设法从全网获取流量,从而来提升产品的转化率,这是一切 C 端产品的宗旨,没有流量的产品只是一个花瓶。

B端-效率思维

对于 B 端产品,我们更多关注的是效率,不管是面向外部客户,还是服务于公司内部各业务角色/部门,B 端产品要解决的始终都是如何提升企业的运营效率(即工作效率),解决的是「开源节流」中的节流部分。所以我们会通过流程优化、工具打磨、策略调整,去提升各个环节的人效,降低各方面成本,从根本上提升企业效率,这点从我们做流程设计的时候能清晰的反应出来,设计目标都是在合理且效率的基础上,让用户舒适的完成这个流程,并不是说企业投入资金购买了一款数据统计软件,结果数据统计还没有人工来的精准、方便。

6. 设计原则

C端

在 C 端产品设计的过程中,我们首先要明确核心功能是给哪些目标用户使用的,也就是我们最初的设计目标是什么,需要保持产品的场景多样化,突出核心功能,因为 C 端产品的同质化现象非常严重,因此我们要好好思考,如何将我们的产品在众多产品中脱颖而出,如何让产品的品牌设计辐射到更多的地方,如何在功能和体验上寻找新的亮点。

再者就是要保持良好运营手段,因为 C 端的用户是自由的(忠诚度低,随时可以换产品使用),所以需要通过一些运营手段来绑定用户的留存。C 端产品的本质都是一个核心功能,所以设计师在产品初期时就需要全盘考虑,哪个功能是产品最核心、最不可丢弃的,哪个功能是锦上添花,为了提升产品的附加价值的。因此,我们抛开这些基本原则,还需要对用户行为进行塑造,塑造用户行为就是「绑架」用户。

把握关键时机:把握用户在使用 C 端产品过程中注意力的关键时机,用户在使用产品的过程中,注意力的分配是不均等的,比如同类产品太多,先下载 2、3 个试用,进到产品里不知道干什么,随便逛逛,逛着逛着就删除 APP 了,这就是典型的没有把握用户关键时机,没有提供给用户有用的东西,败在了产品策略和本能层次。没有在第一时间让用户知道产品是干什么的?能从中得到什么?亮点内容在哪里?是如何引导我使用的?那么作为产品的界面设计师就需要知道在哪些关键节点上,用户的注意力是集中的,哪些节点是分散的,如何引导用户关注这个点。

所以通过研究这些用户在使用过程中的关键节点,可以抓住关键时机,来达到塑造用户行为的目的。那么,这些所谓的「关键」时机反映在注意力理论下,对应的就是注意的「中心点」,反之为「分散点」。用户在使用产品的时候,注意力总是从中心和边缘来回切换。

举个例子:让交互设计师在信息流页面做一个阅读提示,用于用户在更新消息流之后的场景,目的是能让用户发现更新之前的阅读位置,并在此处刷新,不让重复信息出现,不影响用户体验。那么下图中哪个方案更合适?

 

中心点:「上次看到这里,点击刷新」的提示消息出现在此位置和时机是有讲究的,由于它们出现在旧消息之前,新刷新的消息之后,用户的阅读注意力正在从新的信息流转到旧的信息流,中间会出现注意力断层的中心点。所以在此出现的提示更容易被用户察觉,提示内容才能发挥更大的价值,因此 A 方案最合适。

分散点:B方案中消息提示在用户刷新之后出现在底部,虽然该方式在 toast 的层级里,干扰性是最低的,因为它的位置在底部,会适当减少用户浏览内容时所产生的干扰,但是从用户行为路径上看,显然不合适,用户的行为是要翻阅信息流,而它的出现方式与「翻阅」的行为是相违背的,反观还是会阻碍用户的浏览,虽然它的感知程度很强,能让用户第一眼发现这个贴心的功能,但是出现的时机不对,这就影响了用户体验。

增加趣味性:所谓趣味性,是指能引发用户的正面情绪,比如使人感到愉悦、有意思,能感染人、打动人、教育人,这是能够引起用户注意力的重要因素。

增加产品趣味性的途径有很多种,就拿微信 H5 为例:

随着 H5 页面技术上的突破和微信推广程序井喷式的发展,微信 H5 推广领域已经成为各大 C 端产品的必争之地。推广的形式可以基于 H5 的框架进行多种形式的拓展,比如:小游戏、邀请好友赢红包、小程序等等。微信端 H5 推广的优点就是将推广的趣味性融入产品当中,将营销手段运用在用户使用过程中。这样做的好处显而易见,通过趣味的游戏程序打开市场的缺口,用户基于推广程序的趣味性,有很强的分享动机。

说到分享动机,就不得不说最近刷爆朋友圈的《能进***的个个都是人才》,这个长图就很有意思,每段内容都能让用户产生共鸣,根本想不到这是篇广告推文,直到最后一小段内容才曝光了品牌和产品,但效果显而易见(短短几天阅读量10万+),所以这种趣味性的运营方式很容易带动用户去分享,分享即裂变式传播,而 C 端产品的运营目的就是引流、裂变。

 

增加创意性:王者荣耀无疑是近年来受众最广、用户最多、盈利最大的线上手游。我们通过分析这样一个标杆级的产品,可以得出创意对一个产品的成功与否到底起了什么作用?这款游戏火到咖啡厅一群人坐在那里玩一中午的原因在哪里?我想用我设计的眼光去审视一下王者荣耀,它到底为广大玩家提供了一种怎样的体验?

「容易上手」几乎是王者荣耀玩家的共同感觉,而这种直观感觉决定了一款手游能在多大程度上流行。一方面,王者荣耀采用了双轮盘(左右两边一个操控区域)的操控方式,玩家通过左右两边的虚拟按钮进行控制,同时可以控制自动攻击。新手玩家默认自动攻击,从可玩性角度很大程度上减少了用户的学习成本。

双轮盘的操作方式并不是王者荣耀首创,但是他却成就了这种经典的交互方式,为后来产品树立了一个成功的典范。操作方式的创新点还在于取消技能施法的方式。区别于 PC 端游戏,移动终端没有鼠标来控制技能释放与否,王者荣耀采用技能滑至右上取消的方式,创新性地解决了小屏幕交互上存在的问题。

 

除了以上几个设计点外,C 端产品的设计手段还有很多,主要包括:推送提醒、各种红点提示、弹窗提示、嵌入广告、分享刺激、打赏刺激等。无论采用任何设计方法,其核心的目标始终是落在用户的注意力上,通过吸引用户注意的方式,达到塑造用户行为的目的。

B端

产品设计者对于用户的需求在一定程度上是可知的,所以 B 端产品是辅助用户行为,比如我们要做一个企业报销系统,这些流程和工作行为已经有一套标准的流程了,我们只需要将这些场景转化为流程设计。那这个系统会存在哪些场景,只需要找到相应的使用角色一聊就能挖掘出来,而且场景相对较固定,不用考虑用户是不是喜欢这个功能,因为这是公司制度要求,不喜欢也得用。因此在设计初期,我们要做的就是充分挖掘相应的功能需求,尽量把流程做到完善,而在设计上要有:合理的功能与模块划分、严谨的业务流程设计、一致性的操作体验、干净简洁的界面设计。

合理的功能与模块划分:即在做产品信息架构时,就需要仔细考虑功能、模块的划分,客户常用功能模块有哪些,模块与模块之间的关系是怎样的,当然有些产品版本是通过客户需求进行个性化设计的,比如有的客户要求为他们企业单独设计一套工作流程,那么怎样组合该客户的功能模块呢,这也是做 B 端产品经常遇到的需求。而对于不同岗位的人员,他们的权限划分也是不同的,比如在不同权限人员登录时显示的页面有哪些不同?能查看到的模块有哪些,里面的界面状态是怎样的?如果某岗位人员拥有不同的权限范围,怎么设置他的功能可见性?不同权限的人员怎么协同工作?需要多人协作办公时,如何进行业务上的移交、提醒、工作流的显示?这些都是设计师需要仔细考虑的点。

都说 B 端产品业务复杂,细分下来,权限设计就是最要花心思的,因为它涉及到不同的用户角色、岗位、场景,不能像 C 端那样常规化。

 

严谨的业务流程设计:B 端产品不用揣测客户打开产品会干什么、引导他干什么,因为他是工作软件,在使用时,客户必然有明确的目的,需要什么他自己会打开,因为都是他们自己最熟悉的业务范围。总不可能利用碎片化的时间在工作软件上休闲一下吧,这个场景明显不成立。同时,设计师需要对产品的行业和业务具有一定的了解,如果产品只针对单一行业,设计师只需要了解对应行业的特性和需求即可,若是平台类产品,需要面向多元行业,那设计师就需要了解所有的目标行业特性,找到他们的异同点,针对不同使用场景,分析客户的具体需求,最后产出合理且专业的流程方案。如果你不了解客户的工作业务,你就不能有质量的产出他们满意的流程方案,所以做 B 端产品不光要学习本职岗位的技能,还要了解目标客户他们的工作流程、业务知识。

一致性的用户体验:无论是 B 端还是 C 端产品都应该遵循这一点,这是互联网产品最基本的素养。保持交互和视觉的一致性,让用户在使用时,能感到熟悉、亲切,能直观地了解到操作会带来怎样的结果。在用户疑惑时,及时给予反馈,在遇到困难时,给予帮助。在用户迷茫时,有效引导用户,这就是一款聪明的产品,它能够提前预知到用户的所想所需。同时,B 端产品的界面元素复用面积会比 C 端广而大,因此 B 端产品更应该注重交互的一致性。做过后台的都应该知道,一个提醒方式、一个表单控件,它们能覆盖到 80% 的页面。

干净简洁的界面设计:B 端产品是为了工作而生,界面里往往都是「内容为王」,不宜使用过于强烈的色彩对比,也不需要过于浮夸的设计,整体产品调性都应该尽量简洁,不要让视觉效果喧宾夺主,而应该减少干扰用户的「多余设计」。这里不是说炫酷的设计不实用,而是 B 端产品的目标用户不同于 C 端用户,B 端用户主要是通过产品来完成枯燥的工作,即便视觉效果做的再吸引用户,他们也不会给你的产品带来流量和黏度,因为买单者是高层,使用时间也相对固定。所以还不如把开发、设计的成本放在提升产品性能和流程体验上。

虽然我一名设计师,但毫无疑问,做 B 端产品必须要维持:功能为主的设计原则、视觉服务于功能的产品素养。这也是为什么很多 B 端产品喜欢用蓝色系的原因,因为与蓝色相关的负面信息很少,同时色彩上也不会过于强烈、刺激,一般人都不会排斥它,并且色彩含义也为理性、商务、科技,这就更适合 B 端产品的特性。

 

关注点

1. C端关注人性

 

产品强调:刚需、痛点、高频、体验。

刚需

在 B 端产品设计中,我们往往面对的是刚需。用户会非常明确的告诉你,几乎无需挖掘,「我想要什么功能,我线下是怎么完成这个任务流程的,有这个功能我就付费,没有这个功能我就不买单」。当然,用户所讲并非用户所需,需求仍需要梳理和验证。

而为什么 C 端产品却要刻意强调「刚需」?因为 C 端产品的需求不同于 B 端产品,C 端产品的用户量大、散、广,缺乏组织性,需求具有模糊性,所以需要刻意去挖掘。经常看到一些产品 YY 出一些客户需求(「我」认为的设计),其实这些需求用户根本不需要。

痛点

在 B 端产品中,用户选择产品的决策过程中,有足够的说服时间和机会,另外价格也会是一个非常重要的参考因素。

而在 C 端产品中,用户喜欢更换成本较低(QQ和微信等社交类C端产品的更换成本很高,不在此列)、决策时间短,所以能否在极端的时间内,抓住用户痛点,就非常关键,比如通过运营活动和情感化的视觉设计,在短时间内引起用户的共鸣,形成热点式引流。如果不能抓住用户痛点,产品很可能不会被下载,即使被下载,使用频率也会非常低,渐渐的就藏在手机某个角落几个月不更新,从隐藏逐渐走向了删除,这样的产品就会丧失竞争力。所以很多 C 端产品经常推送一些运营消息,文案还特别吸引人,目的都是为了让用户回归,告诉你它还很想你。

高频

在 B 端产品中,用户使用频率是由业务和工作量决定的,所以提高 B 端产品用户使用频率的机会并不多,总不能节假日的时候推送一条消息「少年,快回来工作吧,加薪升职就是现在」,这样做毫无意义,也违背了它本身的商业价值。

而在 C 端产品中,用户粘性、付费率、转化率、活跃度等往往跟用户使用的频率紧密相连。C 端产品很多都是免费使用,通过增值服务收费,比如充值 VIP 享受更多特权等,只有通过免费的方式,让用户先使用,从而培养了使用频率,这才是增值服务收费的基础。所以高频和流量就成为了能否实现增值收费的关键点。

体验

C 端产品由于用户缺乏组织的压力,并且更换产品的成本低到没有,删除你就是几个交互手势而已,所以 C 端产品必须极其重视用户体验,想尽一切办法留住用户、锁住用户、让用户把产品当成生活中不可分割的一部分。

用户体验对 B 端产品也非常重要,但通常客户更重视功能、流程和效率,而用户体验则更多的体现在产品性能方面,试想你使用一款软件工作,由于产品性能响应非常迟钝,而且数据不精准,你一定会很抓狂,很有可能一天的工作计划被这款「该死」的产品所耽误,所以在用户体验上,性能要比界面更重要。

2. B端关注组织与业务

 

产品核心诉求:功能、流程、效率。

功能

不同于 C 端产品需要深入挖掘用户的需求,B 端产品的需求往往是非常明确的,在功能的场景覆盖面积上,和 C 端产品恰恰相反,功能多、大而全,这代表了一个 B 端产品的完整性。但这里所谓的「功能多」,并不是一些杂七杂八的锦上添花的功能,而是为了覆盖到更多业务场景的主要功能,这样才能拿去卖钱,才能给客户选择性使用,才有了更多的商业竞争机会。

至于功能过多而产生的学习成本过高现象,在 B 端领域也不是一个大问题,因为 B 端领域的客户往往需要专业的学习,客户也通常不会认为是负担,反而因为掌握了这些技能而实现了自身价值的增值,因为 B 端产品是公司主动要求员工使用的。其次我们作为 B 端产品的开发者,很多公司也会提供相应的业务培训和售后服务。

当然,SAAS 类产品(B端产品之一)由于免实施的特点,决定了功能要全面、又要容易上手的特点,所以 SAAS 产品是 B 端产品中最难设计的一种,需要在商业和体验之间权衡。

流程

既然 B 端产品要满足业务信息化的需求,那就必然涉及到流程设计。B 端系统必须要能贴合企业用户的业务流程才能正常运行,而不同企业的流程是不一样的,所以 B 端产品的流程设计是一个非常大的挑战。

因为很多时候 B 端产品是将线下的流程转移到线上,实现无纸化办公、敏捷办公,所以功能流程已经在线下有一套完善的流程了,只需要在现有的流程上做简化和整合即可,甚至一些线下的纸质文件在线上变成电子档时,客户都要求贴近原始文件,只有这样才能顺从之前的使用场景,降低学习成本,所以前面为什么说做 B 端产品设计要懂业务,就是因为产品里的功能流程是线下转移到线上,了解线下业务能帮助你更严谨地设计线上流程。

效率

B 端的产品的业务经常涉及到海量的数据,所以在 B 端产品中,效率远远比用户体验更重要,客户不是在休闲时刻把玩你的产品,而是通过你的产品完成工作任务。比如要上传 1000 条数据,那么批量上传等高效率的功能设计和性能保障,就比优化上传界面的用户体验要重要得多。

至今我们仍然可以看到有些商超还在用一些 DOS 平台上开发的收银系统,虽然这些系统已经非常陈旧、用户体验已经很差了。但是由于使用时间很长,而且效率非常高,所以依然保持着旺盛的生命力。

产品特性对比

  1. 客户VS用户

客户

使用 B 端产品的人或组织。说白了就是给钱的合作方,它们通常是一个企业,以企业或部门的名义,购买或租赁了你们公司所开发的产品。

用户

使用 C 端产品的人。而个人使用者则是不受工作场景限制的每个人,拿起一个产品就可以注册登录,并直接上手把玩。

客户是理性的,用户是感性的。客户关心 ROI(投入产出比),用户关心过程(满足人性的某个弱点)。

举个例子:双十一基本上成为一个全民狂欢节,很多人吃土也要剁手,为什么?因为便宜,很多人趁着氛围一冲动就各种买买买了。

但我们很少听说有 B 端产品在搞促销,一是因为企业的采购通常有计划安排,可能还需要财务的各种审批,不太可能刚好就在你促销的时候企业就需要采购;二是企业的采购要考虑投入产出比,而不会因为你打个折扣就决定买你家的商品,这关乎到企业利益和你自己的利益。

但个人用户不一样,购物车存了好长时间的商品,总是嫌贵舍不得买,可是看到双十一突然打5折,这下便有了冲动的借口,毕竟错过再等一年。

客户有级别之分,用户则基本一样

企业有大小之分,10 个人的微企业和 100 个人的小型企业是不一样的,同样 1000 个人的中型企业和 10000 个人的大型企业也不一样。更准确地说,对于同类产品不同大小的企业它们的需求是不一样的,可能因为企业的管理方式不一样,有些企业会提出一些个性化的需求。

比如同样需要内部沟通产品,10 个人的企业大家都坐在一个办公室里,需要找谁讨论问题,吼一嗓子隔壁公司都能听见,随时随意可以开会,需要的只是传播声音的载体──空气。

但如果是 100 个人的小型企业,可能吼一嗓子就没那么好用了,因为不是每个人都熟悉,并且座位可能会离的很远,这时候就需要一个微信群方便大家沟通,这时的传播载体是──微信群。

如果是 1000 人的中型企业,跨部门协作的场景就非常多,很多时候要找的人是不认识的,还有可能对方故意潜水半天不回信息,这个时候提高沟通效率就显得特别重要,所以「钉钉」和「企业微信」的「已读、未读」功能就很受这种场景的欢迎,对方是否在故意潜水,就看是不是已读,如果长时间未读那就可以通过语音或电话找,所以中型企业就很适合用这类产品。

那 10000 人以上的企业,可能「钉钉」和「企业微信」他们的原生功能也不一定能满足复杂的协同需求,需要更多人性化的功能,这种情况一般是自己开发相应功能,或外包给第三方开发,然后接入「钉钉」或「企业微信」。

上面说的是 B 端产品面向的客户有大小之分,下面我们来看看 C 端产品面向的用户是怎么基本一样的。

再拿微信举个例子,从身份地位、收入上看微信的用户也是千差万别,但是从微信满足的人性弱点角度来看(懒惰、窥窃、色欲、存在感、虚荣、贪婪、冲动、从众、分享、嫉妒等),用户与用户之间并没有什么区别。一位成功人士和一位无业游民都有懒惰、虚荣等缺点。只是严重程度可能有所差别,他们都有通过朋友圈各种「炫耀」的需求,只是炫耀的内容可能不一样而已。所以作为 C 端产品,理论上是能满足所有用户的需求的,当然有极少部分是不看不发朋友圈的,这种小概率群体可以不计算在内。所以 C 端产品留下来的用户,他们的需求都是被该产品所解决过的,因为这些用户都有相同的需求,虽然他们的身份都不一样。

2. 工具VS「玩具」

工具的目标是性价比,玩具目标是休闲

性价比包含了两个指标,性能(效率)和价格。不难理解的是,企业之间的竞争本质上就是生产效率的竞争。所以企业采购的工具(B端产品)肯定是为了提高生产效率,比如各种管理系统是为了提高客户管理的效率,数据库系统是为了提高记录和运算的效率,在此基础上再横向对比价格,性价比最高的当然最适合。要吸引企业来购买产品,B 端产品不得不考虑产品效率和价格。

「玩具」的主要目标是好玩、休闲,这里指的都是用户体验,可以理解为用户通过碎片化的时间去享受产品给他带来的愉悦感、归属感、放松感,而用户体验则是吸引用户的重点。而满足人性弱点的体验就是好的体验,好的体验都出现在「聪明」的产品上,即「眼色活」、帮助用户思考、做到用户行为的前面去,讲的就是要满足用户「懒得思考」的弱点。比如我们都知道国民产品微信的用户体验做得很棒,其中有一点就是易用性,老年人都可以用的产品,满足了「懒」这一人性弱点,再加上其它的一些功能满足「虚荣(炫耀)」、「偷窥(看过去的朋友圈)」等弱点,就能让产品变得好玩,只有好玩才能引流,这正是 C 端产品追逐的目标,因为很多 C 端产品的商业模式都是建立在巨大的用户群体之上,有了流量,金钱也正在路上。

工具的生命周期比「玩具」的生命周期更长久

相对于 C 端产品,B 端产品的生命周期更长,一是因为 B 端产品作为业务工具,本身就比较复杂,开发这样的产品是需要大量的行业经验积累和技术积累,因此一款 B 端产品一旦赢得市场认可,就能建立经验和技术壁垒。二是 B 端产品基本都是要花钱购买的,一旦企业采购了该产品,员工也熟悉了如何使用,再换新的产品成本就比较大,所以更换的意愿会比较低。

C 端产品为好玩而存在,当新推出的产品更好玩的时候,那老产品的生命周期和地位可能要面临着挑战。比如 QQ 和微信推出后,短信就被替代了,同样是通讯类产品,微信和 QQ 就好玩很多。可能有人会说因为短信收费,这并不是最重要的原因,即便短信现在完全免费,估计也没几个人用了,因为微信不止能发消息,还能发各种表情、图片、语音、视频、支付等,自然前者就被后者所替代了。同理,当微信被玩腻,人们发现下一个产品更好玩时,微信也同样会受到挑战,可以对比下三年前和现在的朋友圈、订阅号原创文章的质量就明白了。对了,还有「昙花一现的子弹短信」。所有说产品都是有周期性的,只不过 C 端产品要比 B 端产品的生命周期更短。

工具复杂难用,玩具简单易用

B 端产品复杂难用这是众所周知的,而 C 端产品老人都可以用得很溜。为什么?一方面,B 端产品是工具类,用于生产,而不是我们的日常生活,使用工具很多时候不是人的本能行为,而是为了达到某一目的而学会的技能,因此一般是要经过培训学习才会使用,所以很多 B 端产品有售前/售后方案、使用手册、业务培训等等。

另一方面,这和 B 端产品的目标有关(效率、准确、安全),当开发资源都用在打造产品性能的时候,用在用户体验方面的开发资源难免会不足,所谓「功能先行」,就是这个道理。

而 C 端产品的目标就是易用性、易通性,只有用户体验做的比竞品好,才能赢得用户和流量。假如 C 端产品需要拿着产品说明书才能玩下去,那这种产品一定会被淘汰。

3. 「卖软件」VS「秀软件」

B端产品「卖软件」

之所以说 B 端产品的商业模式是「卖软件」,是因为 B 端产品实实在在的一手交钱一手交货,也就是说 B 端产品开发出来是要直接卖钱的。即 B 端产品从诞生第一天起就要考虑如何销售,甚至有些开发团队直接用原型 demo 去谈客户,最后还成交了。

通常来说一款 B 端产品如果能有几十万客户已经是用户量特别大的产品了,不像 C 端产品动不动就是上千万、上亿,甚至上十亿用户量。因此通过流量变现的方法是行不通的。可以想象如果一个企业工具里面插入各种杂七杂八的广告,这得受到多少企业用户的吐槽,关键是这些广告还不能直接变现,这里最基本的口碑就没了。另一方面,对于性价比高的 B 端产品,企业是愿意自主付费的。自然而然就形成了垂直变现的商业模式。

C端产品「秀软件」

C 端产品的商业模式通常是间接变现。通过开发出用户需要的产品,把产品的体验做好,内容形式有针对性,从而吸引更多的用户来使用。产品本身是免费的,比如百度,支付宝,微信等产品。在用户量足够大的前提下,通过广告、推广等方式变现,本质上就是流量间接变现的商业模式。之所以 C 端产品这么做,是因为用户群体足够庞大,当用户量足够大的时候,广告产生的收入就很可观,同时还能实现同类产品引流,把用户引导到各种「同父异母」的应用上,创造二次流量。比如「手机百度」看短视频必须要打开「全民小视频」和「好看视频」。

设计师从C转向B是什么感受?

不少设计师在做过一段时间 B 端产品设计后会感觉缺乏激情和多样性,因为做酷炫的视觉效果和时尚的微交互的机会并非常有。时间一长就会发现它既无聊又单调,整天面对一些表单、可视化数据,何时才能出头?时间一长会怀疑人生。

正因如此,设计师们感受不到设计带来的成就感,如果不重新认清自我、调整好心态、设立工作计划,很容易原地踏步。这里不是说设计师不利于做 B 端产品,而是要结合自己的职业规划做选择。

我从 C 端转战 B 端之后,发现 B 端产品吸引我的有以下几点。

1. 更有挑战性

B 端产品相对而言,场景、功能、业务流程、信息架构要比 C 端更复杂,面对的异常情况也比较多,一些专业性强的行业,甚至还需要一定的背景门槛,比如一些互金公司会帮助 PM 和设计师考取金融行业相关资格证。正因难度更大,设计 B 端产品才更具挑战性。

而C端产品目前各行业基本成熟,产品同质化相当严重,竞品中有大部分都差不多,设计师很多时候的工作就是在做领导和产品经理的需求,「借鉴、学习」成熟竞品的设计。而 B 端市场还处在发展中状态,现在正是市场红利的时候,竞品虽少,但商业竞争残酷,即便下载了竞品,你没有体验账号还是进不去的,所以从一定意义上讲,做 B 端产品的设计,很多时候都需要自己去调研用户需求,去摸索设计方法,并做出方案去验证它。对 UI 和交互设计师来说,复杂的业务场景和产品逻辑能让你养成严谨的设计习惯(思维),以后 UI 转交互,或转产品经理,B 端的设计经验都是一个非常牢固的基础。

2. 更能体现设计师的价值

上面也说了,C 端的成熟产品很多,产品也经过市场检验了,优秀的产品站在更高的角度,去除设计师自己的情怀来看,在一段时间内很难再有突破性的创新,只能在细节和体验上微创新,主要还是靠产品经理发现功能痛点或运营的手段,设计师在这种情况下发挥的价值有限,往往地位也很低下。一般的互联网公司,很多设计师都是执行者,很难参与到产品层面的工作,在开发眼里觉得设计师就是画图的。

3. 更能进行行业深耕

B 端设计师对行业、业务的了解远远深得多,他们做的不止是框架层和表现层的东西,每设计一个功能,必须要了解该功能在整个产业链的位置、功能目的,对其他业务环节有什么影响等等,只有对行业了解得更深入,才有更多的机会享受行业带来的红利。

以上是我的个人看法,当然设计师如何选择 C 端和 B 端,这和自己的兴趣、职业方向有非常大的关联。偏视觉的设计师做B端产品时肯定会有一些局限性,偏交互的设计师在你经历完 B 端的产品设计之后,你会发现 C 端的逻辑真的很简单。所以无论怎么选,请先考虑好自己的个人因素,并不能因为现在 B 端火,你就跟风,喜不喜欢、适不适合、能不能在 B 端领域生存下去,还是要看你自己。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/135812.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

自动驾驶专题介绍 ———— 摄像头

文章目录介绍工作原理实现功能分类按通信协议区分按不同感光芯片按像元排列方式介绍 摄像头可以采集汽车周边的图像信息,跟人类的眼睛最为接近。摄像头可以拥有较广的视场角、较大的分辨率,还可以提供颜色和纹理等信息。这些信息对于实现自动驾驶功能是存…

Mentor-dft 学习笔记 day48-OCC With Capture Enable Clock Control Operation Modes

OCC With Capture Enable 有一个OCC具有capture_enable输入,可以与自由运行的慢速时钟一起使用。当OCC指定为启用捕获(capture_trigger:capture_en)时,在输入自由运行的慢时钟上添加时钟门控器,以从自由运行的时钟输…

影响宝宝大脑发育的6个坏习惯,你可能每天都在做

“望子成龙,望女成凤”这几乎是每个父母的愿望。虽然有一个高智商的天才宝宝太难了,但从不妨碍父母希望孩子更健康、更聪明。所以大家都比较关注宝宝的大脑发育,希望宝宝的大脑发育更好,长大后更聪明。但在日常生活中,…

android 12+从后台启动FGS限制

后台启动FGS限制 限制简介 以 Android 12(API 级别 31)或更高版本为目标平台的应用在后台运行时无法启动前台服务,少数特殊情况除外。 如果应用程序在后台运行时尝试启动前台服务,而前台服务不满足其中一种异常情况,系…

vue前端打包Docker镜像并nginx运行

首先说明咱们的前端项目是基于Vue的,反向代理使用的是nginx 1.打包vue前端项目生成dist文件夹上传至服务器 新建一个文件夹,叫vueDockerTest,下面的文件都需要。 cert是你存放ssl证书的文件夹,nginx.conf 是nginx的配置文件&am…

Kotlin 惰性集合操作-序列 Sequence

集合操作函数 和 序列 在了解 Kotlin 惰性集合之前,先看一下 Koltin 标注库中的一些集合操作函数。 定义一个数据模型 Person 和 Book 类: data class Person(val name: String, val age: Int) data class Book(val title: String, val authors: List…

jmeter 5.5+influxdb 2.0+grafana v9.3.2 - 压测看板setup

Docker set up 安装docker应用 https://docs.docker.com/desktop/install/mac-install/,在官网下载docker安装包,和安装其他的mac应用是一样的操作。 设置国内的镜像仓库(拉取镜像会快很多) {"registry-mirrors": [&q…

叠氮-聚乙二醇-羧酸;叠氮-单乙二醇-丙酸Azido-PEG1-acid;1393330-34-1小分子PEG衍生物

Azido-PEG1-acid 中文名称:叠氮-聚乙二醇-羧酸;叠氮-单乙二醇-丙酸 英文名称:Azido-PEG1-acid; 分子式:C5H9N3O3 分子量 :159.1 CAS:1393330-34-1 外观:粘稠液体或者固体粉末&#…

SHA和AES加密+GUI Swing写的一个本地运行和保存的密码管理小工具

目录效果项目结构功能1、登录2、加密3、解密4、列表代码1、先准备好两种加密方式的工具类SHAUtilAESUtil2、登录窗口3、主页窗口(加密和解密面板)4、主页窗口(列表面板)5、主程序(main)最后通过SHA和AES加密…

TestStand-序列步骤属性

文章目录GeneralRun OptionLoopingPost ActionSwitchingSynchronizationExpressionPreconditionsRequirementAdditional ResultPropertyCtrl-N创建一个新的Sequence,通过右键创建任意步骤 General Name -步骤的名称。 Type -步骤类型。一般不需要设置。 Adapter-适…

Android Kotlin之协程-异步流Flow的使用

数据流以协程为基础构建,与仅返回单个值的挂起函数相反,数据流可按顺序发出多个值。从概念上来讲,数据流是可通过异步方式进行计算处理的一组数据序列。所发出值的类型必须相同。 数据流包含三个实体: 提供方会生成添加到数据流…

信息安全技术 政务信息共享 数据安全技术要求

声明 本文是学习GB-T 39477-2020 信息安全技术 政务信息共享 数据安全技术要求. 下载地址 http://github5.com/view/790而整理的学习笔记,分享出来希望更多人受益,如果存在侵权请及时联系我们 政务信息共享 数据安全 范围 本标准提出了政务信息共享数据安全要求技术框架&…

2023年工作第一天心情感悟

我是卢松松,点点上面的头像,欢迎关注我哦! 今天是2023年1月3日,也是我们上班的第一天。今天这篇随记,也发表下我对2023年的看法,也对过去的2022年做过总结。 (2023年元旦,到门头沟…

Spring之ApplicationContext快速入门

目录 一:概述 二:代码演示 三:BeanFactory与ApplicationContext的关系 四:BeanFactory的继承体系 五:ApplicationContext的继承体系 一:概述 ApplicationContext称为Spring容器, 内部封装了…

面试官:能用JavaScript手写一个bind函数吗

经常会看到网上各种手写bind的教程,下面是我在自己实现手写bind的过程中遇到的问题与思考。如果对于如何实现一个手写bind还有疑惑的话,那么可以先看看上面两篇文章。 手写bind vs 原生bind 我们先使用一个典型的手写bind的例子,代码如下&a…

PHP命令执行的函数

在做面试题的时候发现,自己对PHP命令执行的函数的了解并不是很全面,就想这去学习一下。我也在网上找到了许多的资料,在这里我就相当于一个总结吧。 system(); System()函数的主要功能是在系统权限允许的情况是执行系统命令,windows系统和Lin…

【服务器数据恢复】EMC存储Zfs文件系统下raid5数据恢复案例

服务器存储数据恢复环境: 某公司一台EMC存储,12块硬盘组成raid5,2块热备盘; Zfs文件系统。 服务器存储故障: 硬盘故障导致存储崩溃。 服务器存储数据恢复过程: 1、对故障存储所有硬盘进行物理故障检测&…

详细软件著作权的申请

一,申请注册账号并进行实名认证 在中国版权保护中心官网注册账号。 我是自己申请的所以选择的个人,这里根据实际情况进行选择后注册。 注册后进行实名认证(3-7个工作日人工会进行审核,所以每个著作权人都要提前注册并进行实名认证…

论文投稿指南——中文核心期刊推荐(地球物理学)

【前言】 🚀 想发论文怎么办?手把手教你论文如何投稿!那么,首先要搞懂投稿目标——论文期刊 🎄 在期刊论文的分布中,存在一种普遍现象:即对于某一特定的学科或专业来说,少数期刊所含…

【电商】电商后台---商品上架前的最后准备

电商后台相关模块进行维护后,离商品上架越来越近。 在供应商、合同、商品、价税等都维护完成后,采购部创建采购单,离商品可以上架销售越来越近了。 本篇再接着梳理一下商品销售前的最后准备工作(没考虑促销)&#xff…