“求助反馈”作为App基础功能之一常常被产品团队忽略其重要性，一个优秀的“求助反馈”设计不仅能解决用户在产品使用中遇到的问题，还能在产品迭代和风险排查中扮演重要角色。本文将讨论如何设计合适的“求助反馈”功能。

目录：

• 一、“求助反馈”为何能成为产品基础功能之一？
• 二、如何为自己的产品设计合适的“求助反馈”？
• 三、结语

一、“求助反馈”为何能成为产品基础功能之一？

“求助反馈”分为问题求助和意见反馈两部分，两者在产品当中都有其独特的作用，根据两者作用做了以下解答。

答：“问题求助”能减少用户与产品间不必要的误会。

许多工具类或是电商类产品，用户在使用过程中常会遇见功能使用障碍，操作流程不明晰等非技术性问题，有了“问题求助”的设计能减少用户与产品间不必要的误会，防止因用户操作不当产生“产品难用”的误解从而流失用户，也减少了同类问题反复咨询的情况发生。

答：“意见反馈”是产品团队和用户互动交流的重要桥梁。

任何一款产品终其一生8无非在做两件事情，一件是及时发现缺点并纠正它，另一件是发现成为更好的自己的途径并实践它。产品从1到N要想做到健康迭代，闭门造车显然不是一个明智的选择，所以“意见反馈”自然而然地成为了产品团队与用户互动交流的桥梁。你的冷暖我要知道。

谈到用户的冷暖，在“意见反馈”的信息当中往往是见冷不见暖，好在产品人有着被泼冷水仍笑着面对甚至摇鼓呐喊地喊着让暴风雨来得更猛烈些吧的优良品质（极度自虐仅代表个人观点），这才使得产品越变越好，越贴近用户的心窝。冷水大致分为以下3种：

1. 提BUG；例如“在X页面闪退”，这类反馈整理提供至开发和测试能帮助他们优化代码，也能够防止平台大面积崩溃的发生，达到早发现早治疗的目的。
2. 提需求；例如“我想要…”，当初淘宝也是一句我想要不出门就能逛街才诞生的（硬扯），所以用户主动提的需求是应该得到重视的，如何用产品思维将用户需求转化为产品需求这是后话了，这类意见反馈能够帮助产品进行迭代。
3. 无效信息；阳光照亮你的前路，同时会在你背后留下一道黑影，冷水不尽然是良药苦口的，许多不知所云甚至是瞎写一通的无效信息在一定程度上加大了运营成本，所以快速找出有效信息并整理分发至目标部门是评价一个意见反馈功能设计合理性的标准。

二、如何为自己的产品设计合适的“求助反馈”？

“求助反馈”的两个部分（问题求助&意见反馈）常常被设计在一起，因为通常情况下只有当用户遇见了“问题”后才会点击“求助反馈”试图获得解决，但是用户的“问题”很难被定义为是产品设计问题还是用户使用问题。所以两者像是相辅相成的关系，但两者的设计逻辑又不能够混为一谈，所以本文将分别讨论两点的设计逻辑且举出模范产品的设计。

1.问题求助

产品在不断更新迭代的过程中，由于功能的不断增删改，部分功能的操作流程并不会那么直接明了，所以常见问题的整理归纳显得十分重要，解决问题的同时也教育了用户如何正确使用产品。其中电商类产品常能遇到需要及时得到回复的问题，例如配送问题、交易纠纷等。所以还需要客服功能来解决。

example：

网易考拉海购结合自身产品特性对于“常见问题”和“在线客服”的设计十分值得借鉴，将电商产品常见问题进行了整理和归纳后分类，制成最高效的问题解答表。与此同时用“智能客服”、“在线客服”、“咨询电话”三类客服形式满足用户不同程度的需求。

总结：常见问题的整理虽然繁琐，但却是产品可用性的保障，在产品更新迭代当中也需要对常见问题进行定期审查修改完善，客服功能需要根据产品特性来设计，如果不是支付交易类产品，可适当减少客服的功能支持，减少运营成本。

2.意见反馈

一个完整的意见反馈模块分为两部分进行设计，即用户反馈意见给产品团队，产品回应用户的反馈意见，两者形成触发行为，提供反馈的体验闭环。

用户反馈意见给产品团队

• 实现设计功能需求前，先要明白用户需求和产品需求是什么。

用户只有在遇见了问题才会想到通过意见反馈来寻求帮助，所以用户需求为解决某问题；

产品方在得到海量反馈时，最希望获得哆啦A梦的神奇过滤机，筛选出有效且明确的问题或是需求，以便产品团队更好地做出反应，所以产品需求是快速且准确地了解问题所在或者需求是什么。

综合两点需求，意见反馈功能需要具有易用性、可筛选性和及时获得反馈三种特性。

• 接下来我们还需要根据自身产品特性判断用户可能遇见的问题类型。

例如工具型产品，用户在使用上大概率遇见功能使用方法的问题；社交型产品，用户可能会提出自己的一些需求而不是使用问题；电商类产品，往往会遇见售后、物流等求助类问题。

根据自身产品特性，归纳出高发反馈类型，是设计意见反馈功能很重要的一步。

• 最后一步是明确意见反馈现阶段目标是什么。

由于开发资源有限，“意见反馈”同整个产品一样无法做到一蹴而就，需要实现核心需求后跟着版本的迭代添砖加瓦，成为综合性的“意见反馈”。所以需要根据产品现阶段核心需求来设计“意见反馈”。

意见反馈阶段性的核心需求一般分为以下几类：

1.BUG排查：处于早期产品，由于没有经过大批量测试，代码鲁棒性仍然不能由测试来保障，所以意见反馈能帮助产品团队快速排查BUG，及时修复。

example：

微信“意见反馈”中的BUG排查，筛选出高发常见BUG并整理成树状的故障引导表，方便用户快速的表达并提交BUG，也减少了产品运营成本。

2.需求收集：用户需求能够影响到产品迭代内容，意见反馈中关于用户提交的需求可放入需求池当中，是产品需求的重要来源之一。

example：

网易云音乐采用表单式的意见反馈设计，让用户有较高的自由度去描述自身需求，但这无疑增加了不少的运营成本，后台对于无效信息的自动过滤十分重要，建议设计表单式意见反馈时要求一定的最小字数，这样设计可在用户这一环就减少了许多无效信息。

产品回应用户的反馈意见

本文将介绍三种类型用户得到反馈的方式

1.toast或页面提示“提交成功”

用户点击提交意见反馈之后，常见设计为toast提示“提交成功”且跳转回某页面，或是像微信一样页面提示“提交成功”点击确定后跳转回某页面，两者区别在于用户对于自己-提交意见反馈成功-这个信息的接收度，很显然页面提示更能保证用户确信自己已成功提交意见反馈，当然toast提示并非不可取，只是需要确保toast提示时长足够长，且跳转回的页面需在意见反馈功能模块内，较少用户对产品的失控感。（网易云音乐V4.2.0 意见反馈toast提示时间短，且跳出意见反馈功功能模块，体验欠佳）

2.历史反馈

类阿里智能中提供历史反馈的设计既确保用户确信自己的反馈已成功提交，还能在后续产品与用户进一步交流提供了途径，缺点在于历史反馈给予用户对于得到回复有了更高的期望值，若长时间未得到回复，用户将有更大失落感，所谓希望越大失望越大，所以这个设计的选择应权衡利弊。

3.留言评论式

新浪微博中对于意见反馈的设计较为特别，都采用了评论留言式的设计，亮点在于用户能够浏览其他用户的反馈，以及产品和用户间的互动，更有社区感。但该设计适合用户量较小的社区型产品，否则将适得其反，例如新浪微博的意见反馈常被人诟病。

总结：意见反馈的设计并不能一股脑的从其他优秀产品上照搬，因根据自身产品的调性，用户群的特性，开发资源的可调控性阶段性地去进行设计，参照以上列举的设计结合自身产品一定能合理规划出适合的意见反馈。

三、结语

求助反馈虽不是核心功能，但和登录注册一样是产品的基础功能不可或缺，在人力资源足够的条件下因不断完善求助反馈的功能模块，达到减少不必要的用户流失、风险监控以及辅助更新迭代的效果。

本文由 @石力.Lison 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自PEXELS，基于CC0协议