2019已经过去，这一年，遇到了很多挑战：担负起所在中心几个重要的后台系统的版本迭代

两年多的工作时间里，做过B端产品也做过C端产品，最大的感受就是，B端产品虽然没有C端产品色彩丰富以及拥有一些炫酷的动效，但B端产品里面的业务逻辑一串连一串，沟通和理解成本要比C端多的多。

此文主要来分享一下，通过做B端产品踩过的坑而总结出的心得。

01、挖掘真实需求

任何⼀款产品若要深入人心，必要深谙人性。需要区分清楚⼈类表⾯需求及潜在需求。只有把握了人性深处的需求，才能让产品植⼊⽤户的灵魂深处，欲罢不能。

需求最根本的来源永远都是⽤户，只有了解了⽤户真正的需求，才能做出⽤户满意的产品。这就要求产品经理需要在与⽤户接触的过程中，深⼊观察、倾听、理解⽤户到底想要什么，更要挖掘⽤户内⼼深处所想的但是却没能被表达出来的需求。

今年主导了一个改版项目：cms系统，主要用户群体是负责公司大促营销页面的运营人员。改版后，有收到一个问题单“将时间编辑界面缩小，界面过大会误点到空白处”

看到这个问题的我一脸懵。思考：若直接按照业务需求来，将时间选择器界面缩小，是否能解决这个问题？

问题提炼：“框太大容易点到空白处”，简而言之，即“误操作”。

思考后与实操后，发现并不是时间选择器界面大小的问题，而是每个日期的点击区域过小（改版时，前端开发之改了时间选择器控件的视觉样式，但未调整对应的点击区域大小）。与运营人员沟通后，证实了我的想法。

解决方式：与前端一起，适当增大了每个日期的字号与点击区域，解决了运营的问题。

接到需求后，我们首先要挖掘出用户真正的诉求是什么，切忌只停留在需求表面。

常用方法：用户访谈、焦点小组、可用性测试、问卷调查、用户反馈

02、评估需求

在做需求前，我们会组织发起需求评审会，让大家一起对需求进行讨论。此时，需要注意的是，除了需要关注用户体验的问题以外，还要与开发一起评估该需求的实现：不懂技术没有关系，开发会告诉你该需求的落地会出现什么问题，在实现上会有什么难度，这些在需求评审阶段都会提出来，这就要求你在交互构思阶段解决掉，针对这些问题提出合理解决方案，否则只按照自己的想法画出了原型后，开发告诉你这个方案必须修改，否则开发成本过大，无法在排期内完成，这个时候你再去改原型将会费时费力。

如下图，列表展示的是模板信息，将模板内的信息数据（橱窗商品数、分组数、使用店铺数）也展示在列表内

乍一看没有任何问题，但实际上这3列需要分别统计每个模板的各项指标数据，如果在一个列表（接口）中全部展示出来，性能很差，导致查询速度会很慢。

开发给出方案，将这3列信息收起来，增加一个按钮，点击后出弹窗展示，如下图：

但是这种方案满足不了业务需求，无法同时查看多条数据作为对比，探讨后，最终采用这三列还是放在列表内，鼠标hover后展示每个模板的各项指标数据，这样会快很多，并且也能满足业务需求，减少操作成本：

事实上，在做数据查询时，我们需要考虑到数据量大小与加载时长，设计时需要保证系统性能针对不同需求给出合理方案。

03、从用户角度设计

在做设计时，首先需要考虑到使用场景、使用人群、产品目标等，针对使用场景，假想自己是一个真实用户，当你看到这页面的时候，第一眼你获得了什么信息，是否明白自己能够在这个页面里完成什么操作。而设计师看页面，看的是色调、背景、设计感、风格等，反而忽略了最真实最重要的东西，要记住，好的页面设计是给人以引导，告诉他们要去做什么。

在一次体验走查中，点开了一个“查看详情”页面：

用源代码形式展示新旧值，并且用红色和蓝色标出作为区分。逻辑上没毛病，但是思考下，我们的用户群体是运营人员，他们真的能看懂代码吗？

第一次点开这个页面，以为是出现了bug，沟通后才知道，这个功能是开发直接做的，因为他们觉得用代码形式最能直观的展示出数据的变化情况，并且觉得这方案十分完美就没有告知我。emm…

找了几个运营人员沟通后，原来他们都对这种代码形式感到头疼，但看也能看懂，就是太费劲。是这样啊，能用中文一眼看懂的东西，为什么要用英文字母来展示呢？后台系统最注重效率！

解决方式：将所有参数列出来，变化值用蓝色填充。给一个“查看源代码”入口，满足习惯看代码的开发人员（cms系统主要用户是运营）

做后台功能设计时，需要从该功能的真正用户群体出发，切忌只站在自己的主观角度来考虑。

04、了解常用功能实现原理

作为一名产品经理，对于开发原理知识应该具有一定的了解和认知。这样一方面能够保证和开发人员沟通的顺畅，另一方面懂得基础原理能够在设计的过程当中避免很多可能犯的错误。这里简单介绍一下我在做项目过程中经常使用到的功能及实现原理。

1.批量导入实现原理

后台系统经常使用到“批量导入（上传）”功能，通常会提供一个“下载模板”的功能，用户需要按照提供的模板及要求填写后方可成功导入。

如图是cms系统里，批量导入excel表格，前端返回的错误提示样式，运营需要根据这些错误信息将表格修改后再重新导入。

假设你是运营，需要根据这些错误信息来修改表格，操作效率是否高效。

针对错误提示，其实可以提供“下载错误表格“的功能，服务端校验后将表格内错误单元格标红，将错误信息返回给前端的同时提供一个“下载错误表格”功能，这样使用者对照着标红的表格，修改起来更为方便。

经常在与开发沟通的过程中，越来越觉得懂技术的产品经理确实会在方案落地上有很多优势，但这个懂技术并不意味着你要会写代码，而是你需要了解计算机是如何实现你的方案的。

2.搜索与筛选原理

后台系统经常使用到搜索与筛选功能。

搜索，分为模糊搜索和精确搜索，精确搜索是指搜索内容与搜索结果完全一致，而模糊搜索则会自动拆分检索词为单元概念，并进行逻辑运算。通俗点说，精确搜索就是全字匹配，你输入了“王”，搜索到的结果就是“王”；模糊搜索就是关键字匹配，你输入“王”，搜索结果可能是“王五”、“王六”…我们实际在使用中，模糊搜索会最常用，比如：淘宝的商品搜索、网银云的音乐名称搜索、微信的好友搜索…

后台系统的搜索，通常又分为纯前端搜索和服务端搜索。二者区别是前端搜索不能有分页（只能搜当前页的内容），适用于数据量少的时候，所以我们最常用的是服务端搜索。

后台系统搜索时，我们考虑到系统性能（函数防抖与节流），一般会在输入框后加一个查询/搜索按钮/icon等，点击之后再发送请求，而不会做成移动端的实时匹配，如下图：

筛选，一般切换了选项后就能搜：

思考一下，搜索与筛选组合时，筛选项需要在点击按钮后再发送请求吗？

理论上来说，组合查询时，筛选项可受制也可不受制按钮。查询条件较少时，两种方式都ok；查询条件较多时，若筛选项切换即请求，当每次切换筛选再输入内容再点击“查询”，相当于多请求了几次，浪费系统性能。

个人认为，组合查询时，若有业务需求（筛选为高频操作），可将搜索项的按钮放在输入框内（避免歧义）；一般情况下，建议筛选和搜索均需受制于查询按钮：

3.弹窗高度原理

PC端产品经常出现弹窗（包括表单类型、文本类型、阻断类型等），表单类型内容多的时候可能会出现两列的情况。

之前有和同事一起合作制定过后台设计规范，定义了输入框宽度360px，上下高度24px，弹窗限高540px：

上图为表单类型弹窗，一共有二十多个字段需要用户填写，而按照规范做出的一屏最多展示14条字段，这样操作起来需要频繁上下滚动，极为不便。

后台更注重效率性，将弹窗上下间距调整为16px，出现错误提示时下一列下坠8px，弹窗限高600px，两列时将输入框宽度调整为280px；

此外，将所有字段罗列出来，根据用户诉求，按照操作频率从左边开始，从上往下排列，最不常用的字段固定放在右下方：

调整后，一屏可展示20条字段，且不会出现上下滚动条。

自适应：弹窗高度根据内容多少自适应，确保视觉效果更佳；

最小高度：设定一个最小值，达到了这个最小值后，不论内容多少高度不再变化；

限定高度：设定一个最大值，达到了这个最大值后，弹窗内出现上下滚动条。一般情况下，限定高度值不超过

600px（且若屏幕内容区域大于600，则弹窗最大高度为600；屏幕内容区域小于600，以屏幕内容区域为最大高度）

除特殊业务需求外，我们一般不做弹窗撑满屏幕。

05、增强组件化设计思维

组件化设计：就是把产品需求场景化、视觉表达模块化，每个组件基于复用为目的，使其具备独立的完整解决方案，通过标准的规范组合方式来构建整个设计方案，从而提升设计效能。

这里就不赘述组件化设计的必要性与好处了，目前很多大厂已制定出较成熟的组件设计规范，19年上半年花了几个月时间和同事一起制定了适用于我们中心内部的设计规范，目前正在使用中。

新手产品设计师需要增强组件化设计思维，推荐去熟悉Ant design、Element、Fusion Design等，并熟悉常用的组件类型：

需求：筛选区域增加地区筛选（省市区），并且可以只选择省/只选择市/只选择区：

有没有觉得，地区选择器放出3个选择框很累赘：

地区选择器，由3个选择器改为1个级联选择器，且定义“选择即改变”，即可直接选中父节点（需求定义可只选择省/市/区）；选择省以后，出现下一级选择框，此时可点击其它空白区域收起下拉框；选择了省市区后，下拉框自动收起。此外，由于选择框固定宽度，限定字数超出用…代替，鼠标悬浮时展示完整信息：

产品设计时必须熟悉常用组件类型，要根据不同业务需求给出合理方案。

06、打破固有思维

随着工作时间的推移，产品经理会在知识、方法和经验方面逐渐形成个人定式。它们在一定程度上能够帮助产品经理迅速解决问题、提升效率。然而，随着这些内容在设计时被反复使用，会形成比较稳定的、定型化的思维路线、方法或模式，也就是固有思维。这种固有思维会带来消极影响，无形中妨碍采用新的方法，并约束创造力。

做过的改版项目中，经常会遇到以下类型的弹窗：

上图为查看楼层操作说明的弹窗，用户仅能查看内容，此时“取消”、“确定”按钮的意义何在？且无内容样式，看上去是不是有点奇怪。

大家总是会有固性思维，在弹窗内加上“取消”与“确定”按钮，但其实在很多场景下，不需要用户进行操作的（仅有浏览功能类的弹窗），是不需要这两个按钮的。此外，弹窗一般会设定一个最小高度，无内容时，需要给个空状态，视觉效果更佳：

仅有查看功能类的弹窗，底部无需加取消与确定按钮。

在合适的场景、时间和项目中，最大化发挥固有思维的积极作用，尽量避免它的消极作用，与此同时，通过好奇和同理心不断学习知识并挖掘问题的本质，才能真正平衡设计、工作甚至生活。