行业对设计师的要求⼀直都在不断革新，只有「⼀技之⻓」的设计师已经很难满⾜⾏业需要，产品分析已经不仅仅是产品经理的工作内容，对于 UI 设计师来说，也是必备技能之一了，尤其是对于 B 端领域的设计师来说，更需要拓宽视野，思维前置。

那么，该如何去做产品分析呢？本文将从产品分析是什么，如何做两个方面来讲述，为大家提供思路，做真正落地的对设计有帮助的产品分析，提高自己理解业务、处理业务、解决问题的能力，体现出设计师的价值。

1.1 产品分析定义

1.11 B端产品是什么

对于 B 端产品来说，它只有一个目标，就是解决问题，通过对问题的分析得出解决方案，而任何一个问题都不会只有一种解决方案，在权衡利弊后得出了最终的解决方案，产品就是解决方案的表现形式和实际载体。

1.12 产品分析是什么

从设计师的角度来说，产品分析通常是挖掘产品缺陷，优化产品体验，为产品迭代提供依据，比如：通过深度体验产品，挖掘产品的在功能、交互体验方面的不足，并通过分析制定产品优化方案。一款产品从浅至深拥有无数的可被挖掘的信息，这些信息本身是庞杂冗余无意义的，只有通过分类和清洗才能得到对人有意义的信息，本质上来说，产品分析就是在做信息分类和清洗的工作。

1.2 产品分析与市场分析、竞品分析

1.21 市场分析

市场分析是对产品所在的市场进行宏观的竞争态势和市场规模的分析。市场分析主要包括行业背景、市场现状和商业模式三部分。可以看到，市场分析其实是从很宏观的一个角度来切入，更偏向于战略层内容，因此市场分析也是三者中距离设计师最远的一个概念。用通俗的话来说，市场分析最主要的目的就是分析产品是否赚钱。

1.22 竞品分析

广泛意义上说，竞品分析就是根据分析目的，找到切入角度，对竞争对手或市场进行客观分析，找到竞品或自己的优势与不足，为下一步决策提供科学依据，其实就是「知己知彼」的过程。对于设计师而言，竞品分析的目的更倾向于寻找解决方案，比如：通过竞品分析来寻找参考从而解决自己当前遇到的问题。

1.3 产品分析对设计师的意义

• 1. 设计：帮助设计师理解产品的历史和现状，避免设计时天马行空无法落地
• 2. 业务：帮助设计师快速理解业务和融入新团队
• 3. 沟通：可以帮助设计师同产品经理更好地进行对话，降低沟通成本

1.4 难点——业务难以理解

不同于 C 端，B 端往往有很坚固的行业壁垒，所涉及业务也非常难以理解，究其原因，来自以下两个方面：

• 1. 业务逻辑复杂
• 2. 远离日常生活

1.41 业务逻辑复杂

B 端产品很多时候，都是在原有线下业务的基础上进行数字化。逻辑的复杂度本质上是来源于这个行业多年来积累的足够成熟的业务流程与规范，而这些东西没有办法速成，只能靠不断地积累来增进理解。

1.42 远离日常生活

C 端产品的设计中，设计师大部分情况下都或多或少地就是用户本身，或者带有用户属性，比较容易产生同理心，去发现问题解决痛点。

而 B 端产品不是给普通用户使用的，是给特定群体使用的，这种特质就决定了设计师很难去真正地理解用户的处境，设计师最厉害的特质——同理心也很难派上用场。

1.5 误区

有的设计师同学，一接到产品分析的任务，到手就是先去网上看看别人是怎么做的，然后按着人家的结构对自己的产品进行一通分析，其中不乏用到了「用户体验五要素」、「SWOT分析」等看起来高大上的方法论。

按这样做，产出的分析报告不能说错，但是最起码是不恰当的，对设计上的帮助微乎其微。其中有这样两个问题：

• 1. 与产品经理边界混淆
• 2. 注重方法论，流于表面

1.51 与产品经理边界混淆

产品经理是产品的第一负责人，需要对产品的整个生命周期负责，说人话就是产品经理负责产品做什么不做什么，该什么时候做，而设计师关注的是产品的用户体验。产品是商业的代言人，而设计师是用户的代言人，二者本质上的不同，就决定了在做产品分析时关注点必然不同。如果按着产品经理的思路来做产品分析，得出大环境之类的太过于泛化的结论对设计没有什么实质性的帮助。

1.52 注重方法论，流于表面

用户体验五要素，swot，等等这些高大上的方法论看起来非常有用，从多个维度把一款产品分析得非常清楚。可真实的情况时，往往新手设计师同学既不懂方法论的本质，也不懂使用场景，只是盲目地套用，导致产出的是一篇「八股文」一般的产品分析报告，过于全面但没有重点，什么都是点到为止，对自己理解业务和辅助设计没有实质性的帮助。

我认为，「方法论」本质上是经验主义，使用过去解决问题的方式来解决新的问题。在一定程度上，方法论是有用的，一些简单的问题，确实是有固定解法的，而且，解决问题也更快。但是在更难更特殊的场景下，方法论不再管用了。很多时候，问题表面上看起来一样，可是由于问题的背景不同，所以解法也是不一样的，这时候再采用方法论，就会产生思维固化，强行去套方法流程，得到的一定不是最正确的答案。

在确定了目标和分析重点之后，我们就可以开始进行分析产出产品分析报告了，在这里我整理了几个撰写时的原则供大家参考：

• 1. 避免主观
• 2. 思考要全
• 3. 自上而下

2.1 避免主观——不要把自己当成使用者

第一点是我们要避免去主观臆断功能的合理性。正如我上面提到的一样，我们并非 B 端产品的核心用户，有些我们感觉反常的地方，但是其实有它的合理性，因为 B 端用户的痛点往往是在特定的工作场景下产生的。因此，在不了解真正用户和场景的情况下，仅凭经验下的结论往往是错误的。

我之前的一个项目的设计中，在给图表配色时，我最初的一个版本是用的近似色去完成的，在发给产品经理初审时被打回来了，理由是这种配色不够明显。我追问原因后才知道，我们的一部分用户是年龄比较大的用户，对比度足够高才能方便他们看清楚。最后出的一个版本是对比度非常高的配色，尽管从设计的角度来看这种配色美观度不足，但是能够让用户看得清楚。

在这个例子中，用户对于美观度并没有很高的要求，反而对于数据的识别度要求更高。我们常听的一句话是「己所不欲，勿施于人」，然而在B端的设计中，我们更要做到「己所欲，亦勿施于人」。

2.2 思考要全——使用者和决策者都要考虑

B 端产品有一个很重要的特点，购买决策者与使用者的割裂。我们在思考一个功能时，不能仅仅考虑使用者的体验，也要考虑决策者的想法。

比如钉钉的「已读未读」这个功能，相信大家对这个功能是槽点满满。但是在 B 端产品中，决策链上游是购买决策者即老板，因此就有了这个功能。如果只考虑到用户体验，这个设计从一开始就不该出现。但是，与 C 端产品的流量思维不同，B 端产品不是靠体验来吸引用户存活的，而是靠满足决策者的需要来活下去的。很多大家感觉不好用或者体验很差劲的 B 端产品，仍然活得很好，就是这个道理。

说句题外话，钉钉已经注意到了这个细节，在去年的一个演讲上，钉钉总裁也提到了对这个功能点的考虑，他举了一个场景，在不改变现有设计的情况下解决了这个问题，通过智能手表等外设来预览消息，而手机和电脑依然显示未读，自己考虑好了的时候再去回复。

2.3 自上而下——从宏观到微观

从战略层到功能架构，再到每个功能细节，采用金字塔原理去遍历，避免遗漏的同时层层深入。

在此处，我介绍一下我认为一份合格的产品分析报告应该包含的部分，各位设计师同学可以根据自己的需要进行适当调整。

3.1 文档说明

3.11 版本说明

因为产品分析是有一定的时效性的，且是针对某一个具体版本去进行分析的，所以在文档开头要列出自己所分析产品的版本，例如（飞书 V5.6.9，钉钉 6.3.35）。

3.12 分析时间

即设计师进行产品分析的时间，留档以供以后查看。

3.2 产品概述

此处要回答的问题是，产品是用来干嘛的，给谁设计的以及怎么赚钱的。

3.21 产品定位

即产品是用来干嘛的，不需要特别具体，只需要在大方面上对产品进行概括即可。举个栗子，抖音定位是一款短视频消费型产品，以“内容”的新鲜有趣为主，强调分享和信息获取，满足幸福快乐的美好时刻需要。

3.22 目标用户

即产品是给谁设计的，在此处需要对客户和用户做区分。客户一般是指企业的 CEO/管理者，他们来决定是否要斥「巨资」购买一款软件。比如说某公司的 CEO 最终决定买钉钉还是飞书作为办公协同软件。而用户一般是企业内的员工，他们使用软件来完成一些日常工作。分析目标用户的意义是，在之后的分析中，我们都要以用户为落脚点，去分析功能的合理性。

需要注意的是，此处并不需要去做一套完整的用户画像，只需要大概描述一下是产品的客户和用户的职位和核心需求即可。

举个栗子，对于某客服工作台产品，

• 用户：客服，主要职责是接受用户咨询，帮助顾客解答疑惑。
• 客户：公司 CEO，目标是对业务情况进行把控，提高客服效率。

3.23 商业模式

即产品如何赚钱，在这里，我们并不需要用各种很高端的工具——比如商业模式画布，去分析商业模式，我们仅需要知道产品的赚钱方式即可。作为设计师，我们不需要有产品经理那么专业的商业思维，但是我们也一定要能够从商业角度理解产品的价值，一款产品最健康的状态一定是用户价值与商业价值并存。因为本质上而言，用户体验也是商业价值的一部分。

对于B端产品而言，有两种最常见的售卖方式：

• 1. 本地部署模式
• 2. SaaS 模式

1. 本地部署 —— 按软件数量售卖

本地部署是指产品的应用、数据都存储在一台计算机中，这台计算机不与其他任何服务器、计算机相连。21世纪之前的传统 IT 公司大部分都属于这类，比如 Adobe 旗下的产品（尽管他们也在做云，但是更多情况下我们还是把 PS 当做本地产品来使用），那时候 B 端企业的商业模式是：主要服务于大企业客户，通过与顶级的合作伙伴合作，推出顶级的产品，提供一整套软硬件解决方案，并进行深度服务，一次性收取高昂的软硬件费用，并且每年加收不少服务费。

2. SaaS —— 订阅制

21 世纪后，随着云计算技术的发展，越来越多的产品开始部署在云上，也就逐渐发展成了现在的 SaaS 产品，从这个角度来讲，我们通常所说的 SaaS 产品其实就是将本地部署变为云端部署的产品服务。

这时候 B 端企业的主要商业模式是：不仅服务于大型企业，也服务于中小企业。以订阅制的方式，定期收取费用，并且提供不同的版本，进行差异化定价，实现收益最大化。

举个例子，蓝湖就是提供了四个版本并且以季付或年付的方式进行收费。

3.3 功能架构

3.31 什么是功能

将需求转化为对应的软件层面可实现的能力，即功能，功能可以实现需求所期望达成的目标。

3.32 什么是功能架构

一个完整的 B 端产品包含若干功能，将一套功能依据业务进行分类整合，形成的抽象化业务模型即功能架构。

3.33 功能架构与信息架构

功能架构指的是产品是如何由这些功能组成的。我们在分析功能架构时实际上更偏向于产品的实现模型。

信息架构是包括组织系统、标签系统、导航系统、搜索系统在内的综合系统。我们在分析信息架构时，分析的是这个产品是如何将不同的功能组合在一起展现在用户面前的，分析的是产品的呈现模型。

3.34 为什么要分析功能架构

一个成熟的 B 端产品甚至会有甚至会有三四百个功能，我们在分析功能细节前，必须要先厘清架构，以一种抽象的框架视角来全局思考，而不是也仅仅以用户的视角来看产品的表象。

3.35 如何分析功能架构

收集

真正地去使用产品，并将产品的所有功能与模块收集到一起。

整理

以模块作为分类依据，将所有功能分到不同的模块里，必要的话，可以继续细分子模块。

在这里要注意，一个功能是否属于某一个模块，不能以这个功能是否在某个页面为依据。一个页面出现了某个功能，只是因为这个场景下用户需要这个功能，而不是这个功能属于这个页面。

以飞书后台为例，很多人在分析时会把首页也作为功能架构图中的一个节点去分析，这是错误的。

首页只是功能的聚合，而非功能模块，例如「添加成员」这一功能应该属于「组织架构」模块中，如果将首页也加入分析，势必会出现功能的重复。

3.4 功能分析

在分析完整个功能架构之后，我们可以深入到每个功能的细节了。其中包括以下两点：

• 1. 功能使用流程
• 2. 功能背后的需求

3.41 功能使用流程

通过绘制功能的使用流程，我们可以模拟用户在使用产品时的流程，发现一些从宏观角度上忽略的点。在绘制时，要注意的是，要控制在页面 & 操作维度，避免拔高到功能维度甚至业务维度。

3.42 背后的需求

我们除了要知道这个功能该怎么用之外，还要知道功能与业务的关系 —— 功能背后的需求。

3.43 需求分析

在分析背后的需求时，除了知道这一需求是什么，如果可以多走一步，对需求进行分类，那对于我们了解产品时大有裨益的。

3.44 马斯洛模型的局限性

关于需求的分级，在 C 端中常用的模型是马斯洛需求模型，但是这一理论并不适用于 B 端，主要是由于以下原因：

• 1. 马斯洛需求研究的是人，而 B 端产品面向的是企业和组织
• 2. B 端系统一般复杂度较高，除了业务目标之外，还要考虑软件架构、体系构建等问题。

3.45 B 端产品的需求划分

一般而言，我们可以将需求划分为功能性需求与非功能性需求。非功能性需求，指的是隐藏在功能需求背后以及开发需要考虑的的需求，也叫作“跨功能需求”。最常见的非功能性需求就是产品的响应时间，一般非功能性需求是由开发和测试同学考虑的。

而对于功能性需求，有三大类：业务需求、功能需求、产品需求。而这三类需求也有比较立体的层次关系：

业务需求，提出者是业务范围、业务模式和业务规则的制定者，一般是指业务方的高层人物，比如 CEO、高级经理等。产品设计是服务于业务定位的，进而使得产品战略遵循于企业的发展战略，只有这样产品方向才不至于发生偏差，因此，他们提出的需求一般不能违反，换句话说，他们提出的需求是整个系统设计的最高纲领。

用户需求，提出者是基层管理者和执行者。他们关心的是如何使用产品完成自己的工作，提出的需求相对细节，例如对操作、流程上的诉求。

产品需求，由于 B 端产品的复杂性，在建设时需要考虑到功能复用问题，以及与其他系统的架构交互问题。举个例子，语雀 App 是阿里旗下的产品，在开发登录界面时，没有重新开发，而是集成了阿里云的 SDK。产品需求本身对业务实现没有价值，它的价值体现在节省人力和优化软件架构上。

三者虽然并没有绝对意义上的优先级顺序，但是一般而言，B 端产品时优先考虑业务需求，其次关注用户体验，满足用户需求，最后才是考虑产品需求。了解了这一点，我们对功能背后的需求进行分类后，就可以从更高的视角来分析功能的设计逻辑，而不仅仅是停留在好不好看的层次上对功能进行分析。

3.5 交互设计

3.51 交互设计是什么

在《交互设计原理》中是指：对于交互式数字产品、环境、系统和服务的设计，定义人造物的行为方式，即人工制品在特定场景下的反应。

在《交互设计精髓4》定义为：设计交互式数字产品、环境、系统和服务的设计，聚焦于如何设计行为。

而在《超越人机交互》中则是指：设计交互式产品来支持人们在日常工作生活中交流和交互的方式，创造用户体验以增强人们工作、生活以及通信的方式，聚焦在实践上，即怎样设计用户体验。

交互设计即行为设计，关注于如何设计系统如何帮助用户更高效愉快地达成目标。

3.52 怎么分析交互设计

仅仅知道是什么远远不够，我们更要知道如何去分析一个产品的交互设计好坏。在这里，我提供两个思路供大家参考：

• 1. 从行为维度拆分
• 2. 十大可用性原则

从行为维度拆分

上文提到，交互设计的对象是行为，而这里的「行为」可以拆分为 3 个部分：导航，输入和展示。

导航系统：即用户在哪里和去哪里

设计要点：

• 1. 导航不能是一个页面上可以链接到其他所有页面，而是要有的放矢，选择用户关心的，更想要去的页面添加导航。
• 2. 导航要显示出来导航本身与所包含内容的关系
• 3. 导航要显示所包含内容与当前页面的关系

例如：掘金的顶部导航，既体现出来了导航本身与包含内容的关系（导航的标签是当前内容的概括），又体现出来了内容与当前页面的关系（当前页面是首页下的一个子页面）。

输入系统：即用户向系统提供信息

这里的输入不仅仅指我们日常中的输入，而是一个广义的概念，将所有用户向系统提供信息的方式统称为输入。输入可以通过多种方式完成，包括输入命令、按下按钮、快捷键、甚至打手势、语音等方式。

设计要点：

• 1. 高效，例如绝大多数的产品都提供了快捷键提高用户的操作效率。

• 2. 准确，例如 sketch 里方向键的作用是移动 1 像素，使用户在使用鼠标快速移动的基础上，也可以准确操作。
• 3. 防错，例如大部分的产品都会在危险操作前二次确认。

• 4. 符合预期，例如在「幕布」中，在画布区和在滚动条区都向下拖动鼠标，操作结果是相反的，但却符合用户的预期。
• 5. 适当隐喻，隐喻是指提供熟悉的实体，是人们能够容易地理解底层概念模型并知道在界面上做什么。例如我们所熟悉的购物车就是现实世界中购物车的隐喻，帮助用户快速理解软件的使用逻辑。

展示系统：即系统向用户提供信息

设计要点：

• 1. 突出重点。用户的浏览动作不是读，不是看，而是扫。设计中应该突出重点，弱化和剔除无关信息。
• 2. 保持一致性。样式规范一致性给用户带来品牌信赖感的同时，还能够通过一致的重复降低用户反复学习成本。
• 3. 及时反馈。系统应该让用户知道目前的状态, 并及时给予相对应的反馈。

十大可用性原则

尼尔森十大原则由毕业于哥本哈根的人机交互学博士 Jakob Nielsen 发表，他提出十大可用性原则，用来评价用户体验的好坏，我们也可以以此为依据来分析一个产品的交互设计好坏。具体的内容网上有很多资料，笔者就不再赘述。

3.6 视觉设计

3.61 概念

视觉设计即 UI 设计，负责产品的图形、图标、色彩、视觉风格等，从视觉层面把控产品界面设计，决定营造出什么样的视觉体验。

3.62 分析内容

视觉设计的分析内容可以拆分为形、色、字、构、质、动。在分析时，如果是网页端，可以借助浏览器的开发者模式或者谷歌浏览器的插件「VisBug」来详细查看各个维度属性细节。

形

图标的圆角，卡片的圆角，icon 的风格与统一度（包括：视觉大小，线段粗细，端点类型、拐点类型等）

例如，同样是头像卡片，QQ采用了圆形来体现灵动轻盈的风格，而主打熟人社交的微信则采用了小圆角。

色

色彩分析包括用色规范、色彩搭配、层级等。在 B 端产品中，色彩在使用时更多的是基于信息传递、操作引导和交互反馈等目的。

字

字体的属性有字号、行高、字体、字重等。通过合适字号和字重可以对界面元素划分视觉层级，帮助用户识别。而在一些特殊的场景下，可以运用特殊字体来提高识别度和增加页面美观度。

例如：支付宝使用了常用的 Din pro 作为其数字字体，其他 APP 厂商也分别使用了特殊的数字字体。

构

此处的构是指页面结构，分为层级和间距两大部分。合适的层级和间距可以帮助用户理解页面，并给予界面呼吸感和通透感。

质

质感与风格、界面风格，投影数值，扁平还是拟物。

比如说相比普通的单层阴影， Ant Design 采用了三层阴影的表达方式，让阴影更柔和，更符合真实状态。具体可查看 https://ant.design/docs/spec/shadow-cn

动

最近几年，越来越多的公司和团队已经意识到动效在产品用户体验中的重要性，动效设计已经成为产品设计语言的重要构成之一。

动效设计并不只是为了修饰，使用动效不仅可以更清晰地体现内容元素之间的逻辑和层级关系，还可以提供当前的状态反馈，加强用户对操作行为的感知，给用户以可控的感觉。

除了上述内容之外，我们在分析一个产品时还可以做以下两件事：

4.1 用户体验自查

4.11 为什么要做体验自查？

在被问到「你觉得这款产品的用户体验好吗？」时，我想大部分设计师同学即使做完了产品分析，也很难回答这个问题。那么，我们该如何做才可以较为准确地回答这一问题呢？

基于这个问题，我们从用户体验的定义出发，ISO 对用户体验的定义有着如下解释：

用户体验，即用户在使用一个产品或系统之前、使用期间和使用之后的全部感受，包括情感、信仰、喜好、认知印象、生理和心理反应、行为和成就等各个方面。

从定义可以看出，用户体验不仅是主观的，而且范畴非常广，所以在描述时，我们不能仅仅用好/不好来概括。要解决这个问题，要点在于建立一个清晰合适的标准来量化用户体验，体验自查就是在做这样一件事 —— 度量体验。

通过做体验自查，可以达成以下效果：

• 1. 将用户体验量化，探索设计破局点
• 2. 帮助设计师更全面地审视产品设计
• 3. 将产品体验上的问题可视化，更直观地展示体验问题

4.12 工具 —— 设计走查表

本质上，设计走查表通常是设计师在完成设计稿后，用于快速遍历方案、修正遗漏或不周的工具。在产品分析中，我们使用这个工具也可以达成体验自查的目标。通常，我们是需要根据产品建立一套适合自己的交互设计自查表的。如果暂时没有，也可以暂时使用网上成熟的自查表来进行。

4.13 步骤

收集

字段说明

问题位置：

即体验问题发生的位置。

类别：

不同自查表对问题的分类不同，例如用户体验五要素、可用性原则等。

重要程度：

如果采用正向思考，很容易陷入“都很重要”的困境，所以这里一般采用反向分析法，也就是如果不解决这个体验问题，会造成多大的影响。我这里将重要程度分成了三个等级，分别是：

• 1. 基本没有影响，有替代功能
• 2. 不解决也可以用，但不太好用
• 3. 不解决基本/完全不能用

发生频率：

同样是三个等级，需要注意的是，这里不是以时间频率来定义的，而是以「每经历 n 次业务节点就会出现这一问题」的方式来定义的，如果不好量化，也可以使用每次，经常，偶尔这样的词来代替。

严重程度：

严重程度 = 重要程度 * 发生频率

这里要注意的是，我们作为设计师，提出严重程度的判断仅仅是作为优先级参考，但是真正的优先级和排期还是需要产品经理来做。

问题描述：

即对体验问题的详细描述。

整理

首先，对问题进行重新审查和校验，去掉非体验问题、重复问题、补充不完整的问题描述等，然后整理到一起，这就是整个产品存在的大大小小、各种各样的问题了。

然后，我们通过图表对数据进行二次加工，一般采用雷达图或柱状图。

示例 - 雷达图的使用方式

严格意义上说，这并不是标准的雷达图，只是使用了雷达图的图表背景。

外圈：上述表格中的「分类」

数值：上述表格中的「重要程度」

为每个模块/流程各制作一张表，然后将每个问题都以点的形式置于图中，哪个分类问题最多，哪个模块/流程问题最多？哪些问题较为严重亟待解决？一目了然。

4.2 专业名词库

设计的本质是为了更好的解决问题，了解业务是解决问题的基础，也是沟通顺畅的利器。但是想要成为一个业务专家，没有长时间的沉淀上是不太可能的，但是公司一般不会给很长的时间去学习业务，那我们该如何在短期内快速掌握业务知识呢？

在理解业务时遇到的最大挑战就是那些晦涩难懂的特殊名词，如 json 文件，API 等开发中特定的术语。

针对这个问题，在产品分析的过程中，我们可以同步建立一个专业名词库，来记录这些特殊名词，并将这些概念用自己的语言进行描述。这样，在了解产品的同时也对业务有了一定程度的了解。

对设计师而言，相比 C 端的各种炫酷效果，B 端设计很难做的出彩，设计的价值更多是隐形的价值，基本不存在会有人因为你把一个按钮做得好看夸你。从这个角度来说，确实成就感比较低。

但是，通过自己的设计让帮助用户更有效率地完成工作，这何尝不会带来满满的成就感？B 端产品一般是用户不得不使用的产品，作为设计师的我们更应该对自己所设计的产品有着敬畏之心。

最后，给大家分享我很喜欢的一段话，与大家共勉。

本次的分享到这里就结束了，希望可以对大家有帮助。由于文章字数较多，笔者几经修改，仍不免有疏漏错误之处，如发现错误，请读者于评论区或私信指出，不胜感激。

在快节奏的洪流中，保持设计的初心，做有灵魂的设计，我们下篇再见~

参考文献：

[1] B端设计面临挑战

[2] 设计研究院｜探究B端产品的体验设计方法——角色全景图

[3] B端产品建设中需求的三个层次

[4] 产品认知的U型曲线：带你学会产品分析

[5] 设计师必看！手把手代练竞品分析

[6]《不枯燥的 B 端设计课》

[7]《如何阅读一本书》

[8]《交互设计沉思录》