如何全面系统的了解一款B端产品？总监级干货来了！

上一篇 B 端和 AI 分享中，重点提过 B 端设计师要加强对全局的认识，以应对新的行业挑战和机遇。

但问题是，如何加强对全局的认识？第一步肯定是多用 B 端产品，但 B 端不像 C 端我们每天都在使用，往往非常隐蔽难以接触到，对于没有什么项目经验或者准备开始学习的新人来讲非常陌生。

虽然我们过去整理过可以直接注册登录的 B 端 SaaS 平台，但没有目的性的去胡乱看一通是没有什么帮助的。必须要掌握一定的思路和方法，才能从开源的产品身上理解吸收经验，提升我们对 B 端产品的全局认识。

一、B 端产品的研发思路

试用产品除了了解页面设计的样式、功能、交互以外，还要去了解它背后的设计逻辑，更宏观层面的考量。

而要满足这一点，首先就要知道 B 端产品的研发逻辑，才能在自己的使用过程中进行逆推和更深入的思考。

一个常规的 B 端产品研发流程，可以总结为下面这个循环：

第一步也就是最关键的一步，即总结业务需求，那什么叫业务需求？即企业运作实践中所产生的需求，要通过数字化产品来解决。

比如一些很常见的情况：

1. 需要全体员工上下班考勤的统计，作为绩效评定的标准之一
2. 需要记录门店物料的进出状态，用于每月底的财务审核和进货依据
3. 需要一个专用的企业任务管理工具，用于从上到下完成任务的指派和跟踪
4. ……

正常的 B 端项目，是由业务导向的，如果没有业务需要，就没有它存在的价值。而很多新手和初级设计师会一直把 B 端需求归因为“甲方的任性”、“老板的天真”，用虚无主义来消解一切市场行为，这显然是没有意义的。

因为 B 端产品如果不能解决问题，那么投入成本研发它有什么用，资本都是大风刮来的嘛？

不排除有些项目从立项到成果都很糟心，但代表不了所有项目都是这样的，而优先关注 SaaS 类产品也有个好处，就是它们都建立在非常明确的业务场景和目标之上，因为产品做的不好，解决不了客户的业务问题，那就不会有人买单。

有了业务需求，才会制定对应的功能点和产品服务。如果产品包含的功能板块越多，就证明它所要满足的业务点也就越多。

然后，设计师才会在功能要求上制定交互的逻辑以及具体的界面样式，程序员再把它们实现出来，完成后续的上线。

而上线以后不代表产品的研发就结束了，除了还没做完的需求外，上线的产品还要在应用场景中收获用户的反馈，需要结合它们制定后续版本的需求。

所以，一个经历过长时间发展和迭代的产品，变成今天这样是多种条件共同作用的结果，可以根据主次总结成下面这种状态：

第一级：业务需求

第二级：功能需求、用户需求

第三级：设计水平、开发水平

这种结构类似用户体验五要素，但和五要素不同的是，我们的全局分析不能只围绕“体验”展开，因为 B 端是业务驱动不是体验驱动，用户的优先级远远没有业务高。

而体验 B 端产品的时候，就可以根据这个分类去做解读。首先是功能反映了它要满足哪些业务需求，具体应用场景是什么样的。功能点有哪些，以及相关的逻辑。且哪些功能是基于用户需求和体验制定的。

然后再分析细节层面的，基于业务、功能、用户的影响之下，设计的表现水平如何，一些能感知到的技术应用是否能满足现有的要求。

虽然分析顺序是从上而下，但我们体验一个产品必然是先接触到最底层的细节（界面和交互），而这就会让设计师直接陷入细节不能自拔，开始关注按钮、色彩、组件、表单等内容的视觉和体验，再用不同的理论去套用分析。

虽然细节分析对于设计师来讲是必要的，但我们今天的主角是全局的认识，只关注细节的做法是不能帮助我们获得提升的，所以从产生的接触到使用上，我们从一开始就要奔着宏观的层面而去。

就像企业主、真实用户去使用产品，很少会优先关注界面好不好看（或者根本不在意），原因就是他们的关注点不在这里，而在更有价值的地方，这也是我们要培养的能力。

所以想要提升产品全局认识的话，那么使用 B 端产品的路径如下:

别以为这是个复杂繁琐的流程，其实操作起来并不困难，下面我就会基于新手的现状建立一个从简单到复杂的学习增长路线。

二、B 端产品的使用路线

前面说过，对于大多数人来讲，接触的 B 端产品并不多，没有相关行业经验和知识的积累下，就是进入了软件内也是两眼一抹黑啥都用不懂。

比如面向开发、运维的云服务、Devops 类产品：

或者面向物流、进销存的 ERP、SOP 类产品：

虽然这些专业性的 B 端产品离我们很远，但不代表我们日常学习、工作中就完全用不到 B 端产品。想要建立对它们的认识，就要先从和我们生活关联性较大的方向入手。

我的建议是根据难度依次去体验后续三个类型的产品，第一是 TODO 类工具，第二是文档类工具，第三是电商类工具。

前两个在早年都只有纯 B 端应用，随着 Web2.0 的发展，个人用户也对这类产品有非常大的需求，所以它们逐步开放给个人用户，是 B 端 C 化的主要应用场景。而电商类工具，则是因为我们网购经验实在是太丰富了，所以理解成本很低，并且电商类系统的功能覆盖面非常广，可以很好帮助我们延展对 B 端系统的认识。

下面我们分别对每个类型的工具使用进行介绍：

1. Todo 类产品

Todo 类产品就是待办事项管理工具，现在完全面向的 C 端的待办工具不少，比如滴答清单、日事清、Things 等等。但既然我们要上手 B 端产品，就要选择以 B 端为主的工具，比如国产的 Teambition、Worktile、Tower，或者国外的 Terllo、Asana 等等。

这类工具也叫项目管理软件，是在敏捷模式大火以后普及的，最基础的任务管理模式就是使用 “kanban” （这是个日文，英文就那么些，直译也是看板……），将任务拆分成不同阶段，每个阶段下的任务用卡片进行罗列。

先到这些产品的官网看它们介绍，选择个自己看得爽的直接注册登录进去使用，然后用它来做你们的生活待办清单或学习待办清单。

比如我们创建一个项目，把任务拆分成四个状态，考虑中、准备做、进行中、已完成。把你近期工作或学习的任务添加进去，然后结合它来完成你近期的工作事项。

当然，这个分类不是固定的，你们可以自己调整。在使用的过程中你肯定会产生各种问题，从而去产品中找对应的功能或实现方法。

2. 文档类产品

文档类产品就多了，前面写过专门的文档演变过程，C 端产品不胜枚举，而这里我们主要关注一些面向 B 端为主的文档工具，比如石墨、腾讯文档、飞书、语雀等等。

同理还是了解完选择一个自己喜欢的，然后去搭建个应用它的场景。如果还只是自己用，比如创建个人的笔记之类的，就没意思了，不会体验到它们的协作精髓。我会建议你们去创建一些需要多人共同协作的场景，比如和朋友创建训练计划，和同好共同整理资源，和群友共同编写知识库等等。

有了目的，再去使用这些文档工具，你们就要自己去梳理对应的目录，制定文档内的格式，协调编辑的路径，确定改动的逻辑等等。

因为现在的文档工具已经非常复杂，所以他们呢可以提供非常多的功能和操作方式，可以让我们投入非常多的时间去研究它们应该怎么和我们的需求适配起来。

是继 Todo 应用后最适合上手应用的工具类型，也因为它们太复杂，并不建议大家前期用文档工具作为 Todo 工具体验（当然这个也可以自己试试）。

3. 电商类产品

最后一个电商类产品，其实就是电商的店铺管理工具。比如淘宝的千牛、有赞、微店等，就是可以直接开店并管理店铺的工具。

这里我们要做的就是模拟一个开店的过程，去操作这些产品。当然没目的性开店是没有意义的，你可以挑选个你喜欢的店铺或品类，搬运它们现成的素材到自己店铺里，并创建 10-20 个商品。

从开店填写信息，到上架商品编辑内容，是一个非常复杂、繁琐的过程，但中间的大多数步骤你们都能理解为什么要做这些操作。所以过程越繁琐，中间就会有越多能让你觉得困惑或是问题的地方，对于我们深入理解业务和产品的联系有非常大的帮助。
如果条件允许，我也建议你们尽量自己上架自己拍商品走完整个流程（不同平台、品类门槛不同，要自己研究下），再体验下单、发货、提现的不同环节。

在上述的体验过程中，我们构建的应用场景，就是业务的需求，而使用这些产品就是去解决业务需求的过程。产品能不能满足你的需求，如果能是怎么满足的，没满足的话是为什么，缺少什么东西？这些亲身经历是理解 B 端产品的基础，而不是只随便看看页面按按按钮来分析产品的体验。

有了这些经历，就可以从宏观去分析产品面向的业务需求是什么，它们提供了哪些功能和服务，是否可以满足。而这些功能、服务应用了什么样的交互和信息，操作体验好好不好。最后才是视觉这些细节的完成度，还有哪些问题和改进空间。

这种思维在实际项目中也不一定能锻炼到，很多工作了几年的初级 B 端设计师仍然不具备这种能力，所以必须依靠我们自发去训练。

而经验的累计，可以帮助我们在完成新的项目或改版的时候从更宏观的角度看待问题，输出一套界面或者规范不再只是立足于一些“无关痛痒”的设计理论，而是要配合业务、功能尽量去解决 “上层问题”，创造更多的价值。

结尾

上面的操作建议所有已经从事还是想要从事 B 端行业（不管是设计还是产品）的同学去实践，只沉浸在视觉、体验的设计中是永远不可能在国内 B 端领域“进阶”的。

当然，会真的实践的同学必然是少数，所以这部分人会在认知上远远超过另一部分懒于实践的人，在职业发展中上升到他们无法企及的纬度。

想学系统完整的B端课程，看这里 👉 https://pro.uisdc.com

下篇再贱~

欢迎关注作者的微信公众号：「超人的电话亭」