APP帮助模块设计-详细分析
智能手机已经成为人类不可分割的器官，人们在线上处理生活的方方面面的习惯已经形成，APP作为线上渠道最
主要的方式之一，已被各行各业广泛使用。这里将持续的和大家一同谈论关于APP产品设计的各模块、细节的设
计方式及思考
【帮助】模块和我之前讲到的注册、登录、支付模块有着明显的差异，从产品需要与否的层面来看的话。注册、登录、支付模块对于不同属性的产品来说有着强弱不同的存在度，甚至有些产品不需要这些模块，用户仍然可以无障碍使用，且无抱怨，例如计算器、手电筒等工具类软件。但是【帮助】模块就不同了，它对于任何一款产品来说都是必备的，不随产品属性、产品形态、所处行业等的变化而变化。
一、关于帮助的常见认知误区
从事产品或交互或视觉的同学应该都知道尼尔森的十项交互基本原则（之后会和大家一同深入分析思考“十项基本交互原则”的意义和现在是否还适用等有趣问题），其中一条原则便为：人性化帮助原则。从字面上的意思理解，很容易理解为做产品时我们要给用户帮助。那该怎么给用户帮助呢？帮助该以何种形式交付给用户呢？''对，帮助中心功能，在产品中增加多个明显入口让用户在需要帮助时就能找到入口，进入帮助中心功能，找到解决方案，从而解决问题。'' 以上，是大多数产品新人在未深入思考和经验积累的情况下出现的惯性理解，也就是对于“帮助”认知的第一个误区：帮助=帮助中心。
我们经常在网络上或工作中看到或听到某某产品、某某研发和某某领导在看到产品方案中有关于帮助用户的内容设计时，都会一本正经的说：''我觉得不该给用户这些帮助，真正优秀的产品是不需要帮助的，而是用户拿来就会使用的，所以方案的这部分还是要重新修改….。'' 这便是对于帮助认知的第二个误区：优秀产品不需要帮助。（误区二更像是一种固化思维，从业者被大量此类的内容信息反复灌输，最终造成了洗脑的效果，形成固化思维，像极了脑白金的广告，真的很佩服洗脑者的这种****能力。）
首先对于误区一帮助=帮助中心，我们通过对帮助组成类型进行了解，就很容易避免。
我们在产品设计中使用到的帮助可以分为以下四种类型：
- 帮助文档
该类型的帮助应该是我们感知最明显的类型了。一般稍微复杂些的产品都会附上帮助文档，软件产品中一般是以【帮助中心】功能的形式交付给用户使用、硬件产品一般都是会以纸质说明书或电子说明书的形式交付给用户使用。不管是哪种形式都是将整个产品中操作说明或用户常见问题集合在一起，供用户使用。现在的用户也已经形成了在使用产品时遇到问题去找帮助文档的习惯了。所以除非是产品极其简单、完全没有学习门槛以外帮助文档是必备的。属于有是应该，无则严重降低用户体验的环节。
示例
- 场景化帮助
该类型的帮助，是根据用户当时的具体场景给予用户主动的或被动的帮助。例如淘宝双十一每年都会有很多的优惠活动，这些活动都会附着对应的帮助说明，一是帮助用户在需要时可以知道活动流程，二是帮助活动方约定活动条件。这种用户在特定的场景下会出现并需要用户自行点击查看的帮助，我们称之为主动型场景化帮助。再例如当用户浏览王者荣耀商城时，看到了充值即送英雄的活动，用户一看可以，感觉这波不亏，很赚，就点击充值了，一顿操作后，王者荣耀APP弹出弹窗：您已成功购买xxxx点券。这时用户就知道已经充值成功了，接着用户去查看送的英雄…。以上这种场景，用户在完成某个操作后系统出现的反馈提示，我们称之为被动型场景化帮助。同样，场景化帮助也符合有是应该，无则严重降低用户体验甚至会造成其他纠纷的环节特性。
示例
- 一次性帮助
该类型的帮助生活最常见形式的是当产品有新功能调整更新时，用户第一次触达该页面，软件会出现该模块介绍的说明页，帮助用户对该模块做个大致的了解或是对该模块的排版调整等问题进行描述的告知行为。这种说明页通常为一次性帮助，用户查看过后就再也没有其他入口找到了。一次性帮助属于锦上添花的设计，能让产品的用户体验更较友好。
示例
- 无需帮助
该类型的帮助毫无疑问是四种帮助类型中使用最广泛的一种。该类型的帮助强调的是不要对用户造成无用的干扰，和那句“有一种爱，叫做放手”有异曲同工之妙。我们通过对产品在不同场景下可能发生的情况进行逐条思考判断，以最少的干扰给与用户最有效的帮助。
二、“帮助”在不同形态的产品中该以何种组合出现
在第一部分我们知晓了产品设计中“帮助”的四种类型。之后我们就能根据自身产品属性的不同，来选择不同的“帮助”组合方案来解决问题。
例如TOB产品和TOC产品中，四种类别的占比就不尽相同。对于TOB类产品而言，由于：
- a.先付钱后交付产品及服务的商业模式（绝大多数TOB来产品都是这种模式）
- b.定制化需求多，流程和功能不统一且复杂
- c.产品体量大，角色众多，甚至涉及到权限等问题，导致产品及其复杂
- b.往往产品实际付钱者和产品提供方都有着希望产品能真正为B带来益处的统一目标
- 和客户公司关系好
等原因，使得B端企业会对产品功能是否能实现更加看重，而对实现功能后所展现的易用程度、视觉体验、交互体验有较高的容忍度。并且B端产品的结构较为复杂，使用者无法快速自学。所以我们就知道了对于TOB产品来说帮助文档类型的帮助是必备的，而其他的“无需帮助”“一次性帮助”“场景化帮助”这三类帮助类型即使产品中没有涉及，也不影响产品功能的实现，虽然会降低用户的使用体验感，但是毕竟已经付了钱，再难用也只能吐槽吐槽接着用。
而对于TOC产品就完全不同了，由于C端产品几乎在各个赛道上都有大批竞品，且各竞品产品基本都是相同的、标准化的。这就导致产品无法从功能层面去向其他竞品争夺用户，也就是可替换度高。这时提升产品用户体验就变成了抢用户的重要因素之一，所以活得好的C端产品在细节上的体验往往做得都很不错。再加上C端产品的商业模式不像B端产品那样先付钱再使用，所以C端用户有很大的自由度，不喜欢你这款产品可以立刻去使用其他产品。所以TOC产品中“无需帮助”“一次性帮助”“场景化帮助”“帮助文档”都是需要的，只是权重的大小不同而已。
现在我们明白了为什么很多C端产品经理接触到B端产品时，总是会投出鄙视的眼光和嘲讽：‘这设计的是什么垃圾。这么难用，谁会用这东西’的原因，其本质是两者服务的对象不同而已，再直白的说就是付钱的对象不同而已。从而导致产品设计的侧重点就不相同了。
当然，产品除了TOB或TOC的不同外，还有像是硬件产品或软件产品的不同等等，不同属性的产品在“帮助”类型的选择和搭配上都是以相同的，千万不要一个组合套到所有产品上。
三、帮助中心的组成
最后将APP中“帮助中心”的组成梳理下：
- a.产品功能介绍
及产品说明书，对产品各模块各功能进行流程化的详细描述。最好呈现显示为视频+图片+文字。
- b.常见QA
这里汇集用户出现频率最高的问题和解决方案。QA是不断更新的，频率高的问题要尽可能通过产品设计来消除掉，新发现且没有解决方案的问题要及时更新至QA中
- c.建议反馈
让用户发声的口子，也是获取帮助中心迭代需求的口子之一
- d.下载
用户的记忆力没有想象中那么好，给他们一个可下载的帮助中心，对照着操作解决问题，要比让他们来回切页面好的多得多
- e.人工客服
马路上有路怒症，产品中同样也有，某些用户没有找到问题的解决方案加上性子急脾气大，顿时就有火了。火大伤身啊，导致产品体验变差的风险急剧上升，这在我们产品中可是不允许发生的。所以我们给个人工客服，让他们有地方消消气，顺便解决问题，收集QA迭代需求，还能帮助其他用户，很棒
- f.搜索
搜索功能还是极其游泳的，尤其是在帮助中心内容杂多的时候。也是提现帮助中心体验优劣的重要指标之一。易用的搜索增加效率、提升体验，反之会引来无尽吐槽
以上，在产品设计中“帮助”模块的总结思考及理解。
随着时间的推移，新的设计理念和交互形式会不断迭代更新，也就需要我们自身也不断升级迭代。
tips:文章中使用的图片来源于网络，如涉及侵权请及时告知，将修改!
