b端产品设计与开发「什么是b端产品」

大家好，b端产品设计与开发「什么是b端产品」很多人还不知道，现在让我们一起来看看吧！

作为一名B端产品经理，你知道如何做好B端产品设计吗？或者换个问法，什么样的设计，才称得上是好的B端产品设计？也许，你可以抓准“结构”，在结构层进行更完善的产品搭建。本篇文章里，作者就“结构”在B端产品设计中的关系发表了他的看法，一起来看看吧。

之前写过一篇文章《到底什么是B端产品的用户体验？》，用提问的方式道出了我个人对B端产品用户需求层次的理解。

用户体验是肉眼可见的一面，在B端产品里，还有看不到的一面——系统结构，它直接决定了产品重构的生命周期，直接决定这个系统设计的好与坏。

为何要如此夸夸其谈？

乔布斯小时候，他爸爸做一个橱柜，背面也用好木头。乔布斯十分不解：“背面又看不见，为什么还这么重视？”爸爸说：“看不见的地方与能看见的地方一样重要。”后来，乔布斯做苹果电脑时，要求里面的线路必须整齐。工程师把看不见的地方做得精致，已经超脱了产品本身，而是艺术之品，是对另一种追求。

同样，软件产品背面的木板也理应炮制有方，理之有序。即使我们作为凡夫俗子无法理解高境界的艺术境界去追求极致，至少也该对系统系统的重构周期尽可能长做出结构优美的设计。

一、什么是结构？

字典释义：由组成整体的各部分的搭配和安排。

如果您有阅读我的历史文章《系统是什么？》会知道，结构实则就是系统三大件（系统目标、组成部分、关系）中的关系，它随处可见：天体之间是万有引力，自然界是物质和能量交换，经济领域是价值交换，建筑领域是力学，系统领域则是逻辑等等。

二、结构为什么对B端产品如此重要？

图1 结构示意

1. 结构对系统形成稳定支撑

建筑结构基于力学的精密应用，承载摩天大楼历经风雨不塌；系统结构基于逻辑学的精密应用，承担B端产品的经久迭代可用。

这似乎也是架构师的核心使命：通过对复杂环境的信息收集，对信息进行分类归总，并赋予它们最优逻辑联系，最终建立秩序，从而支撑产品即使应对复杂外部环境的变化，也能支持持续的优化和升级。图1，左右两侧都构建出了支撑结构。

2. 结构是一种化繁为简

熵增定律：要让一切的无序变得有序，必须做功，如我们身体需要摄入能量支持新陈代谢做功，来保持有序（健康）状态。

系统设计一样，起初是一堆无序信息，经由智力做功，对其分类、归总、建模，终而形成简单且易于理解的结构，做功能效越高，结构越抽象越简单，且蕴含的势能也越大。

图1中，通过三条与边垂直的相交，且保持120°的直线形成内部结构，完全可以支撑“承重”，优美、简单、清晰；右侧的“承重结构”，但纷繁复杂，难以理解，明显是没有智力做功，或做功效率低下的结果（我们的系统何尝不是慢慢从左侧变成右侧）。

3. 结构有助于统一上下文

清晰简单，易于理解，会便于交流与思想同步。团队的配合的最高境界是“默契”。而结构何尝不能达到这个境界？给定一个输入，通过结构的逻辑链路就可以通过结构大致推断出一个输出，何须反复澄清？

4. 结构有助于查找问题

结构清晰，意味着构件的职责分工清楚，构件之间的逻辑关系明确。系统一旦暴露问题，通过表象就可直达问题根源，容易定位。

三、怎样才算是好的结构？

从图1中，结构的好与坏一目了然。

左侧，三条长度相等，相交120°，形成完整的“承重结构”，实用而美观。我们作为系统“设计师”，也多少要有一点艺术的极致追求，赋予系统结构些许的赏心悦目。

1. 清晰的系统目标

做系统一定不是为了做而做，而是有意义驱动，这个意义构成了系统目标，或者说是此系统的第一性原理。反过来说：如果目标不清晰或有所偏离，从根上就不正确，基于此构建的系统也必定是无效的，更无优美可言。

有时会存在目标尚不晰的情况下边干边看，来争取时间的场景。这时，需要依靠敏捷迭代来逐步保证目标的正确性（关于系统目标这部分，建议延伸阅读历史文章《“第一性原理”在B端产品设计中的运用》有更深入的讲解）。

2. 构件职责单一

“单一职责”原则，您应该多少有听过。无论是大到经济领域的专业分工，小到系统构件的单一职责，都是在讲避免“眉毛胡子一把抓”导致哪方面都做不好的情形。一个构件一个职责，十个构件便是十个职责，通过数个构件职责的相互关系便可以达成系统的整体目标。

这背后的原理也很简单：低维简单问题易于高维复杂问题。将高维复杂问题进行切割，到我们能够妥善处理的粒度，多个简单问题妥善解决后，复杂问题也就随之解决（来源于还原论）。

3. 构件关系简单

与其说简单，不如说弱依赖。在系统设计时，十分忌讳“强依赖”（A宕了，B就停止工作了），它是系统设计的灾难。

构件之间，尽可能做到少依赖、弱依赖：尽可能在A宕掉的时候，B还能自闭环地正常工作，这样客户的业务才可能不受阻碍，系统才会有一定的柔性。

想做到2和3极度不易但并非不能达到。在1的指导下，不断循环2和3，直到纳什均衡（没有任何可以改进的空间），其结果便是构件职责分工清楚，构件之间的依赖极少或者极弱。

四、怎么做好结构？

做好结构，基本等于做好系统。还是离不开系统三要件：系统目标清晰、构件职责单一、构件关系简单。

既然好的结构是严密的逻辑推导，那么也不得不使用科学的方法帮助实现。这里就不得不提及应对复杂系统设计的方法论：领域驱动设计（DDD，Domain-Driven Design），这并不是什么横空出世的新鲜玩意儿，这是Eric Evans在2003年就提出的一个近20年的设计思想，其核心目的是解决复杂软件架构设计。

对于复杂的B端产品，DDD的设计思想再合适不过，但要领会其中的要义，也并非一日之寒。

DDD包含战略和战术两大部分内容，对于B端产品经理，建议掌握战略部分：商业逻辑、核心业务流程设计、用例设计、实体识别状态图设计、领域模型设计、限界上下文识别机映射的设计。