To B 产品交互的经验分享——以某云计算平台为例

原标题:To B 产品交互的经验分享——以某云计算平台为例

编辑导读:在To C 行业一片飘红的情况下,To B 行业无疑是近几年的“香馍馍”,市场潜力大,不少巨头都投身于此。本文作者作为一个在To B 行业摸爬滚打四年的产品人,对To B 产品交互有着自己的看法。本文以某云计算平台为例,对其交互体验进行分析,希望对你有帮助。

编辑导读:在To C 行业一片飘红的情况下,To B 行业无疑是近几年的“香馍馍”,市场潜力大,不少巨头都投身于此。本文作者作为一个在To B 行业摸爬滚打四年的产品人,对To B 产品交互有着自己的看法。本文以某云计算平台为例,对其交互体验进行分析,希望对你有帮助。

之前做ToB产品已经快4年了,现在已经从事ToG类产品了,本文总结了个人在ToB产品交互设计中的一些感想与经验,希望可以对初入ToB产品的交互设计师有一定的帮助。

之前实习的时候做过一些ToC的产品交互设计,后来转入到做ToB的产品交互设计一直到现在,从ToC到ToB,其实还是有一些很大的区别,其中最大的区别就是对业务以及业务逻辑的理解和交互设计两方面。下面将具体的说明这两方面的区别:业务及业务逻辑理解、交互设计。

一、业务及业务逻辑理解 1.1 业务理解

对于交互设计师来说,ToB产品对业务理解能力的要求要高于ToC产品,之所以会这样是因为两方面的原因:To B 产品的专业性、个人教育与职业背景。

我们都知道ToC产品的目标用户是大众用户,而ToC产品的需求也当然来源于真实的生活,这样一来我们理解ToC的业务自然就像是看我们生活的回放一样。如化妆、订餐、乘车等都是我们日常生活的一部分,在这些场景下诞生的APP就算不用过多的解释,我们也能大致了解是干嘛用的,甚至还能出现一些具体场景。而ToB产品的目标用户往往是一群具有特殊职业的用户,往往还需要经过特殊学习和培训才能任职,如程序员、警察、医生等,我们除了大致了解这些用户是做什么的之外,对于他们具体的工作却生疏的狠。

To B 产品需求比 To C 产品需求较难想象具体场景

另外对于交互设计师本身来说,大部分是从工业设计、心理学、计算机等学科出生,并非一个无所不知的人。对于 To C 产品来说我们可能也是其中的一个目标用户,但是对于 To B 产品来说,我们可能就是一个小白用户,所以对于一个不熟悉甚至还需要一定的学习才能理解的产品需求,在进行交互设计之前,需要花上一定的时间对目标用户和具体业务进行了解和分析。

1.2 业务逻辑

在业务逻辑上,To B 产品比 To C 产品业务逻辑相对较为复杂多,主要体现在 To B 产品内模块之间的依赖性、任务流程的复杂性以及权限分控三个方面。

To B 产品内模块之间的依赖性相对 To C 产品较强。对于 To B 产品来说,完成一个任务往往依赖几个模块配合使用才可正常运行,比如一个用户使用云计算产品进行网站建设,其至少需要通过云服务器、弹性公网 IP、域名系统、备案系统四个模块再加上一些配置才能成功搭建一个网站,缺少一块就无法顺利完成网站搭建。而 To C 产品间的依赖相对比较独立,在进行任务的操作时不会彼此依赖,就拿微信来说通讯、朋友圈、支付相关操作都可以单独完成,甚至可以独立成3个产品。

购买云服务器的流程比微信聊天功能的流程长且操作复杂

相对 To C 产品来说,权限分控功能是 To B 产品所独有的重要功能。To B 产品往往是一个团队协作的平台,而对于团队来说,每个人的职责和权力是不一样的,这样就得让产品根据不同用户身份角色与权限对用户的操作进行限制。那某云计算产品来说,团队里的一部分人负责云服务器,一部分人负责数据库,一部分人负责创建实例订单,一部分人负责支付订单等,各自负责自己的职责。

某云计算团队不同用户的不同权限

相对 To C 产品来说,权限分控功能是 To B 产品所独有的重要功能。To B 产品往往是一个团队协作的平台,而对于团队来说,每个人的职责和权力是不一样的,这样就得让产品根据不同用户身份角色与权限对用户的操作进行限制。如某云计算产品来说,团队里的一部分人负责云服务器,一部分人负责数据库,一部分人负责创建实例订单,一部分人负责支付订单等,各自负责自己的职责,每个职位有每个职位的权利和责任。

二、交互设计

了解了 To B 产品的业务理解和业务逻辑方面与 To C 产品的区别后,我们大致对 To B 产品有一定的了解,那在具体的设计方面是否和 To C 产品一样呢?还是有着较大的区别?下面将具体的阐述个人对 To B 产品在交互设计上的理解和感悟。

首先不管是ToB还是ToC,在设计宗旨方面两者应该是具有一致性的,都是针对目标用户在具体场景下的需求分析,以用户需求导向为中心来提高用户体验的设计,正所谓凡是脱离用户和场景的交互设计师分析出的一定是个伪需求。但是由于两者目标用户和使用场景存在较大的差异性,导致在具体的设计过程中拥有较大的区别,具体将从3个方面来表达 To B 产品的差异性:需求分析、设计思维。

2.1 需求分析

需求分析主要分为用户需求分析和业务需求分析。

用户需求简单的理解就是目标用户在某一场景下完成特定行为从而达到具体的用户体验目标,如在某云平台创建云服务器实例需求,就可以理解为熟悉云计算的程序员通过某云平台点击创建按钮等操作来快速、顺利的完成创建表单的过程。所以目标用户和使用场景对于用户需求来说是核心,由于ToB产品目标用户相比ToC产品目标用户业务性强且用户基数少,通常运用在ToC产品用户需求研究的问卷法等定量分析的方法就不适用于ToB产品,对于ToB产品更适用于用户访谈和观察法等定性的研究方法。通过对用户访谈数据和观察用户使用产品场景的分析,构建出目标用户的用户角色更直观方便的帮助理解业务需求。

业务需求也可以简单的理解为通过什么完成任务来达到什么业务目标,如某一云服务器推广活动的业务需求,简单理解就是让更多用户创建云服务器来提高云服务器的销售额。业务需求分析的重点就是如何将业务目标转化为用户行为,这又回到对目标用户在使用产品动机、担忧以及障碍的分析。所以在需求分析方面,不管是用户需求分析还是业务需求分析方面,都需要对目标用户和使用场景进行深入的分析,避免出现“我以为”“我认为”的设计。

2.2 设计思维

由于ToB产品和ToC产品存在的业务逻辑、目标用户以及体验目的的差异性,导致ToB产品在具体交互设计时拥有不一样的设计思维,具体体现在以下四个方面。

2.2.1 先整体后局部

由于ToB产品的业务模块间依赖较大,往往一个功能会涉及到很多地方,这就得要求设计师在进行交互设计时,首先考虑当前需求在整个平台内涉及的模块和功能,避免出现功能遗漏。把改需求影响的页面及功能全部都考虑到后,再考虑当前需求在具体模块内或功能上的形态和具体交互,以适配不同模块或功能的差异性。如某云计算平台创建报警联系组需求,在报警联系组模块使用页面的形式完成报警联系组的创建,由报警组名称、备注和选择联系人三项组成。而在创建报警页面,由于该需求属于报警规则创建的一项,其呈现方式也为普通的表单项且省略创建联系组的非必填项备注信息。

创建报警联系组需求

2.2.2 逻辑严谨

由于B端产品的业务复杂性,在进行交互逻辑的设计时应该更加严谨,尽可能的考虑全所有操作的可能性与限制,页面与具体功能对于不同角色用户的呈现方式等,避免出现因考虑不周上线后出现各种Bug的情况,尤其是ToB产品涉及到计费相关模块比较多,就更加谨慎。如某个模块的创建实例按钮不可点击的状态出现的原因就有好几种,没有配额、欠费、没有实名认证、没有权限等,当这些条件同时存在时又应该优先显示什么提示。

创建按钮的不同状态

2.2.3 效率至上

效率至上也是B端产品与C端产品的一个较大区别,C端产品在满足用户需求后侧重于满足用户情感方面,如怎样提高用户粘度、怎样在使用时提高用户的情感体验等方面。B端产品在满足用户需求后更侧重于提高用户的工作效率方面,如怎样更快的完成当前的任务、在页面信息较多情况下如何让用户理解每一个信息等。所以在进行B端产品设计时,遵循效率至上的设计才能提高用户的满意度。如进行表单填写在某个输入框输入关键字就能显示一些模糊匹配项进行参考,当Hover到某个语义模糊的图标按钮时,会显示对应的介绍等都是为了提高用户的工作效率。

2.2.4 简约通俗

由于ToB产品目标用户具有特定的工作场景和专业知识,所以在进行设计时所用的语言和一些使用习惯应该尽可能的与目标用户的真实环境保持一致。这样用户在使用产品时会减少对产品的学习成本,提高用户的使用体验和工作效率。如某云计算平台在进行某策略编辑时,将其编辑输入框设计的与用户实际工作运用的工具相似,让用户更加熟悉、便捷的进行策略编辑。

三、总结

以上内容就是我对 To B 产品交互设计经验的分享,其实之所以ToB产品与ToC产品会有这么多的差异,归根结底是由它们的产品目的决定的,C端产品主要解决用户实际生活中的需求痛点,

B端产品主要满足实际用户的工作需要。所以只要在设计的一开始能够区分产品的本质需求,即能够很好的做出好的设计。

本文由 @拾叁太宝 原创发布于人人都是产品经理,未经许可,禁止转载

题图来自 Pexels,基于 CC0 协议

免责声明:非本网注明原创的信息,皆为程序自动获取互联网,目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责;如该页面侵犯到您的权益,请给站长发送邮件,并提供相关证明(版权证明、身份证正反面、侵权链接),站长将在收到邮件12小时内删除。