APP帮助模块设计-详细分析

1. APP帮助模块设计-详细分析

 【帮助】模块和我之前讲到的注册、登录、支付模块有着明显的差异，从产品需要与否的层面来看的话。注册、登录、支付模块对于不同属性的产品来说有着强弱不同的存在度，甚至有些产品不需要这些模块，用户仍然可以无障碍使用，且无抱怨，例如计算器、手电筒等工具类软件。但是【帮助】模块就不同了，它对于任何一款产品来说都是必备的，不随产品属性、产品形态、所处行业等的变化而变化。
   从事产品或交互或视觉的同学应该都知道尼尔森的十项交互基本原则（之后会和大家一同深入分析思考“十项基本交互原则”的意义和现在是否还适用等有趣问题），其中一条原则便为：人性化帮助原则。从字面上的意思理解，很容易理解为做产品时我们要给用户帮助。那该怎么给用户帮助呢？帮助该以何种形式交付给用户呢？''对，帮助中心功能，在产品中增加多个明显入口让用户在需要帮助时就能找到入口，进入帮助中心功能，找到解决方案，从而解决问题。'' 以上，是大多数产品新人在未深入思考和经验积累的情况下出现的惯性理解，也就是对于“帮助”认知的第一个误区：  帮助=帮助中心  。
   我们经常在网络上或工作中看到或听到某某产品、某某研发和某某领导在看到产品方案中有关于帮助用户的内容设计时，都会一本正经的说：''我觉得不该给用户这些帮助，真正优秀的产品是不需要帮助的，而是用户拿来就会使用的，所以方案的这部分还是要重新修改….。'' 这便是对于帮助认知的第二个误区：  优秀产品不需要帮助  。（误区二更像是一种固化思维，从业者被大量此类的内容信息反复灌输，最终造成了洗脑的效果，形成固化思维，像极了脑白金的广告，真的很佩服洗脑者的这种****能力。）
   首先对于误区一 帮助=帮助中心 ，我们通过对帮助组成类型进行了解，就很容易避免。   我们在产品设计中使用到的帮助可以分为以下四种类型：
                                                                                                                           在第一部分我们知晓了产品设计中“帮助”的四种类型。之后我们就能根据自身产品属性的不同，来选择不同的“帮助”组合方案来解决问题。   例如TOB产品和TOC产品中，四种类别的占比就不尽相同。对于TOB类产品而言，由于：
   而对于TOC产品就完全不同了，由于C端产品几乎在各个赛道上都有大批竞品，且各竞品产品基本都是相同的、标准化的。这就导致产品无法从功能层面去向其他竞品争夺用户，也就是可替换度高。这时提升产品用户体验就变成了抢用户的重要因素之一，所以活得好的C端产品在细节上的体验往往做得都很不错。再加上C端产品的商业模式不像B端产品那样先付钱再使用，所以C端用户有很大的自由度，不喜欢你这款产品可以立刻去使用其他产品。所以TOC产品中“无需帮助”“一次性帮助”“场景化帮助”“帮助文档”都是需要的，只是权重的大小不同而已。
   现在我们明白了为什么很多C端产品经理接触到B端产品时，总是会投出鄙视的眼光和嘲讽：‘这设计的是什么垃圾。这么难用，谁会用这东西’的原因，其本质是两者服务的对象不同而已，再直白的说就是付钱的对象不同而已。从而导致产品设计的侧重点就不相同了。   当然，产品除了TOB或TOC的不同外，还有像是硬件产品或软件产品的不同等等，不同属性的产品在“帮助”类型的选择和搭配上都是以相同的，千万不要一个组合套到所有产品上。
   最后将APP中“帮助中心”的组成梳理下：
   以上，在产品设计中“帮助”模块的总结思考及理解。

2. 【产品】移动端APP常见架构与设计

通过点击底部Tab标签切换不同页面，可以说是如今众多APP的标配了。
  
 典型的如：微信，微信底部4个Tab分别是微信、通讯录、发现、我，更新迭代这么多年，一直很稳定，即使增加了很多功能，但微信的整体架构依然很简洁、稳定，佩服龙哥。
  
 一般底部Tab标签为2-5个，超过5个通常会折叠。个人感觉过多的Tab标签会影响用户对APP主要功能模块的认知。
                                                                                  
 有些Tab标签对应的页面有不同类型的内容，此时可在页面上方同时设置顶部文字标签，使该Tab标签下的内容能够更清晰、有条理的分类。
  
 如：抖音首页底部Tab标签上方有关注、推荐两个文字标签。
                                                                                  
 底部Tab的形式适用于APP有多个主要功能模块，每个模块可单独成页。
  
 而有些APP核心功能很突出，且各个功能模块均依附于该核心功能；或是核心功能非常重要，其他功能相对弱一些。这样可能不太适合以底部Tab形式设计APP。
  
 对于核心功能很突出、且各个功能模块均依附于该核心功能的情况，可以考虑用卡片形式，如：faceU，它的核心功能是打开摄像头拍照，主要功能有贴纸、滤镜等，这些主要功能是依附于拍照这个核心功能的，因此比较适合卡片形式的架构。
  
 对于核心功能非常重要、其他功能相对弱一些的情况，可以考虑打开APP后，开门见山直接显示核心功能，其他功能隐藏在次级页面，如：滴滴，打开APP后直接进入打车页面，凸显核心功能，其他功能如：订单、客服、消息等，均折叠隐藏在次级页面。
                                          
 列表布局即通过一行行列表的形式展示每项内容。这种方式扩展性好，可上下滑动展示更多内容，适用于并列、平行内容的展示。
  
 常见的如设置页面：以列表形式展现每项可设置功能，右侧显示“>”，表示有更多操作；或者右侧直接显示开关按钮、默认选项等。常见的列表布局还有对话列表、歌曲播放列表等等。
  
 同时如果展示内容有分类，则可以通过增加行间距的方式，将不同类别的内容聚合在一起。
                                          
 宫格布局即以宫格平铺的方式呈现各个功能入口，这种方式使用户能够直观、清晰看到各个功能入口，比较适合提供服务/功能较多，且各服务/功能相对独立的APP。
  
 每个宫格区域一般是以图标+标题的方式展示，标题不易过长。
  
 如：支付宝以宫格展示各项应用入口，微信以宫格展示可提供的第三方服务入口。
                                          
 以瀑布流方式展示图文内容，所展示内容错落有致，可通过滑动的方式查看更多内容，沉浸感、流畅感好。
  
 常见的如：旅游类APP，图文信息比较多且更新频繁的APP。
                                          
 抽屉式菜单，即点击导航按钮，将二级菜单像拉抽屉一样拉出来。
  
 这种形式能极大程度保持页面简洁，节省空间，但由于功能隐藏在子菜单中，比较适合不太重要的功能。
  
 常见的如：个人中心、设置等，会比较多的隐藏于抽屉式二级菜单中。
                                          
 手风琴菜单表现形式为，通过点击一级菜单按钮，能够实现在子菜单展示与收回之间的来回切换。
  
 常见的如：QQ好友分组列表，相信大家都不陌生了。
  
 这种形式的菜单能够在保持界面简洁的情况下，实现信息扩展，比较适用于两级结构的分组信息展示。