高手来了！10个B端设计的常见问题答案

本文总结了10个常见的B端设计问题，帮你对B端设计的认识更进一层。

1. 如何具体地理解设计体系和设计规范这两个概念呢？

“设计规范”更专注于内容上的规则准绳，帮助设计师产出一致的设计方案，传递统一的品牌特性。

但实际上，就算团队中有了一套统一的标准工具和设计指南，部分设计师依然会有新的不一致的“创意”，而前端对应的组件代码也需要在不同业务中根据设计“创意”而人肉修改。

此外随着业务迭代，设计师们会更多地面临“周期性业务的品牌更新”，“不同品牌的多种垂直业务同期构建”，“众多相似的后台系统构建”，“跨业务/部门的设计、前端协作问题”。

面对这些问题，体验工程的建设已经远远不止于一套设计规范或一套组件库，他需要一套完整的系统来支撑，解决内部协作的一致性问题，解决设计系统更新的周期性问题，解决一群设计师与工程师如何规模化的生产各种业务 UI 的问题，从而最终解决用户体验一致性的问题。这便需要建设一套“设计体系”。

总结一下二者的区别就是：「设计规范」专注于内容，是公司/业务的设计约束准绳，提供了一套标准来实现体验一致性，传递品牌理念。在目标上更侧重于“品牌统一”，内容属性强于工具属性。「设计体系」是一个完整的产品，它不仅包含“原则、规范、指南”这些内容，还包含着一系列的协同工具，帮助规模化生产，减少设计和开发的重复工作量。在目标上更侧重于“协同提效”，工具属性强于内容属性。

2. 产品经理和交互设计师最大的工作内容区别在于？

产品经理

通常更关注产品战略、产品竞争力、需求洞察和分析、公司商业回报等问题所以他的视角必然是从外到内，市场上有什么变化，竞争对手有什么品牌，目标用户有什么需求，我们做这事为什么不能赚钱……

为了达到这个目的，他必然要更多地和老板打交道，要和上下游的合作伙伴谈判，要争取内外部的资源 支持，要写 PRD 和 MRD，要考虑发布会……

你可以理解一个产品的产品负责人，通常就是这个产品的“CEO”。

产品是需要顶层设计思维：

否则为啥还需要产品经理（以下简称 PM）？哪怕 PM 只负责一个很小的模块。如果只是因为头衔的通货膨胀，那为啥没有代码经理。经理这个 title，说明这个岗位是需要有大局观的。如果说一个公司对 PM 的定位就是画一个原型出来，那这个公司基本肯定就是外包公司。

在这里，谈一下个人对 PM 的理解。PM 是一个从无到有，从 0 到 1 的创造性岗位。没有人知道一个产品有哪些功能，长成什么样才是最好的，没有标准答案。那难道我们就无法评价一个产品经理工作的好坏了吗？当然不是。这里就要提到一个心中 PM 的核心技能，商业化。商业化能力对 To B 产品经理是尤其重要的，甚至是最核心的技能，同时也是可以某种程度上评判一个 PM 工作好坏的直观参考。当我们在考虑是否要做一个产品或者新加一个功能的时候，PM 首要职责是要思考这个产品或者功能

1. 可以解决客户多大的问题，价值在哪里。
2. 竞品有没有，他们为什么做了，或者为什么没做。
3. 技术实现的路径是什么，能做到什么程度。

对这三个问题的思考，合格的 PM 对于一个产品的商业化变现能力有了初步判断。最怕是客户要什么就做什么，二怕竞品有什么我们就抄什么，这两种都极不可取。这三个问题思考不到位，很可能后面的努力都变成徒劳。而往往大多数产品的失败，核心原因也不是产品交互多差，界面多土，而是在一开始就走错了路。顶层设计就是在我们深入思考后，对于产品的规划，目标的客户，推广的节奏等给出具体的方案。

而商业化能力，不仅仅适用 PM，越是产品的负责人（无论是否是 PM）越应该锤炼自己的商业化能力。

交互设计师

更关注人机交互关系、场景、角色、用户画像、交互范式各种专业性问题，所以他的视角经常是从高到低，用户用我们产品有什么问题，怎么确定哪些问题是重要的，可用性是否出现问题，易用性怎么提升，硬件和软件能力怎么更好地服务于用户……

这样的思考方式促使交互设计师更多地关注产品本身技术平台、各种竞品的差距、用户感受、交互条件的限制与优化，所以输出竞品分析报告、场景分析、任务流程图、交互模块逻辑关系图、用户研究、纸面原型、高保真原型 demo……

你可以理解一个产品的交互设计师是这个产品在 UX 框架层面的专家，他决定你的业务逻辑怎么解释为用户逻辑，而不是技术逻辑。现在 B 端都没有纯视觉 UI，都是和交互合并成产品体验设计师。上接用户、产品和业务，下接开发和测试。有人说交互设计师是“设计 PM”，还挺贴切的~

3. 组件搭建之后，产品经理直接拿组件去拼页面，直接进入开发

那么设计的价值在哪？另外公司不重视设计和组件，我们应该怎么办？

第一：关于搭建组件之后，产品直接拖拽使用，设计怎么办，价值在哪？

个人认为其实非常好，证明你的搭建工作发挥了价值，提高了整个产研部门的效率。你在这个过程中可以逐渐从不必要、重复性设计事务中解放出来，有时间去关注整体的产品交互，以及产品流程的合理性，以及如何从产品层面去优化整体产品体验等等。才能体现 tob 产品设计师的价值，才不会被别人称作是拖拽组件的“工具人”。

第二：目前公司不重视设计和组件化怎么办呢？

这个我建议把眼光放的长远一些，我们和公司只是合作关系，我们的个人成长不管是从技能上还是从认知上，收益最大的永远是个人。没有几个人会一直待在一个公司，但是随着你的能力的提升，你会遇到更好的公司，也会有更多选择，梦想总是要有的。

4. B 端组件的搭建在具体的作品集中的占比应该多少？会加分么？

首先作为 B 端设计拥有组件化思维和组件化构建能力是必须的。但是具体是否需要在作品集展示，展示多少，能加多少分，需要去结合自身的阶段去看。比如你是一个初级设计师，那么你至少会设计使用组件，知道组件的原理，以完成日常的设计工作；如果是中级设计或者是高级设计则需要减少组件设计的部分。尤其是如果你申请的是一个管理岗位，我们固然不需要用很大的篇幅去讨论怎么做组件，而是要把重点放到把控设计任务的质量和时间等等。

5. 组件搭建的范围是？什么内容需要做成组件，选择的依据是？

组件搭建范围：

页面底层的框架，原子层的栅格、间距、字体、颜色、阴影等的具体定义、使用范围、为什么要这么定义。底层框架的原理决定着页面的秩序和前端实现的成本。依次向上到基础组件、业务组件、区块组件，最终基于组件多嵌套组合成场景页；

组件化内容的选择依据：

对于 B 端的产品来说，在结构细分时，项目中满足复用性和拓展性的可拆解的模块均可以组件化；把页面穷举罗列出来，分析相似性和可替换的模块，然后利用思维导图的方式罗列出可组件化的内容，做成可替换的组件，使每个原子可独立变化和替换，这种多嵌套组合式的细分方式，让组件最终呈现出来的样式满足多场景的业务需求。

6. 什么时候是做组件库的时机？

在 B 端产品中，做组件库的时机要需要产品发展到较为稳定的版本，这个阶段公司把整体把系统性提升产品体验和服务的竞争优势提上了日程；毕竟 B 端的组件库需要结合业务设计出符合业务场景的样式‍，真正可以组件化的逻辑和样式是不可以凭空想象的，需要积累足够的了解业务逻辑，足够的业务场景。

总结

1. 产品发展到较为稳定的版本
2. 设计师足够的了解业务逻辑
3. 积累足够的业务场景
4. 产品线多、项目多、设计师多、工程师多；
5. 公司所处阶段重视产品体验、品牌化、差异性；

7. 想问一下你了解的 B 端企业工作流程是什么样的？各个流程设计师需要完成哪些内容？

B 端企业工作流程：

我所了解到的企业工作流，是当客户有意向的时候，对应的客户经理（产品经理）会针对具体的需求输出原始的用户需求文档书，并给出简单的原型设计先和客户确认，确定立项之后，会拉着各个业务线的 leader 一起对原型评审。到这个时候最重要的就是设计部门的意见，因为一旦原型被拍板通过，后续如果在出现产品功能需求上的问题会把锅扣在设计头上。所以一般在这个阶段我们都会比较谨慎，所有问题基本都会暴露出来。当然我理解把问题前置是一个好的事情。设计完成高保真之后，在开发之前还会进行高保真 Review，参与的人员和评审原型时一致。如果高保真评审通过就会进入到开发测试阶段，上线之前设计部门会进行还原度验收，形成设计验收报告，并告知客户经理和开发经理，最终上线效果会根据具体的项目要求和时间来定；

8. toB 和 toG 的区别除了目标定位外，你认为具体还有哪些区别？

一般政府以及官方机构被称为 G 端，严格来说 G 端属于 B 端的一种。所以 B 端的共性就是为了提高企业运行效率。那么我会重点说一下我接触到的一些明显区别。

G 端包括实体的智能硬件以及软件服务或者解决方案

智能硬件又包括智慧园区中的无人汽车，X 厂的智能装货机器人，以及很多实际应用的智能硬件。其实目前很多 G 端的企业在发硬件发展上是很快的，我在没真实参观之前也没有想到，一个 X 厂居然可以完全不用人，就可以实现全自动化生产。这里面当然包括很多软件硬件的解决方案共同协同。

还有一点就是 G 端更着重强调预警：

不管是我们日常看到的街道违规抓拍，以及工厂里面设备故障，等等其实主要功能侧更侧重于强调预警。在违章或者故障发生之后第一时间通知对应的人去处理。随着科技慢慢的发展，人工智能 AI 的介入，以及各种算法和大量数据的采集，以后的预警可能真的会在故障或者事故发生之前，就做出预警的动作，从而避免真正警情的发生。

9. 现在组件都这么成熟了，为什么还要自己花这么大成本去搭建呢？

其实这是跟你的公司的战略方向、发展阶段相关的。对于一个中小型企业或者他可能就觉得用现有的开源组件，已经是够用并且好用，我为什么还要去自己做呢？没毛病，这种情况下还是以目的导向的，你想节约成本，就去用别人就成熟的这种规范去搭就 ok 了，没问题的。

但是有另外的情况就是：一：开源的组件库、场景库（pro）基础，无法满足企业内特殊复杂的业务场景；二：公司发展到一定程度了，想要品牌化、差异性化；自然会自上而下的去要求和推动产品体验升级和组件化的进程；

10. B 端设计师如何快速理解业务？

查阅行业报告

如果是之前从未接触的新业务，我们可以通过市面上的行业报告，来对该行业有个大体的认知，因为在行业报告中，会提到行业的发展状态，政策导向以及未来的发展趋势。

理解产品专有名词

专业业词汇对于 B 端设计师理解上是有难度的，在实际工作沟通当中都需要通过专业词汇来进行准确的描述。比如在 OCR 产品当中,我们必须要了解：分类器、K-V、自定义模版/模型、参照字段等一些专有名词词汇，而词汇的背后往往是产品当中的深层逻辑。理解专有名词的含义然后逐步再去理解流程和业务逻辑；我们可以选择直接竞对通过竞品的官网、产品试用等，我们可以寻找到"用户手册、帮助中心”等模块，也可以去看自家产品沉淀的产品说明书，里面就会有相应的专业词汇的讲解；从而加深对产品的理解；

竞品体验试用

试用往往是在真实的环境下对该产品进行体验，试用可能是销售人员给到你相应的体验测试账号，或者你可以直接注册。设计师应该根据竞品的官网或销售人员演示的流程或产品文档进行相应的页面梳理,通过截图将该产品的主流程进行截图。最终将页面流程静态的还原到设计图上，一是遇到同类型需求时,能够快速了解竞品的功能设计思路；二是帮助我们在产品的后续更新迭代，有了可以参考的版本。如果无法拿到直接竞品的体验账号，我们也可以去体验相关联竞品；

产品体验走查，理清流程和结构

对照产品白皮书体验自身产品，体验过程中列出主功能流程图以及对比分析流程和内容合理性，将问题和疑惑记录下来和产品经理进行沟通，深刻理解业务，对症下药才能提供出切实可行且合理的设计方案；

欢迎关注作者微信公众号：「IM UED」