B端产品的发展，从解决一个业务的问题（电算化，部门级），到解决企业各环节的问题（信息化，企业级），再到今天企业解决全面数字化和智能化的问题（数字化、智能化，社会级），大致经历了3个阶段。

产业互联网

我国的产业主要分两大类：传统产业（以制造业为主）和新兴产业（以互联网为主）。传统产业的大部分规模已经成熟，但在创新能力、资源配置和成本控制方面存在较大的瓶颈；而以互联网为代表的新兴产业部分已经成熟，但整个市场的总量已经显现天花板。
产业互联网的提出，正是为了实现跨产业数字生态的联动，以互联网的技术提高传统产业的效率，以传统产业的市场带动互联网的发展规模，以便支持国家经济更好地实现转型升级。

产业互联网与消费互联网的区别是什么？
消费互联网下，互联网公司是主导力量，它关注个人消费需求中的差异性特征，最终是为了帮助既有的产品更好地销售和流通；而产业互联网下，传统企业既是主导的一方，又是被服务的那一方，它强调帮助企业更好地从整体上优化业务流程、组织结构，从而提升生产效率。二者的区别，本质上也是做to c 和 to b产品之间的区别。

为什么转型到to b后阵痛不断？
依托力量变了，从前只需要用户有电脑、有智能终端就够了，现在需要有更便宜的传感器、存储、计算……要联合更多更复杂的软件开发商；
主导力量变了，从前是互联网公司全权主导，现在是传统企业来主导，从甲方到乙方的角色切换，谁不痛啊？
关注点不同了，从前是关注个体在日常生活中的消费需求、流量变现，现在强调如何成为企业的数字化助手，帮助企业在生产活动中优化上下游供应链的结构和组织结构。你要了解不同行业客户的业务逻辑，难度更大了……

B端乱象有哪些？
对内，外行指挥内行，流程混乱，部门鸿沟深，合作成本高；对外，前线商务互抢客户，架构师盲吹方案，产品研发供不应求，运维保障无序，客户怨声载道。

企业级产品两个阶段的演进
效能需求阶段：这个阶段的企业级中后台页面设计混乱，业务对于体验的需求显性表现在美化页面设计，提高设计效率和一致性。
体验需求阶段：这个阶段产品开始关注使用过程中的问题，慢慢转向注重于用户需求和体验设计。

康威定律告诉我们，一个公司的IT系统架构是由公司的组织架构决定的。商业模式决定运营模式，运营模式决定组织架构，组织架构影响IT架构。

观点

“设计一个产品，本质上是设计用户在一些特定场景、特定目标下的使用过程，是设计一系列分散的或者聚合的服务。”
这样的思考模式，使我们将静态的思维转换为动态的思维，从一个封闭的设计系统转换为一个连接的、开放的设计系统，从而更好地应对B端产品的复杂性和特殊性，并以全局的、动态的、生态的视角来看待系统的设计过程，而不是一个个传统的静态界面设计。

云服务的技术特点、产品特质是实时的、在线的、互联互通的。
云服务产品的设计强调一个产品体验的全生命周期过程的管理与设计，是用户可感知的服务的各种“触点”。产品是服务的一部分，而产品成功本质上是全链路服务的成功。在面向未来的B端时代，无论产品的技术底座如何变迁，B端产品形态的服务化、连接化趋势是比较清晰和明显的。
在传统的B端产品领域，尤其是软件形态的时代，受限于产品的技术方案、部署方式，以及客户的隐私和要求等，对产品和用户数据的分析开展相对有限，重视程度也不够，并不利于产品的快速迭代和发展。在云服务时代，产品的形态发生了本质变化，在线化已经变成了产品的基本特征。

在产品的设计环节，尤其在产品设计的早期阶段，真正决定产品成败的往往是对业务真正的洞察与理解，对用户群体的准确把握和分析，对市场情况的准确判断，以及对商业模式的精准选择等。
对于一名设计师而言，有两类角色极为关键，一种是上下游合作关系的产品经理（包括需求设计人员、应用架构师等），一类是产品的直接用户（有时候也有相关的间接用户等）。
由于B端产品业务的复杂性，在与产品经理的讨论中，很多时候设计师往往处于下风，一些没有经验的设计师甚至有时候连问题都提不出，只能被动执行。在这一问题上，设计师一方面应该不断地修炼内功，增加业务方面的知识储备；另一方面，设计师也要建立一些用户体验方面的基准，传递给产品经理，甚至研发人员等。
比较公认的是，在B端如果可以称之为优秀的产品经理，必然是这个领域有深刻洞察的业务专家，甚至是业务领袖。具备很好的产品规划和市场洞察能力，会成为设计师非常好的业务老师和工作伙伴。

在“需求的可视化”方面做得不足，在界面维度表达得不够清晰和明确。
一些有着较强设计能力和表达欲望的产品经理，往往概念原型设计得非常细致，有了很多细节交互的考虑，容易在产品需求到设计转化阶段形成思维定式，挤压了设计的思考和验证环节，也不利于整个需求到设计的转化。
用户的定义范畴往往也应该包括相似产品的用户、行业友商产品的用户等。多维度去定义和寻找用户，便能够站在整个行业的立场去理解用户和场景，而绝对不仅仅是站在面向一个或几个企业的狭义的立场。
>> 运维系统和运营系统
>> 客户满意度、净推荐值

竞品分析是捷径
B端产品的竞品资料没有C端产品那样容易获得。
>> 如何快速从0到1做产品一直是大家关注的问题。如果是一个追赶型的产品，尤其切入红海市场的产品，尽早开展竞品分析是启动设计的最优路径之一。竞品分析对产品方向的把握也是百利而无一害的，正所谓知己知彼，百战不殆。
swot与pest的关系，swot内外部因素，pest外部因素。
竞品分析方法在体验设计领域又叫作竞品体验分析，以此来强化全链路、全流程、全业务视角的分析过程。
“从长远角度看，即使没有法律的约束，用户对抄袭的产品也会嗤之以鼻，这样的产品也不会有真正的生命力。”
产品设计与业务设计的区分：从产品设计的维度来讲，可以分析产品的基础信息架构、功能节点的分类、菜单、样式、布局、交互形态、视觉风格等。而从业务设计的维度来讲，可以关注业务场景的划分和分析、用户群体的细分、业务流程的设计和优化等。
用户体验需求建模：为了更准确地理解与描述业务需求，我们会将各种需求文档进行场景化、具象化的设计与描述，再结合相匹配的产品概念原型模块，形成一个个生动的故事，整个过程内部称之为用户体验需求建模。

场景化所表达的理念即是以用户为中心的产品设计思想，强调产品能够准确地匹配用户真实的业务场景和使用场景，匹配组织中不同分工的业务角色。
>> 提炼成一些重要的公共场景，把这些场景用图和文字进行说明。
（1）高频业务（2）公共模块（3）主流程（4）特定角色（5）细分场景
>> 在B端产品设计中，要面临的一个大的挑战，就是业务的多样性以及非标准化。所以，现在比较流行的赋能型的业务中台等概念，在一定程度上也是为了应对这些个性化的场景需求和特点。
>> 业务化不明显的公共模块场景，又非常重要和高频
>> 主流程场景实际上就代表了最为核心的业务场景及相关的组合。
主流程场景强调的是业务闭环的严谨性、流程性和完整性，也是为了降低场景化描述过程中对于需求表达丢失和不完善的风险。
很多大型企业和组织在选型一款产品时，相关的采购负责人及相应的业务负责人，一定会关注这块产品向决策层提供了什么样的服务与能力。

代入感，参与感
1.基于现场研究，从下而上
2.基于顶层设计的抽象场景，从上而下
>> 在梳理和提炼场景时，把一个功能模块直接映射为一个场景是常见的误区。这种方式简单地用功能介绍代替对整个场景细致的、具象化的描述，缺乏对真实用户的使用情况的具象化表达和分析，最后失去场景真正的价值。

场景呈现与分析方法：人物角色、用户情境、故事、用户体验地图
>> 用户体验中常用的一些方法，如人物角色、用户情境、故事、用户体验地图等组合起来使用，都是一些高效的场景分析和呈现手段。
>> 场景的呈现并不在于形式的表达，而在于可视化的清晰程度，需要真正反映用户在具体场景使用产品和服务的情况
>> 用户情境则需要围绕用户的一个具体目标任务进行细化描述，包含用户具体、细分的目标和可能的实现计划和路径。
>> “一个场景=若干人物角色+若干用户情境+用户体验地图+……”

场景驱动的设计过程
>> 在整个原型阶段中，核心的两个阶段被划分为可抛弃原型阶段和可交付原型阶段。
>> 在概念设计阶段，不应过度投入资源在高保真原型上，这不仅浪费和过度消耗研发、设计资源，并且容易使原型过早、过急地进入稳定期，固化设计者的思维，不利于早期产品需的求验证和调整。
>> 用原型加产品功能描述相结合的方式
>> 需求可视化不代表需求的简化，更不是对需求细节的缺失。无论需求属于哪种呈现形态，其完备性和准确性都不应被打折。
把原型揉碎了说，合理化科学化原型绘制工作。
>> 垂直原型和水平原型

产品的信息架构
>> 如何进行梳理和设计，把复杂的、混乱的原始需求转化为清晰的、结构化的、面向用户视角的信息架构，是产品经理、体验设计师等人的核心工作，也是产品成功的基石。
>> 即使有需求未被满足，也可以通过二次开发或者生态连接的方式进行补充，形成完整的、匹配需求的解决方案。
>> 从混乱到有序、从发散到收敛，并逐步结构化
>> 在信息架构的设计过程中，可以获得基于用户调研等相对完整的成果和结论。
（1）客户目标：客户要解决什么问题，有什么业务需求。
（2）用户：用户到底是谁，直接用户和间接用户都有哪些，用户角色有哪些。
（3）核心业务场景：基于客户的业务特点、行业特点等提炼出核心的、细分的业务场景。
（4）产品目标：产品要负责解决客户什么问题，为了解决这些问题，要具备哪些功能等。
>> 设计一个新产品的信息架构，两种方法也经常混合使用，自上而下用来设计和确认一些核心架构，自下而上用来补充和完善细节等。既有战略层自上而下的考虑，也有基础层自下而上的考虑。
>> “时间”是任何实时系统都存在的维度。
>> 在信息架构的梳理和设计中，有很多的软件工具和分类方法，都可以提升设计效率和设计质量。比如卡片分类方法、自动化分类工具、思维导图工具等。
>> 引入用户进行信息架构的优化、调整是一次难得与用户碰撞的过程，是用户参与设计的一个重要阶段，也可以同步验证产品需求阶段的一些分析结论
信息架构的设计载体：（1）导航系统（2）布局（3）搜索（4）数据组织与管理
>> 如果把系统提供的所有信息、功能都抽象定义为“数据”的话，对信息架构进行设计转化，本质上是解决用户与“数据”的交互问题。而用户与数据的交互目的多为探索数据和寻找数据，而与之对应的产品设计，一般采用“导航”“搜索”“组织（文件/数据）”等方法和功能来对应。不同类型的“数据”，数据的规模、时间跨度、功能都不同。用户习惯等使多种维度的交互形态可以并存使用，并根据不同场景提供更为合理的处理方式。
>> 导航菜单就是信息架构最直接的一个体现与映射，在一定程度上它就是狭义逻辑中的信息架构设计，也是面向用户最为显性的信息架构。
>> 本质上，导航的设计可以有效地帮助用户处理高度结构化的、非海量的信息与数据。
>> 核心页面整体功能区域划分、操作区域划分等，是系统页面布局的核心要素。这一部分可以认为是一种隐性的信息架构，它向用户传递产品的功能、内在设计逻辑等
>> 布局不像导航设计那样，以映射的方式向用户传递产品基础、核心的信息架构，而是以一种类似“心理暗示”的方式来逐步影响用户。用户在逐步使用产品的过程中，潜移默化地形成产品的不同区域用来完成不同的细分工作的认知。
>> 在产品设计过程中，应该针对核心的业务场景，形成一些规范性的布局约束，定义几种核心的布局样式。
>> Windows操作系统上的文件管理器，它以标准的、结构化的方式给用户提供了一种组织文件的工具。
>> 配置之苦

个性化的需求来源
C端客户的个性化需求很多，但B端客户中存在着更多的个性化的内在需求。其分别来自客户化、角色化和用户化三方面的需求。
>> 针对客户化的需求，产品需要具有以下能力。
（1）业务流程和审批流程可配置（2）组织和机构可配置、可调整（3）界面显示可配置、可调整（4）产品界面的换肤功能，可根据企业视觉识别系统（VI，Visual Identity）快速调整
>> 角色化的产品，需要具备以下能力：
（1）产品功能模块可根据具体角色的需求特征重新组织（2）具体界面信息可根据角色的关注角度来调整顺序及展示方式
（这些角色和自己在企业中的岗位、职责有关，并且因为企业信息化的特点也会产生一些新的角色。每个角色因为工作内容不同、工作特征不同、工作场景不同，因此产生了个性化的需求。）
>> 产品需要具备的面向用户个性化的能力如下。
（1）根据用户作业历史，总结出用户常用数据（2）根据用户的使用习惯，记录个人喜欢的交互方式（3）界面显示的个性化设置能力，如按钮、字段显示的顺序，文字、控件显示的大小等。
（每个用户都有着自己独特的业务视角。）

标准产品与个性化的平衡
产品和项目最大的不同是通用性。
>> “标品+个性化”的策略：基本确定产品的形态、功能，以及用户的使用方式，只在实际使用时，对产品做小部分的个性化调整。
>> 客户没有最常用的业务场景，没法构建一种标准的产品形态。当面对这种情况，可以给客户或者用户提供几种模式去选择。
>> 因为客户业务的多样性，有时还会遇到无法确定标准产品的情况。当深入大型企业的实际业务设计产品时，这种情况表现得尤为突出。面对此种情况，经常需设计出一些半成品，甚至工具。在客户化实施的过程中，将这些半成品组装成符合客户业务的成品。
做不了标品，做不了组装方案，我们还可以做能力、工具、半成品。
『严格意义上讲，ERP产品都是半成品』这个观点牛逼

经典的B端设计模式
>> 大量的业务都是以“单据+流程”的方式进行处理的。
单据是对企业经营过程中某项业务的具体记录，其中包括业务发生的时间、地点、参与各方及交易明细等，可作为后续业务追溯、会计核算等需要的原始资料。
>> 单据界面一般都包含表头信息和表体明细信息。表头信息主要记录该业务发生的基本信息、背景信息以及相关信息，表体明细信息主要记录该业务的具体情况。
>> 浏览态、新增态、编辑态
>> 自由态/开立态：创建后但未被提交，严格上说此状态下不是有效单据
>> 将审批功能设计成通用组件

流程：业务流程，审批流程，操作流程
参照
业务报表
打印：打印模板，云打印
角色工作台

帮助体系：提示，操作指引，客服，帮助中心
操作引导是指在某特定场景下，系统对用户接下来的操作进行的指引。根据用户使用场景的不同，常见的有：新手引导、新上线功能引导、对某功能点的操作引导等。新手引导和新上线功能通常通过“观光（Tour）”的形式呈现，帮助用户在短时间能快速了解产品常用功能或新上线功能的位置。对某功能点的操作引导可以通过很多形式实现，比如简单的短语提示、图文提示等。对于稍复杂的操作，还可以使用GIF动画的方式进行提示。
比较完善的帮助中心一般会涵盖用户手册、视频教程、常见问题、版本更新、搜索、培训、社区、用户反馈等相关内容，在用户能够接触达的每一个触点进行相应设计并提供相应的帮助，从而辅助用户学习、交流、解决问题。帮助中心主要面向两类用户角色和场景：一是使用产品的用户，在遇到某特定业务问题时，可以通过帮助文档提供的内容自行解决；二是需要全面理解产品的用户（比如售前人员或培训人员），为他们提供一个可以全面学习产品的渠道。
在B端因业务与功能的复杂性，完善的帮助体系是不可或缺的存在，好的帮助应该具备以下几点要求。（1）有效的功能工作集（2）上线文档帮助与辅助界面（3）传统的在线帮助（4）智能化的帮助（5）本地化和全球化（6）无障碍性

产品品牌的力量
>> 常见的产品品牌与公司品牌的组合如下。
（1）公司标识即是产品标识，不涉及众多产品线。
（2）公司标识衍生出产品线标识或者独立标识，与主品牌有一定相关性。
（3）公司下面相对独立的事业部与产品线的标识，与公司标识和品牌相对独立。
产品的调性与风格不仅仅与产品本身的定位有关系，也和公司品牌、竞品品牌、市场策略等情况相关。
>> 有的主推企业品牌，弱化产品品牌；有的则强化产品品牌，弱化公司品牌；有的则齐头并进。
>> 客户一直以来更熟知的是其正在使用用友、SAP等提供的服务与产品。只有少数IT人员，更清楚这是一个什么产品、版本如何、架构如何等。

产品的设计规范
>> 好的设计规范有助于提高产品的一致性、减少错误出现的可能性、提高开发和实施效率、减少用户学习成本、方便后期追溯检验等。同时，也能统一向用户、客户传递一致的印象，形成一定的品牌价值。
>> 产品一致性应该包含如下几点。（1）布局一致性：保持某一种类似的结构，因为新的结构变化会让用户思考，而排列规则的顺序能减轻用户思考与记忆的负担。（2）色彩一致性：产品所使用的主要色调应该是统一的，用来传递一致的品牌印象与风格，而功能性色彩也能形成固定的规则，方便记忆与识别。（3）操作一致性：降低用户的学习成本。（4）反馈一致性：系统对同一种功能和同类信息传递的呈现方式一致，使得用户与系统的沟通更加顺畅。（5）文字一致性：产品中呈现的文字大小、颜色、布局、语言风格等都应该是一致的。（6）声音一致性：产品中各种操作过程的声音，正向的如确定等提示声，负向的如警告等提示声。
>> 规范与评估体系在相对稳定的基础上，不应过分僵化和固化，应该不断扩充与完善，以满足未来产品发展的需要。
>> 简约（1）企业级产品是一个效率工具，应该容易被用户“发现、开始、使用、退出”其所提供的服务；应该贴合用户的认知维度与流程；应该接受用户质疑任何可能冗余的流程与功能。（2）简单而不失优雅，遵循简约的美学设计原则；谨慎地使用色彩，由复杂的线框构成；具有实用主义优先的视觉表达。