决胜B端

今天要和你分享的是《决胜B端》，关于产品经理的一本书籍

第 5 篇原创读书笔记《决胜B端》

背景

身边走动比较近的两位朋友，已经从程序员转入产品也有一年多了，坐标分别位于上海与北京，薪资待遇25k左右，他们之前也是程序员职位，现如今都已顺利转入产品的行业。

自己因为所在公司也时常有涉及B端与C端产品业务，所以便对朋友的这本《决战B端》产品经理一书产生了兴趣，结合书中与个人工作，我将从以下4点为你分享，同时再文末还将为你分享两位朋友公司产品业务（其中一位是著名上市车企公司，最近车企行情着实不咋地，咱也就不提名了）：

1. 什么是C端、B端产品？
2. 交互设计尼尔森十大可用原则；
3. 数据埋点与数据分析常用用具；
4. B端产品系统以及迭代管理方式；
5. 朋友公司企内部产品架构；

1. 什么是C端、B端产品？

C端产品也叫2C（to Customer）产品，是面向终端用户或消费者的产品，往往承担流量获取和转化的重任。

特点：

1. 用户是个体；
2. 强调交互体验；
3. 数据驱动设计；
4. 收益容易量化；
5. 运营决定存亡；

B端产品也叫2B（to Business）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低陈本、控制风险的重任。

特点：

1. 目标用户是一个群体；
2. 效能第一体验第二；
3. 强调抽象和逻辑；
4. 收益难以量化；

用一张思维导图说明B端产品：

接下以主流互联网公司为例，分享了互联网的盈利模式作，总结如下图所示：

2. 交互设计尼尔森十大可用原则

在说这点之前，我先抛两个疑问，1. 在日常中安装程序时，为什么会有进度条？2. 删除为什么会有二次确认？ 等等，这其实都是交互设计尼尔森十大可用原则之中的，自己时常也画原型图，但都是基于自己对产品的认识，并不知道为什么要这样？直至今日才顿悟。

尼尔森（Jakob Nielsen）是一位人机交互学博士，于1995年1月1日发表了「十大可用性原则」。尼尔森的十大可用性原则是尼尔森博士分析了两百多个可用性问题而提炼出的十项通用型原则。它是产品设计与用户体验设计的重要参考标准，值得深入研究与运用。

1. 反馈原则（Visibility of system status）

系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。比如：

• a. 安装程序时显示进度条，并预估还需要多久结束。
• b. 上传文件时显示进度条，并提示预估剩余时间。
• c. 提交表单时，如果校验失败，则在填写有误的内容旁边提示错误原因。
• d. 程序未响应时，系统会让用户选择是关闭程序还是等待程序响应。

2. 隐喻原则（Match between system and the real world）

系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。

在人机交互设计中，程序的沟通和表达、功能的呈现，都要用最自然的、用户容易理解的方式，避免采用计算机程序语言的表达方式。设计时要采用符合真实世界认知的方式，让用户通过联想、类比等方法轻松地理解程序想表达的含义。

例如，某音乐播放器APP，功能按钮设计如图2所示，即便不做说明，用户也很容易理解每个按钮是做什么用的。

3. 回退原则（User control and freedom）

用户经常会不小心操作错误，需要有一个简单的功能，让程序迅速恢复到错误发生之前的状态。

用户误操作的概率极高。对于误操作，软件系统应该尽量提供“撤销”“重做”或“反悔”的功能，让系统迅速返回错误发生之前的状态。

当然，不是所有操作都是可以“反悔”的，比如，你可以撤销一笔错误的订单，但不能撤销一笔成功的转账交易。以下是遵循回退原则的常见设计案例。

• 编辑类软件都提供撤销功能，例如Word、美图秀秀等；
• 点击删除或关闭按钮后，会让用户进行二次确认。
• 电商平台允许在一定的规则下取消订单。

4. 一致原则（Consistency and standards）

同样的情景、环境下，用户进行相同的操作，结果应该一致；系统或平台的风格、体验也应该保持一致。

软件设计、产品设计中有很多约定俗成的规范，虽然没有明文规定，但大家都在遵守，因为用户已经习惯了这些规范。我们在进行设计时，应该遵循惯例，并且保持系统的一致感，不要盲目地标新立异。

例如，在APP底部的导航图标中，“首页”永远排在第一个，个人中心（“我的”）永远排在最后。并且对于类似“首页”“购物车”“订单”等常见按钮，不同APP的设计样式都非常相似。

例如，Office软件中包含的各个产品，其界面布局和设计风格就保持了高度一致，如图4所示是Word（上）和Power Point（下）的界面，可以看出，二者的“插入”一级菜单下所包含功能的排列顺序、布局方式乃至图标图形，都是高度类似的（例如：Word和Power Point的设计风格很统一）

5. 防错原则（Error prevention）

系统要避免错误发生，这好过出错后再给提示。

进行设计时，首先要考虑如何避免错误发生，其次再考虑如何检查、校验异常。这样做一方面可以让问题更简单，另一方面可以让用户避免或减少无谓操作。

例如，有些时候，为了防止用户重复提交或重复点击，第一次点击按钮后就将按钮置灰，直到处理完成才恢复。有时还会通过调整按钮顺序，避免用户误点。比如，对于很重要的操作，为了防止用户顺手误点，会将二次确认对话框中的“是”和“否”两个按钮对调位置，模拟效果如图6所示。

因为常见的对话框都将“是”按钮放在第一个位置，所以用户在操作时，很容易产生条件反射，顺手点击第一个按钮，然后才突然发现自己点错了。

虽然看起来有些别扭，但是很有效，因为多点一次要好过误删文件。这种设计在软件卸载、APP取消会员订阅等操作中也非常常见，只不过后两种情况下主要是为了做一些心理暗示和引导，避免用户卸载或退订。

6. 记忆原则（Recognition rather than recall）

让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。

计算机应该减轻人们的记忆负担，而不是相反。例如，当切换页面时，不应该让用户记住不同页面的内容，而应该在合适的地方积极地呈现或提示之前的信息。例如，几乎所有的APP和PC端的搜索引擎都会记录用户的搜索历史并呈现给用户。

图7是美团APP的搜索页，可以看到上面的“搜索发现”是推荐类功能，下面的“最近搜索”则是保留的用户最近使用过的搜索关键词。

7. 灵活易用原则（Flexibility and efficiency of use）

系统的用户中，中级用户往往最多，初级和高级用户相对较少。系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。

灵活易用原则不仅是一个交互设计原则，也代表了一种软件产品设计理念：系统既要做得简单、易用，让所有中级用户用起来得心应手；也要提供必要的帮助，让刚入门的初级用户顺利上手；还需要支持灵活的个性化定制，让高级用户能够以进阶的方式使用系统，充分发挥其价值。

例如图7所示是Word的自定义功能，提供了非常强大的配置能力，用户可以对Word的UI实现颠覆性的重新设置。

8. 简约设计原则（Aesthetic and minimalist design）

对话中不应该包含无关的或没必要的信息；增加或强化一些信息就意味着弱化另一些信息。

重点太多，相当于没有重点。在视觉设计中，要掌握好“突出标记”的度，以及内容的呈现方式。例如，图9所示是一份停机通知示例，左图只突出了停机这件事和停机时间，右图突出标记了更多内容，但是用户反而无法一下子抓住真正的重点。

9. 容错原则（Help users recognize, diagnose, and recover fromerrors）

错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码；提示错误信息时要给出解决建议。

对于很多运行时错误或异常，计算机程序都会返回某个错误代码，但是对于用户来讲，看到这些错误代码并不明白发生了什么，所以一定要将错误代码转换成用户能看懂的语句，并告诉用户解决的建议。

访问网站时，如果页面不存在，服务器提供的标准错误提示是404错误（如图10左图所示），很多用户并不理解404是什么意思。图10右图所示的页面就对此做了处理，将错误提示转换成用户能理解的表述，而且给出了解决建议。

10. 帮助原则（Help and documentation）

对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。

现在的软件产品，尤其是C端产品普遍做了良好的交互设计，可以帮助用户快速学习使用，而不用阅读、理解复杂的说明文档。然而，B端产品的复杂性比C端产品高很多，因为B端产品蕴含很多业务流程的规则，系统中的一个按钮可能代表了一个复杂的业务处理规则，如果不了解整个业务场景和处理规则，是很难理解按钮的操作含义的。

因此，对于B端产品，用户进行自助服务、自助操作的难度高很多，B端产品的帮助文档依然有存在的必要。产品设计人员要尽量在前端交互上做好引导提示，对于复杂的规则和逻辑，可以考虑通过帮助文档来指导用户。

3. 数据埋点与数据分析常用用具

目前国内使用比较多的WEB端埋点工具有 Google Analytics(GA)、百度统计、移动端埋点工具有GrowingIO、诸葛IO、神策。

目前我司主要使用的分析工具有，WEB 端是 GA、百度统计、客户端是友盟，最近有接入了微软的 Clarity，

1. 一张经典的GA分析报表图：

1. 桑吉图（Saankey Diagram）也叫能量分流图，用于观察流量的流转情况。

1. Cohort 分析图

Cohort 分析（中文是群组分析、队列分析等，没有统一译法）一种经典的留存分析方法。

1. 访客分析

客观分析全面的用户行为数据，用户在线上的每个动作、行为，都可以被准确地捕获、记录。GA 可以准确记录每一个访客的所有行为，如下图，借助Clarity 甚至还可以提供录屏功能，以下是我司业务回放片段。

1. Heat Map 热力图

热力图（Heat Map）是一种通过标记页面不同区域的颜色深浅，来呈现网页不同区域点击热度的图表，可以方便地观察页面中不同功能的点击使用情况。

我们使用的是 Clarity ，据说国内分析工具-易分析也支持（暂未使用，不做说明）

4. B端产品系统以及迭代管理方式

再做项目管理时，你是否也有为版本发布定在什么时间而烦恼过，分享书中一个典型“双周迭代模式”。

双周迭代模式，即两周完成一个迭代周期，其中，一个迭代周期是指从软件开发到上线的时间，迭代过程如下：

1. 挑选需求并编写PRD（W1D1~W2D4）
2. 评审（W2D5）
3. 技术方案设计（W2D5~W3D1）
4. 开发实施与测试（W3D2~W4D4）
5. 上线（W4D5）

随着软件的迭代升级只做产品功能需求，而不做技术优化日积月累，系统会变的越来越脆弱，运行速度会越来越慢，甚至宕机，那么如何平衡业务需求和技术优化之间的资源分配问题呢？结合业务发展周期，作者建议如下：

5. 朋友公司产品架构

1. 真实案例一：上海知名o2o品牌特卖企业–壹品仓，

盈利模式：

• 1. 自营模式，买入商品（服装、鞋帽等）再次挂牌销售，利用买卖差价。
• 2. 品牌入住，招商品牌入住，从销售单中赚取佣金提成。

2. 真实案例二：上市车企公司

朋友与我分享了近2小时，自己也才听懂了个整体大概流程（如上图所示），越是庞大的企业分工越是明细，朋友自己也是众多业务系统中仅主负责OMS，每个业务系统至少1~2名专职产品经理负责，奈何了解有限，大伙凑合着看。

个人观点

书中涉猎的知识点是比较广泛的，比如：从互联网的业务模式讲到如何转型B端，再从B端业务调研->B端产品方案设计->技术方案->管理与实施->迭代优化->数据分析，最后以传统企业的应用架构演变的故事作结局，对入门级产品经理有启发意义，但是个人认为不够深入，就比方说个人最感兴趣的章节–埋点与数据分析，仅仅如上文所说介绍了工具与图例。如果对本书感兴趣，可通过如下方式获得该电子书。

以上便是我与你分享的全部内容了，我们下期见。

电子书获取方式：

资源来源互联网，如有侵权请联系删除，如果可以请支持正版。

评论