7 年时光里，我完成了从业务型产品（智慧园区、电力营销系统等）到低代码平台的跨越。这份 “稀里糊涂” 却愈发热爱的职业旅程，让我对 B 端产品设计有了诸多跳出具体操作的思维沉淀 —— 不聊原型怎么画、文档怎么写，只聚焦如何穿透需求表象、用更优雅的方式实现产品价值。以下，是我对 B 端产品设计的深度思考，或许能为同路者提供一些参考。
不知不觉中，已经从事产品经理7年了。我是学计算机出身的，刚毕业的时候应聘的是后端开发工程师，后来诸多的因素，稀里糊涂地成为了一名B端产品经理，幸运的是，我热爱做产品。如果真的存在多条世界线，我肯定爱产品经理甚过后端开发。
前面三年多，都是做业务型的产品经理，比如智慧园区、后台管理系统、电力营销系统，这种类型的产品对产品经理的业务能力和行业的专业性有较高的要求，而对于产品设计本身则稍微次之，不会像众多C端产品对界面美观、交互友好性有那么高的要求，以能解决问题为第一要义。
最近三年多，都是在做低代码平台，这对于我来说是一个全新的领域。低代码平台与一般的业务系统不一样，并不是解决特定业务场景问题的系统应用，而是类似于编程语言的框架，只提供构建应用的脚手架，基于低代码平台可以开发较高复杂度的业务应用就取决于脚手架的丰富性、灵活性，这也就要求设计低代码平台的产品经理不仅需要有开发基础而且有高度抽象能力、强大的结构化思维能力。
下面总结一下我在产品设计上的个人心得，主要分析的是B端产品，因为本人没有实践设计过C端产品，也许可以参考，自行辨别。
探索事物本质是一个很深层次的问题，在科学、哲学等学科中也是永恒的话题，譬如道家中“道”，物理学中的“大统一理论”，万物的表象可以万千纷繁，可是最终的至理却是简洁优雅的。那么怎么从杂乱无章的信息中分析出问题的本质，找寻到现象背后的真理呢？
当然，在科学和哲学上，这应该是科学家和哲学家的工作。而在产品设计领域，这自然而然就是产品经理的工作了！
在产品设计层面，我觉得这个问题在下面两个阶段加以分析。
在需求分析阶段，需要识别用户的真实需求。B端的产品需求一般可以分为内部需求（团队内部规划的需求）和外部需求（客户/用户反馈的需求），因为内部需求的背景、应用场景、解决什么问题等各方面因素都是比较明确的，所以这里侧重介绍外部需求。下面细分两种情况说明：
情况1：用户反馈的是最原始的需求，可以作为我们产品设计的突破点，在此基础上做深层次的扩展，而不是仅仅完成用户反馈的需求就行。
举例说明：
很多用户反馈希望产品某些页面在向外分享的时候可以加上企业的logo等品牌标识。
用户虽然只是反馈增加logo品牌标识的这个需求，但是深入用户的分享场景考虑，用户可能是希望增加自己公司的品牌能力，将自己公司的文化氛围传递给合作伙伴。
所以，对于这个需求，如果真的只是针对某几个页面做一个定制化的分享页面就有点僵硬了。反之，换一个思路：
将页面分享的功能做成一个组件（实现层面），在组件中可以设置（有专门的设置页面）分享的风格样式：背景颜色、logo、slogan、布局排布等等，因为有不同类型的页面，支持多种风格样式，有需要分享的页面直接接入这个“分享组件”即可，后续也方便扩展。
当然上面的分析主要是针对标准产品或SaaS产品，交付型的项目产品不在讨论范围内。
情况2：产品经理通过市场、售后等部门获取到的并不是第一手需求，经常会有用户将自己的解决方案作为需求。
当然需要肯定的是，这类用户是基于对产品有一定了解或理解的，但是作为产品经理的我们需要结合这个“需求”的背景、使用场景、解决什么问题，模拟使用过程等多个维度去识别用户的本质需求，而不能直接将用户的“解决方案”作为需求开始设计。
上面只是简单罗列了这两种情况，实际工作中会更加复杂，但是无论怎样，在需求分析阶段需要仔细探索本质需求。
在产品设计阶段，侧重于产品内侧，需要将用户需求转化为产品功能。
经过前面诸多的需求分析，我们拿到一个明确的产品需求，下一阶段就是进入产品设计。
为什么到了产品设计阶段也需要分析本质，探索根源，这是因为在B端系统中，功能和结构是复杂的，有时候，产品其实已经支持了新的需求，可能只是没有前端页面或者缺少一些功能将其组合起来，这就需要避免我们做重复工作，避免产品做的很臃肿甚至相互冲突的情况。
此时，我们不需要急着去画原型、写文档，可以先从以下方面先分析一下：
经过上面几步分析后，我们自己心里就会很清楚，新的需求在产品上本质是由哪些已有功能/结构组合而成，或者需要另起一个新的模块，那么在与开发团队和测试团队沟通时可以做到游刃有余！
不管是在需求分析阶段那还是在产品设计阶段，我们的目标是用最优雅的方式去满足用户需求。
抽象的反义词是具象，如果上面的“分析问题本质”的过程是由外向内，由浅入深，那么抽象就是跳出问题本身， 站在更高的维度将分析的对象作为一个整体，这样可以暂时忽略内部细节，从全局上考虑各对象之间的结构与联系。
这个解释也是略带抽象的，下面用一个简单应用登录页面来加以说明：
登录应用对于用户而言很简单，输入账号密码或者扫码就完成登录了，对于程序与数据而言，【登录】本质上时候就是鉴权，通过登录信息（验证码或账号密码等等）来判断登录的用户是否有权限进入应用，如果有，则可以进入，否则拒绝（若支持注册则进入注册流程）。
一般B端业务系统中支持多种多种登录方式，比如手机号验证码、账号密码、微信扫码、钉钉扫码等等。
每一种登录方式的内部逻辑都是不一样，但是登录的主流程是一致的，我们在设计过程中不要被各种登录方式的内部逻辑而被迷惑而不知所措。
如果用抽象思维，我们可以将每种登录方式作为一个整体，暂时忽略其内部复杂逻辑，在登录主流程设计中，不管是哪种登录方式只需要关注：主流程给你一个登录信息，你给我返回一个登录结果（可以登录/不可以登录）。
主流程确定之后，再考虑每一种登录方式的差异，后面需要接入新的登录方式也只需要关注这种登录方式内部的逻辑。
结构化思维在日常工作中被提及到的最多，特别是对于产品经理来说，尤为重要。结构化思维本质上就是将信息进行模块化，再根据模块之间的逻辑关联建立层级关系（时间、空间等）。
下面就用腾讯体育网页端的首页举例说明：
按照信息的内容可以分为四个模块（还有其他模块，这里就不详细说明了）：
按照模板的信息作用层级关系 功能导航 > 赛区Tab > 热门比赛 >热点咨询，所以腾讯体育按照从上往下的层级关系展示，清晰明了。
当然举这个例子是为了说明结构化思维，并不说这个首页就已经很完美了，在信息展示和交互体验上还有较大的提升空间，可能腾讯体育更重视腾讯体育APP，在网页端没有投入太多的经历，下面作为腾讯体育的老用户吐槽几点：
如果是你，这个页面会怎么设计呢？
结构化思维作为我们在工作中的重要工具，无处不可使用，它的呈现方式也可以是多种多样的。
如果是产品功能设计，可能以界面UI的形式呈现；
如果是开发实现方案，可能是以类图的形式；
如果是方案汇报，又有可能是PPT或Word文档…
一直以来，业内有一个很热门的话题：产品经理需不需要懂技术？
认为不需要懂技术的主要观点有：
（1）产品经理应该以业务为主，更多的时间精力放在业务上；
（2）懂技术反而限制自己的用户思维；
（3）术业有专攻，专业的人做专业的事情。
认为需要懂技术的主要观点有：
（1）跟开发测试团队沟通更加高效；
（2）基于对开发实现的理解可以做出更合理的产品设计；
（3）防止被开发忽悠；
（4）从技术的维度驱动产品创新。
我个人观点是：B端产品经理必须得懂技术，可以不用去写代码。
产品经理是对产品的功能、定位理解最透彻的角色，而开发在考虑实现方案时往往只会在当前的功能去考虑，不会从产品的全局性考虑，这样会导致开发实现方案会有很大的局限性。
那么需要技术需要了解到什么程度呢？
（1）首先在认知上不能排斥技术，不能觉得技术实现只是开发负责的范畴，与自己不相关；
（2）前端：缓存，静态资源，不同终端使用的前端技术、浏览器、第三方前端资源库等等。
（3）后端：了解API、数据库、缓存、技术框架的一些概念等等
当然，以上是个人观点，不同行业不同方向的产品经理都有所差异，但能让自己在产品岗位上游刃有余是我们相同的目标。
以上都是个人在工作中的总结，并没有涉及到具体的工作怎么去做，某种需求应该怎么去设计，原型应该怎么画，只是在思维层面有所总结，思维也是我们强大的工具。
所有的设计工作本质上应该都是一样的，不管是软件设计、工业设计、服装设计，甚至是摄影，哦不对，我为啥要说摄影。。。
设计是有灵魂的，个人觉得短时间内AI还是没法取代，如果真的到了那么一天，这个世界应该会少了一些乐趣吧。
本来写了很多，但是又删了很多，整体结构还是不太清晰，只是当成个人随机总结，想到哪里写到哪里，不做为工作汇报。
本来想整点图片，搞点示意图，阅读起来舒服一点，但是我懒得搞。。。下次再说吧
最后，愿我们变得更强，工作更加从容，生活更加美满！加油！
本文由 @桃树窗前 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。