标签：因素 场景 功能 用户 产品设计 消息 影响 我们 备注
日常中我们接触的产品设计其实是一个比较宽泛的词，不仅仅局限于视觉效果，还有功能逻辑、交互体验等等。对于经验相对欠缺的PM来说，如何做好产品设计是值得深入学习的，这次我整理了个人觉得比较重要的几个影响因素，分别用案例给大家呈现解读一下。
性能因素
这里的性能其实就是开发同学口中常讲的，比如说页面的加载时长，接口的调用次数等。其实大多数情况，产品经理在设计产品功能的时候是不太建议去考虑开发成本或阻碍的。
我们要做的就是极致的功能，解决用户的痛点需求，甚至为了迎合业务我们还需要开发同学去偿还欠下的技术债，但如果你的产品设计影响性能从而给用户带来较差的体验就这需要注意了。
我们先来看下面一个例子：
背景：搭建淘宝生态下的商家服务系统，依托淘宝接口查询商品信息，且系统本身可针对商品添加信息标签。
使用场景：用本地添加的标签条件查询商品
限制：淘宝三方接口有相应数量限制
常规的设计，我们一般都会说首次进入列表页展示默认条件的商品，然后搜索时查找对应条件的商品。但这个地方我们需要注意查询数量的限制，如果说搜索条件查找出来的结果很广，接口调用次数可能会多次调用，可能会导致页面加载时间过长。
这个时候我们其实可以限制查询数量阀值，比如200个商品。后段做分页效果，首次查询给予总结果数量，翻页时超过200个后再去请求下面200个商品信息。
这样设计就能分多次去查看结果列表，没有让用户在首次等待过长时间。站在用户体验角度，针对查询请求页面给予用户最快的反馈。
看完这个后，我们再来看一个开发角度性能的例子：
背景：数据导出，同时校验导出数据中某个字段属性是否完整，并给予提示
使用场景：用户导出数据，当某个字段属性缺失时给予提示；不缺失则完整导出
这个需求其实大多数同学都有经历过，通常我们会让开发同学校验所有的导出数据并给予总的提示，例如是存在多少条数据存在缺失的字段信息。
但是当导出数据非常多的时候，全部校验是非常耗时的。这个时候，我们其实也可以参考上面的做法，当校验异常数量超过阀值的时候我们就不继续校验。
这种设计本身还是很值得推荐的，站在场景角度，提示‘超过50款商品缺失某字段’和‘共有65款商品缺失某字段’效果上来说其实没有差很多，但对于开发同学来说，他们的工作量减轻的同时，也提升了用户体验。
这种设计往往是用户和内部团队都喜欢的设计思路。
场景主导功能
场景理念主要是为了让我们能够站在用户的角度以及真实场景中去思考功能价值，很多在你看来不好理解的功能其实用场景带入会很直观。
这里我举个大家比较熟悉的例子，现在的办公软件已读未读功能相信大家都比较熟悉。对于消息的接收方，会有一个标为未读的功能。
那么问题来了，如果消息接收方已读消息，消息发送方看见消息状态已读后，此时接收方将消息标为未读，那么你觉得此时发送方的消息状态是否要受到影响？
站在消息发送方的场景角度，我们要明确已读的功能目的是为了让发送方能感知对方是否已读了你的消息。
但如果我是个接收方，我看到了你的消息并且点开了对话框，此时发送方消息显示已读。我当下又有比较多的事情需要处理，担心遗漏你交代的事情，此时‘标为未读’的功能就来了。
它仅仅是为了接收方做的一个自主提醒功能，对于消息状态是为发送方服务的。所以，场景主导去思考功能，对于产品设计的理解有很大的帮助。
用户习惯
接下来讲的是用户习惯，用户习惯主要是兼顾用户使用软件的体验。我之所以也把它作为一项重要因素是因为一个成熟产品培养出来的用户习惯是根深蒂固的，且不同的用户习惯是会影响产品页面整体布局的。
直接看案例：
淘宝旺旺端主要以左中右形式布局，从左到右分别是买家联系人列表、消息沟通区域以及功能操作区。
我之所以拿这个举例，主要是因为功能操作区在整个版面占有的区域很小，如何让功能展现全面的情况下保证用户体验是很重要的事情。
最开始的版面设计，我们参考了大量用户的使用诉求。发现大多数用户习惯用两个差异比较大的维度去搜索，而这两者间的关系是存在关联关系。因此我们在设计的时候就有了下面这种样式。
基于两种搜索，我们期望用户能快捷切换，且展现的信息会呈现差异化，所以采用了顶部、底部两种路径，搜索的结果项也做了一些差异化特点。（涉及业务敏感，不具体展开）
同时，我们可以再看一个细节。大多数客服在接待过程中，搜索商品场景下，客服同学很倾向使用翻页功能。
为什么会这样，主要是因为客服同学对于自己店铺的商品非常熟悉，且店铺商品长期不变。我多次搜索某个条件时，对于出现的结果已经有了预判，我知道我要搜的商品可能在第几页。
所以，这种场景下，即使是版面限制，我们还是会选择将页码功能直接透出。
这个细节其实很好说明，不同用户的使用习惯决定了产品布局。如果换做是一个其他产品，页码翻页这种级别的功能布局几乎是不会重点考虑的。
历史功能结合
最后我们来说一下历史功能结合场景，对于大多数公司，我们常做的事情都是在堆砌功能，缝缝补补。没有说产品存在缺陷，满足不了业务，就要推翻重做。尤其是大厂，这种现象尤其明显，大家都知道某个产品存在缺陷，但这种量级的产品谁也没有勇气推翻重做，况且推翻重做也不一定就真的比现在好。
直接看案例：
背景：ERP系统原有内容模块用于商家内部流通管理，不同岗位可根据上任处理者的备注了解需要注意什么。
需求：ERP模块新增移动端，主要用于同步商家处理结果给消费者，且能将客服备注同步与买家，如何在现有的ERP处理界面适配新功能。
我个人对于这种需求的理解，首先没有考虑在原有页面增加新的买家备注功能。我最开始注意的是现有的备注模块，备注目前的使用场景是用于对内沟通，此处的考虑点主要就是能够控制什么时候对内什么时候对外。
所以我的思考方式是增加‘买家备注可见’选项，对内场景默认所有备注内容全部对内。这样我就能比较灵活的控制展现给买家的内容，且我认为展现给买家的备注，我内部同样需要。
demo如下：
这样的结合就比较完美的兼容新老功能的使用场景，类似这样的功能需求其实在很多场景下都是存在的。
好了，以上就是我认为对产品设计会有较大影响的因素，希望看完后能给你带来一点启发。
我是红尘，我们下期见！（公众号：都市摆渡人；关注查阅更多产品好文）
标签：因素,场景,功能,用户,产品设计,消息,影响,我们,备注 来源： https://blog.csdn.net/weixin_47619173/article/details/121782293
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。