浅谈前端开发中的产品思维

前段时间一直埋头在毕业设计中，总想着再写篇博客来告别今年的四月，那就来简单聊一下前端开发中的产品思维吧。

前端工程师的产出直接面向用户，应当对产品、交互和用户体验等层面有一定的认识。在公司有产品经理负责与前端对接产品方面的工作，但这并不代表前端工程师就不需要产品思维了。相反，产品思维能够作为一条重要的思路贯穿到整个开发工作流中，帮助前端工程师更好的去思考怎样将界面和交互做到更适合用户使用，更能让用户提升对产品的黏性，从而推进一款产品逐渐走向成功。

产品思维并不是一个普适性、固定性的思维，能根据既有的方法论总结出一套专属于自己的产品思维才是最有价值的。字节跳动的面试官也曾问过我“谈谈你对产品Sense的理解”，能够掌握产品思维的基本方法并将其实际应用在前端领域，对前端工程师来说是一项比较重要的能力。本文结合一些资料简单介绍了我对前端产品思维的一些认识，并希望能以此为题引起更多对技术和业务的思考和理解。

产品思维与产品经理

所谓产品思维，就是要求设计师要对用户有足够的了解，对用户需求有自己的见解，对产品定义有恰到好处的把控，并且对产品的核心结构有清晰的认知。

要了解用户打开产品时真正想看到的是什么，主要需解决的核心痛点和次要需解决的痛点又是什么，从而根据用户的心理预期设计和优化界面中的层级、各元素的视觉表现和交互方式。

设计师不仅要不断地优化产品，而且要增强用户对产品的黏性，让用户真正离不开产品。

摘自《规律与逻辑：用户体验设计法则》第五章：交互体验设计

产品思维总的来说就是一种解决问题的思维，它能够推动将解决方案逐渐产品化的过程。产品思维也不是一成不变的，它会随着行业领域变化，会随着人的经历变化，会随着问题本身变化。产品思维相对于其他解决问题的思维更注重综合性和全局性，因为满足用户需求和解决用户问题通常需要多角度、全方位地去思考，还要从多个方面着手解决。产品经理岗位便是因此而生，产品经理的存在主要是为了解决用户的需求，推动产品线中产品的落地。

产品经理要善于发现用户在生产生活中遇到的种种问题，寻找他们的核心痛点，并进行总结和分析，最终提供出一系列合适的解决方案。产品思维也是一种标准化思维，可以将产品思维看做是发现问题、分析问题、解决问题的过程集合，产品经理便是在这发现，分析并解决问题的过程中起到重要促进作用的。

产品思维的具体思维

一般来说，产品思维可以再次细分。对于任意一个特定的问题，从产品角度考虑通常应当是这样的：

• 发现问题，明确问题是什么，到底是哪里出了问题
• 分析问题，明确为什么会出现此问题，探究问题最根本的成因
• 解决问题，根据问题成因，寻找出问题的解决办法
• 产品化方案，将问题的解决办法提炼成为完整的解决方案，最终推动解决方案产品化，形成一个完备的产品

在发现问题阶段，用户思维和数据思维是产品思维的主导。其中用户思维属于主观角度，数据思维属于客观角度。首先产品经理应当从用户本身的角度去思考问题，把自己代入成消费者，自己才能切身感受到能否在这样的产品中获益。

你做的产品连你自己都不愿意用，那还指望别人会喜欢用吗？

数据思维是一种极其重要的思维，即通过统计数据发现问题，用数字和图表说话更具有说服力。根据不同业务指标的涨幅跌落，产品经理应当能够快速分析出是哪里出现问题，并快速定位到具体问题。

在发现具体问题后，产品经理应当着手去思考为什么会产生这个问题，要有打破砂锅问到底的精神，这里面体现的产品思维是一种本质思维。这里可以使用5W1H分析法去具体分析，即时间（When），地点（Where），人员（Who），对象（What），目的（Why），和解决方法（How）。5W1H分析法我会在后文章节中具体展开。

在通过5W1H将问题彻底拆分后，便可以开始有针对性地寻找问题的解决方法。有时候，解决问题的方法是多样的，那么这些方案我们该如何取舍呢？在这里产品思维就体现在效率思维上。效率思维指引着商业的发展方向，高效的解决方案能够让商业的发展提高效率，从而提升交易数或交易额，进而通过解决此问题获得更多收益。

最终阶段为产品化方案，在这里产品思维体现为标准化思维。我们需要把产品的解决办法提炼为完整的解决方案，促进解决方案标准化，总结共性，最终促进落地为一系列系统化产品或解决方案，以后遇到同类问题时可以复用此方法。

产品工作流

产品思维在实践应用领域可以体现在一个完备的产品工作流中。产品工作流又可以理解为产品线，一般是指一个技术团队的合作流程。一个常规的工作流或产品线通常包含有如下角色：

• 产品经理
• 用户体验设计师（交互设计与视觉设计）
• 软件开发工程师
• 软件测试工程师

在这样一个工作流中，工作环节可以粗略分为产品策划、产品设计和产品实施，每个环节中产品思维所要思考的问题不尽相同。在每个工作环节中又可以细分为多个详细环节，详情可见下图：

每一个常规的产品迭代都要经历以上环节，这之中需要考虑到诸如产品的定位、价值、资源、发展、场景、规划、功能、数据等等，能展开的问题很多，这里就不细说了。

快速判断产品经理的需求

聊产品思维必然会聊到产品经理，聊产品经理也必然会提到产品思维。但产品思维不是一成不变的，不同行业不同企业所需要的产品经理的能力类型也是不一样的，所以评判一个产品经理提出的需求是否合理也是不完全统一的，但即便如此，我们仍然有方法去判断产品提出的需求是否能够接受，这个能力非常重要，它可以很有效的帮助你减少无效加班。

具体来讲，快速判断需求是否合理的思路有三个：

• 逻辑清晰吗
• 理由含糊吗
• 有数据支撑吗

逻辑部分是需要在需求评审会中提问的，无论是私下交流还是群聊交流，需要把自己在逻辑上的许多疑惑都抛出，抓住一个不详细的点深入发问，这其实也是一个与产品深入讨论需求的过程，在讨论过程中即可明辨出需求是否合理。

理由含糊一般指的是“运营就想要这样的”，“老板就想做成这个样”，“xxx那边说想这么搞”，只是一种关系在上的施压，而没有具体在技术或者产品方面上的理由。当然这并不代表我们有能力完全拒绝掉这些理由，但至少当产品开始用这种理由来解释需求时，你应该心知肚明这是一个什么样的团队了。。

数据支撑才是最有说服力的理由。比如产品提出此功能上线后可以让用户增长率提高大约多少，收益增长率提高大约多少，转化率大约提升多少等等，这是需要往期运营数据支撑的，但往往这些数据支撑的需求也可以通过证伪来否定。具体怎么说？比如产品提出需求上线后预期结果如何，那么需要向产品提问“如果达不到预期，将可能会由哪些原因导致？如何分析上线后成果是否不如预期？”等等。几乎没有产品一开始就成功，但如果我们不能正确记录下失败的数据，那这个产品将永远没有成功的可能。

产品思维方法

前面聊到了产品思维的具体理论，那么落实到工程实践上，就有很多可以运用产品思维的具体操作了。这里举几个能体现出用户思维、数据思维和本质思维的例子。

用户调研

用户调研指通过各种方式得到受访者的意见和建议，并对此进行归纳和总结。用户调研的目的在于为产品设计提供相关数据基础。

用户调研方法包括调查问卷和用户访谈。调查问卷是比较常用的，可以使用互联网调查问卷代替传统的纸质问卷。（相信各位同学大学时都用过hhhhh）不过调查问卷需要注意一点，尽量不要让用户回答一些太过空泛的问题，比如需要让用户长篇大论回答怎么做，这是不现实的，最好是提供一些选项让用户在一定范围内进行选择，而不要让用户大费周章输入很多文字。

用户访谈是一种类似采访的形式，约一些典型的用户进行面对面回答并记录回答要点，从而更具体的了解用户的行为和行为背后的含义，利用得出的结论指导设计。

用户画像

通过一定量的用户调研可以模拟出一个典型用户的形象，这个就是用户画像。用户画像通常包括个人的基础情况，用户的痛点和需求等。比如一个新闻类APP的用户画像，就可以包括以下内容：

• 性别、年龄、职业等人物基本信息
• 打开APP的频率、留存时间、点击偏好等使用情况
• 当次需求迭代的目的，比如新功能的用户喜爱度、用户不满意或需要改进的地方等

整理用户画像的意义在于让产品经理可以关注目标用户的动机和行为，为后面的需求分析做准备。

需求分析

需求分析不是一个新名词了，在软件工程中也会提到需求分析。它的含义是对一些琐碎的需求进行整合并分析，筛选出以下内容：

• 核心需求，要实现
• 伪需求，未必要实现
• 初期要做或着急要做的
• 后续迭代要做的或不着急做的

并不是所有用户需求都要满足，用户没有提到的需求也并不是不需要做，整体而言，需求分析的目的就是把用户的需求合理转化为一系列的产品需求。

马斯洛需求层次理论在需求分析和用户体验设计中也很重要，上层的需求需要同时有下层需求的满足。比如我要做一款社交软件，那么即便用户需求中没有提到信息安全，在实现时也必须要做到信息安全，如果社交软件的信息能被随意泄漏，那么这个产品也就宣告失败了。

下图为马斯洛需求层次理论金字塔，图源网络：

竞品分析与可用性测试

竞品分析指的是把与自己产品相似的产品找出来，以同样的步骤分析其结构、流程、布局、用户画像等，再深入竞品的运营策略、盈利模式等，取长补短，寻找差异化和自身的核心竞争力，总的来说叫做“知己知彼，百战不殆”。

可用性测试是一种分析用户体验的测试方法，在受控状态下让用户体验APP的使用，并记录用户的操作行为，同时记录用户在使用中的疑惑，记录用户打开每个界面时的感受。通过反馈的问题去提炼典型的问题，并在产品迭代中加以优化，可以让产品的体验更加贴近用户预期。

前端的产品思维

说了很多从产品经理角度出发的产品思维，接下来要聊聊从前端工程师的角度看产品思维了。个人的理解是前端角度的产品思维更偏向于多方位思考，即不仅会考虑产品方面的具体思维，同时也会考虑这样的需求在实现方面会有怎样的困难或问题。此外，由于资深的前端工程师大多会对自己负责的产品把控程度比较深，在和产品讨论需求时，有时甚至可以为产品提出更好的替代流程或解决方案。产品打磨本来就是一个互补的过程，需要需求方和实现方共同讨论，共同交流。

需求的意义

在面对海量的需求时，前端工程师应当首先想到根据已有条件去分析此需求的意义，思考这个需求到底能够解决什么问题，能够产生什么价值。在需求评审会中要明确需求真正的意义是什么，判断需求是否合理，然后再考虑这个需求应该怎么做。评审会中的判断方式举例可以见上文“快速判断产品经理的需求”。

5W1H分析法

美国政治学家哈罗德·拉斯韦尔（Harold Lasswell）提出了“5W分析法”，之后经过人们的不断运用和总结，逐步形成了一套成熟的5W1H产品分析法。

5W1H产品分析法是一种思考方法，也可以说是一种创造技法，多被用于项目管理中。5W1H产品分析法对要解决问题的目的（Why）、对象（What）、地点（Where）、时间（When）、人员（Who）和方法（How）提出一系列的问题。

摘自《规律与逻辑：用户体验设计法则》第五章：交互体验设计

5W1H是一个很通用的分析方法，不仅在需求分析中适用，在用户体验设计中同样适用。如果某件事情通过5W1H分析法分析的结果都行得通，那么我们就有理由认为它是可行的。如果在分析中有任何一项差强人意，那就说明这个需求还有打磨优化的空间。

对于前端工程师来说，5W1H可以用来将需求和实现联结起来，当使用产品思维去分析5W得到了可行的结果时，便可以从技术的角度开始拆解需求，考虑1H中的实现部分。通常在产品给出的设计中不会包含具体到代码流程的交互设计，这部分就需要前端工程师在分析需求时去着重思考，如现有技术无法实现或实现排期不符合要求，这样的需求也是无法完成的。

工程化思维：就是要稳！

聊到实现，产品的实现也绝非单纯增删改查那么简单。前端工程化中有一个非常重要的环节是代码规范，规范短期来看不是一个提效工具，但它是一个非常有效的降本措施，可以在产品的一次次需求中逐渐迭代出一些基本的工程规范，并形成固定的组件库或“轮子”对团队的开发进行约束。这便是产品思维落实到前端开发中的工程化思维，简单来讲就是一个字，稳。

工程化讲究的就是要稳定，基础不牢地动山摇，如果组件的基础建设部分每次都要现写现编，不仅开发成本很大不说，可能引入的bug也会让测试成本提升，开发排期更长。我们从需求分析中提炼出的代码组件规范如果仅仅落实到文档上，是很难保证所有团队成员在任何情况下都完全遵守的，毕竟开发复杂度摆在这里，谁也不想给自己多找麻烦。

比如我有一个提交表单按钮，这个按钮点击后发生的事情大概如下：

• 用户点击按钮，按钮变灰，并启动一个spinner图提醒用户正在提交中
• JS会收集此表单提交的信息，在表单验证成功后调用后端接口，传输数据
• 数据提交完毕后，无论成功还是失败，都会有一个toast为用户反馈结果，此后spinner消失，按钮恢复
• 之后对于成功提交的数据，是需要回显还是将页面跳转至其他位置，需要根据业务情况不同来配置

其实不难看出，这一套标准的提交流程是相对而言比较通用的，那么就可以考虑将其复用成为一个大组件，在任何需要表单提交的场景时都可以直接调用，只需要更改不同的表单字段、接口、数据处理函数即可。这样的操作在中后台管理系统中非常常见，使用场景也很多，只要这个组件本身经过测试认定为稳定，那么之后一旦出现bug，排查范围也便缩小了很多。

面向需求 or 面向接口？

这也是一个在中后台系统开发中常见的问题。比如某天后端说：“嘿，哥们，我希望在这个页面显示一个警告信息，不要让用户随便修改这里的数据，你能帮我加一下吗，我跟产品说过了，她说没问题”

此时你是前端工程师，你应该怎么办？

要相信你在页面设计方面的专业度，对于这样的问题，一定不要随意接受，而是首先要问清楚：“这个需求背后的目的是什么？或许我能提供一个更好的办法”

这个问题可不一定是给自己自找麻烦。或许这个警告信息的背后是希望保障数据安全，不要让用户去动自己不该动的数据。此后这个问题就变成了一个权限控制问题，让没有权限的用户根本无法进入此页面，或者提供一个弹窗提示。

最后这个问题甚至有可能是要后端配置权限解决，前端不怎么需要改动代码。

使用面向需求的分析方法，比面向某个单独的数据接口要好得多。鉴权或安全保护等问题从来不是一个细节问题，而是要从项目的宏观上考虑的事情。一个警告提示框是小事，但设计这个提示框背后的原因却可能牵扯出很多问题。

好的设计不应被察觉

思考一下你在使用app的过程中，有多少时候会关注显示方式是卡片、无框还是分割线？在查看表格信息的时候，有没有关注过表格的背景色是什么样子的？有没有注意到表格的分界线粗细程度怎样？

如果你反问我，“我为什么要关注这些？这些细节的设计对我使用app有什么影响吗？”那么恭喜，这样的设计就是好的设计，至少它是及格的设计。

为什么？设计是会影响到人的观感的，但如果在人的认知中，这样的设计稀松平常，不会让我产生认知上的困惑，也不会阻碍我工作的效率，那么这就是好的设计。UI和平面设计在思路上有一些区别，有时候你不需要夺人眼球，从用户的视野中悄悄消失也是一种设计思路。这就叫“好的设计不应被察觉”。如果你发现某个按钮点不动，或者操作过于繁琐影响观感，你可能就会吐槽一句“不好用”，这便是在设计中需要着重考虑，着重打磨的。

你真的会正确使用表单吗

对用户而言，输入表单的体验其实总是不太好，但这也是无法避免的事情。近年的设计中，表单设计越来越向着简单轻便的方向发展，设计师们为了努力减轻用户输入数据的心智负担，将众多的逻辑都放在了代码里。

举个栗子：

某公司招聘系统，录入在线简历时需要输入的字段有一部分是：

• 姓名，年龄，身份证号码
• 性别，籍贯，出生年月日

思考一下，这个字段是否合理？可能在程序员的角度看，每一个字段都是一个再普通不过的信息，让用户对着输入就可以了。但是这之中“身份证号码”是一个特殊的字段，因为它与其他字段具有关联关系。根据身份证号，我们是可以推算出用户的出生年月，年龄，性别，籍贯等信息的，所以这些信息其实没有必要再输入，只需要根据用户输入的内容进行解析即可。

再举个栗子：

某电商平台，录入收货地址时使用的是input输入框，需要用户从省市区开始逐级填写地址。

思考一下，这合理吗？

看起来收货地址确实是需要文字输入的，但它无法保证表单格式的规范性。在设计表单时，尽量要做到让用户做选择题而不是填空题，一方面是为了用户选择的方便，另一方面是可以将数据标准化，方便数据的处理和管理，输入比选择要慢得多。对于这个场景，一般的做法是使用级联选择器选择省市区，具体到街道、小区、门牌号则依然使用input框输入。这样能够保证省市区的标准性和准确性，提升产品使用效率。

但，大量的选择选项，一定好么？

再再举个栗子：

某国际化应用，面向中国用户和海外用户。在注册账号时，需要选择自己的国籍，于是程序员设置了一个巨长无比的select选择框，并调用了一个返回全世界国家和地区信息的数据接口。可能你阅读到这里应该已经猜到会出现什么问题了，没错，问题在“中国好难找”。

脑内模拟一下这个事情，在一堆不知道是按拼音排名还是按英文首字母排名的国家列表中，找到中国，你需要花费多久时间？一个不是很完美的解决方案是，设置一个输入框，让用户输入自己的国家名称，然后再去数据库匹配，这可行，但由于还是让用户做了填空题，所以体验不能做到最佳。那么最佳实践应当是什么呢？

没错，是地理定位。在选择国家地区页面可以请求用户使用地理位置信息，或粗暴点直接基于IP地址查询国家，并将返回结果置于最前，并提醒是使用实时位置确定的国家，用户只需要点击一下这个结果便可完成输入，是不是很方便？

表单的设计哲学还有很多，这里浅浅地点出几个常见的例子，实际工作中还会遇到很多类似的情况，在设计表单时，一定要多从用户的角度考虑，思考清楚每一个输入，每一次按键都代表着什么，不要让用户输入冗余的数据，尽量多做选择少用填空，这才是设计表单的最佳实践之一。

深入思考技术与业务

技术和业务的关系是什么？两者又是怎么样互相作用的？这是一个对立统一的问题，也是一个值得我们使用产品思维来深思的问题。

字节三面的面试官问过我这个问题，当时回答的比较简单粗略，现在在这里写一写也算是对这个问题的复盘吧。

技术之于业务

我们为何要发展技术，为何要不断追求先进技术？科学技术是第一生产力，先进的技术带来的作用就是先进的生产力，只要用对地方，用的合适，就能做到先进。说白了，做技术本身就是应当服务于业务的，无论大大小小的业务，写在纸上只能叫思路，落实到代码上才叫实打实的产品。产品的实现依靠着代码，代码组织的能力和规模强依赖着技术的进步和发展。所以，技术之于业务，如同发动机之于汽车，汽车设计的再优美也是锦上添花，它的本质就是交通工具，没有动力系统做支撑，汽车便无法行进。技术之于业务也是如此，离开技术的发展，便不会有今天诸多纷繁复杂APP的诞生，没有先进技术作为支撑，再强大的高新技术产业也是空谈，一切都要落实到根本，从实事求是的角度出发。

从产品角度思考，技术的落地应用是将发现的问题逐个解决的过程，是在产品实施中的一个重要的环节。产品的实施离不开技术的发力，实现业务的基础便是需求分析的产物和软件开发技术的加持。技术的应用不仅在实施方面，在后续的运营维护上也有技术的不断支撑，如监控，风控，安全等基础设施在维护业务正常运行上也起到了重要作用。

业务之于技术

我们发展业务是为了什么，难道业务只是一种赚钱工具，为公司带来营收和效益的吗？反观计算机技术的发展史，诸多理论、诸多语法、诸多插件、诸多框架，诞生背景多为在解决实际问题时产生新的问题，为了彻底根除问题，人们便发明了集成度更高的效率工具，将这些工具逐渐应用在新的复杂的业务上，为提升商业化效率提供有力支撑。如果没有业务的发展，技术发展的进程将远不如现在快，技术的丰富程度也远不如当今茂盛。所以我认为，业务之于技术起到了一个反推作用，如同火箭推进，业务快速发展的同时带动了科学技术的进步，为技术发展在物质基础上提供有力的支撑。业务的拓展必会带来一系列技术上的问题，或屡屡挑战已有的参数限制，发展技术的目的也是为了能够不断打破这些限制，让业务的能力提升到一个新的高度。毕竟，纪录就是用来打破的呀。

业务反作用于技术的过程也是一个产品重新迭代的过程，即在业务实施中又发现了新问题，然后开始着手分析问题、分解问题，并尝试提炼新的解决方案。在这个过程中，技术也会跟随着问题的分解而向前推进，最终达到一个反作用的效果。

小结

前端工程师应当注重对自己产品思维的提升，但思维终究是一个理论指导，想要真正体会到产品思维对技术和业务上带来的魅力，还是要尝试在开发实践中多把产品思维落实到工程中。通过用户思维和数据思维发现问题，通过本质思维分析问题，通过效率思维解决问题，最后将解决方案标准化，在工作中不断提升自己的产品思维能力，相信会让你的职业生涯更进一步。

参考资料

• 《规律与逻辑：用户体验设计法则》
• 《人人都是产品经理》
• 前端工程师的产品思维：https://zhuanlan.zhihu.com/p/84597015
• 前端工程师应该掌握的产品思维：https://juejin.cn/post/6960564546176024590#heading-2