android app 详细设计文档怎么写

一、明确APP的发展战略要做一款app，首先要明确几个问题：1.app的用户是谁?2.用户使用app能够获得什么?3.公司推出app是为了获得什么?以上问题，这里不做回答，只是一个粗狂的问题，对于APP的设计并无实际指导意义，只是暂且明确了一个产品的方向。二、产品的核心功能有哪些?不同的产品其核心功能大相径庭，这里以电商APP为例，从前端和后台两个方面具体说明电商APP的核心功能需求有哪些?用户端APP(Android、ios版本)，这里只是主要功能，在主要功能的基础之上可以增加一些完善体验的东西。主要功能：浏览商品(列表页、详细页)、分类查看商品、加入收藏、加入购物车、直接购买、提交订单、支付订单、支付，订单列表页、订单详情页，订单可进行 的操作(取消、支付、确认收货、评价、申请退换货、删除)查看商品物流信息，还有个人信息(昵称、头像、收货信息、订单、余额、积分等等)，以及关于 APP端的版本查看，意见反馈，清除缓存，关于我们，用户注册、登陆和用书使用协议等。APP需要的后台系统搭建，根据不同的电商模式，其后台架构也不同，垂直电商和电商平台有很大的差别，主要看商家端是全部自己来进行管理还是开发加盟的方 式，如淘宝的后台架构和唯品会的后台架构就是两种不同的后台架构。主要架构：账户架构(用户、商家、运营、财务、仓储物流)，功能架构，用户的前端展示的 功能需要后台给出相应字段，数据接口。商家端需要发布商品、接单、操作发货、填写物流信息，处理退换货，这些信息同步到用户前端，用户可以随时查看订单的 状态。需要给运营相应的操作权限，商品的排序，BANNER广告，专题页链接，在后台的上传方式和前端的展示位置等等，还有数据分析，不同的商品的销售统 计，订单发生的时间、地点、用户数据等参数进行统计，财务进行相关订单的财务结算，按照商家、用户、订单进行结算，如果能够把控整个数据库安全的情况下也 可以自动结算，仓储物流信息的上传和同步，如果是1小时送这种O2O模式，还要有配送人员的接单、取货等数据同步。三、详细进行竞品分析确定了以上的核心功能和需要打磨的细节之外，接下来就是进行细致的竞品分析，这里仍然以电商为例进行竞品分析，竞品分析的工作如何开展呢，这里叙述一下自己的观点。找到直接或者间接的竞品，大概找5款app左右，下载安卓和IOS端分别使用，使用脑图软件列出核心功能和提高体验的功能，使用axure等原型工具对其产品截图进行纵向和横向分析，包括UI风格、色彩和图标、文字、按钮的颜色、大小、位置等等。从网上调研相关数据分析竞品为什么这样设计，这样设计的好与不好的地方分别说明根据以上数据列出表格，进行筛选，提炼精华部分，去除糟粕部分，给自己的产品设计提供必要的参考。提出自己的产品差异化功能和特色，电商产品必须结合运营部门进行品类的分析，货源、价格、物流服务等进行分析，单个从APP产品进行优化体验，就算做出花来也没用，因为用户需要的不是产品，而是商品。从前端展示分析出来其后台架构和相关功能的布局，这个需要观察细节，注重思维能力。比如，你去操作一个款产品，购买数量填写10万个，看下是否有提示库存不足就知道其后台有没有对库存进行把控。四、真正地开始制作APP开发需求文档 app开发需求文档的标准写法：1.app开发目的，阐明开发本软件的目的；2.代开发的app名称3.参考资料（可有可无）列举app开发需求规格说明时所参考的资料，包括项目经核准的计划任务书、合同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档，以及相关产品的软件需求规格说明。 在这里应该给出详细的信息，包括标题、作者、版本号、发表日期、出版单位或资料来源。4.app开发的功能需求。5.app的运行环境，包括硬件平台、硬件要求、操作系统和版本，以及其他的软件或与其共存的应用程序等。6.条件与限制，给出影响开发人员在设计app时的约束条款，例如：必须使用或避免使用的特定技术、工具、编程语言和数据库。7.app功能划分，列举出所开发的软件能实现的全部功能，可采用文字、图表或数学公式等多种方法进行描述。8.功能描述，对各个功能进行详细的描述。9.外部接口需求。10.用户界面，对用户希望该软件所具有的界面特征进行描述。11.性能需求，包括数据精确度、响应时间、数据转换与传输时间、运行时间等。12.其他需求，如果不需要增加其他需求，可省略这一部分。五、交付设计和文案确定好以上的需求之后，面对设计和研发的需求文档已经告一段落，接下来就要在UI做设计、交互设计师做交互的时候，找相关部门人员完善文案需求，和项目经理一起对工作进行细分，确认时间节点，最后由交互设计师输出一套高保证原型。六、交付研发这样子做出来的高保证原型，在各个细节都已经做到了完善，设计、交互、研发、运营等等对工作也已经胸有成竹，那么大家就可以坐下来好好开个简短的会议，确认每个人的具体工作，给出相应的时间节点，然后随时跟进开发需求就可以了。

面向对象软件设计说明书模板 1 概述 1.1 系统简述 对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。 1.2 软件设计目标 这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。 这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。 1.3 参考资料 列出本文档中所引用的参考资料。（至少要引用需求规格说明书） 1.4 修订版本记录 列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。 2 术语表 对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。 3 用例 此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。 4 设计概述 4.1 简述 这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose） 4.2 系统结构设计 这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。 4.2.1 顶层系统结构 4.2.2 子系统1结构 4.2.3 子系统2结构 4.3 系统界面 各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。 4.4 约束和假定 描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。 另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。 实现的语言和平台也会对系统有约束，同样在此予以说明。 对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。 5 对象模型 5.1 系统对象模型 提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。 对象图应该包含什么呢？ 在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。 所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。 可能经过多次反复之后才能得到系统的正确的对象模型。 6 对象描述 在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。 为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。 对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。 对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。 6.1 子系统1中的对象 6.1.1 对象：对象1 用途： 约束： 持久性： 6.1.1.1 属性描述： 1. 属性：属性1 类型： 描述： 约束： 2. 属性：属性2 6.1.1.2 方法描述： 1. 方法：方法1 返回类型： 参数： 返回值： Pre-Condition： Post-Condition： 读取/修改的属性： 调用的方法： 处理逻辑： 测试例：用什么参数调用该方法，期望的输出是什么…… 7 动态模型 这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。 确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。 7.1 场景（Scenarios） 对每个场景做一则条目，包括以下内容： 场景名：给它一个可以望文生义的名字 场景描述：简要叙述场景是干什么的以及发生的动作的顺序。 顺序图：描述各种事件及事件发生的相对时间顺序。 7.1.1 场景：场景1 描述： 动作1 动作2 7.2 状态图 这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。 7.2.1 状态图1： 8 非功能性需求 在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。 9 辅助文档 提供能帮助理解设计的相应文档。 10 词汇索引 文章录入

这是《App产品设计指南》系列文章的 第7篇 内容，更多精彩可以点击下方链接查看。

《App产品设计指南》专栏目录

经过前面几篇内容预热，相信大家已经对App产品的设计理念，研发流程有了一定的认知。接下来我们来正式切入正题，一起来学习关于App产品设计的具体知识点。需要说明的是，后续的文章为了让大家更直观地理解，语言上会比较直白。文章之外的很多细节，比如说B站的情感化设计，微信克制的初心，这些都需要大家主动思考和发散才能深刻的理解。

在本文中我会重点介绍一下App产品的通用模块。在产品初期一定要设计好产品的通用模块，这些模块会伴随着产品的一生。如果没有设计好，后续迭代多半会踩坑填坑。我目前在用的机器是小米9，所以后面会出现较多的安卓系统的案例。

经常会在App中看到转圈加载的交互，这个就属于全局加载。在数据没有获取到之前显示加载中的特效；数据请求后再渲染页面，这样的交互能让用户不至于焦虑。下面介绍几种常见的设计：

（1）App页面中显示loading图标，增加文案引导。由于一般是圆圈加载，速成菊花图。

（2）App页面中显示由矩形、圆形等图案组合的轮廓效果。这种效果有一个学名叫做骨架屏。

需要说明的是骨架屏最好根据页面内容来显示轮廓效果，如果使用相同的设计效果就会不太理想。

（3）webview页面中在页面顶部显示进度条，表示对应的加载进度。

全局加载需要设置一个数据请求上限，比如说10S。如果达到上限还没有请求到数据，就要显示对应的失败提示，下文中会提到这种场景。

在列表页面中经常会出现没有数据的情况，我们要明确的告诉这是什么，为什么出现，用户要做什么。在实际情况中，上面3种处理会组合出现。

不同页面的内容都不一样，所以空白页最好能根据页面的内容来进行设计

用户进入新页面时，本地判断网络情况。如果网络异常则显示该状态，一般都会增加“重新加载”“点击刷新”“查看网络设置”这种操作提示。

类似微信钉钉等使用长连接机制的App，如果网络中断，页面顶部会显示网络异常提示。

网络异常属于可以实时判断的情况，进入页面时就能立刻判断。

这种情况一般发生在服务器出问题的时候，相当于网页上的404状态。比如说连接人数特别多，或者服务器宕机，此时就会触发该状态。

上面说的错误提示需要客户端请求数据一段时间（比如说10S）之后才会触发。一般包括整个页面出错，部分内容出错两种场景。前者需要有对应的页面设计，后者一般使用toast这种轻度的设计。

上拉加载

如果数据量比较少，可以一次性加载完；而数据量较多时，就需要分页加载。比如先加载20条数据，然后再继续加载。

（1）触发上拉加载分为2种情况，一种是用户看完当前页向上滑动时再加载数据；另外一种是预加载，即用户还在浏览当前数据，程序在后台自动加载数据。比如抖音App，你在浏览视频时，系统会自动加载后面几个视频。

（2）数据全局加载完，显示触底提示，文案如“没有更多数据了”“我可是有底线的”。

（3）如果上拉加载数据失败，在底部显示加载失败并显示“重试”按钮。这种场景也可以不予考虑。

下拉刷新

用户在页面顶端主动进行下拉操作，当前页面数据进行刷新。如果有其他页面的数据或者配置发生变化，也可以同步更新。下拉刷新一般分为以下4个步骤：

（1）用户向下拉动时提示用户在进行刷新操作；

（2）用户下拉是有区域范围的，一般在屏幕的1/3处左右。当下拉达到这个区域时，提示用户此时松开可以刷新数据。

（3）显示刷新中的交互效果；

（4）提示用户刷新成功，可以把刷新成功的数字显示出来。如果挤在失败则toast刷新失败。

在写作过程中，如果有意见或者想法，欢迎有兴趣的读者添加我的微信一起交流探索，共同进步。

如今的时代，几乎人人都拥有一款智能手机，随之而来的是手机APP的需求量大大增加，因此手机APP开发的发展也越来越迅速，一些企业和商家早已经看准手机APP开发的优势，打造了专属的手机APP，以此增加知名度并获得利益。如果我们想要开发一款专属的手机APP的话，我们一定要先对手机APP开发的市场进行分析，选择性价比更高，更靠谱的方式进行开发。下面上海银行网络小编为大家分享一下APP定制开发的过程步骤。

第一步：需求分析

在确定进行APP开发之前，客户要先对产品进行一个详细的需求分析，然后根据具体需求做出需求文档，方便与开发公司进行沟通交流，确保开发公司可以更加方便快捷地了解到客户的需求并进行开发。

第二步：原型设计

开发公司与客户进行详细的沟通交流之后，要先由开发公司的项目经理做出APP的原型设计，然后通过双方的沟通交流，做出双方满意的原型设计，由双方进行确定之后才可以进行下阶段的开发。

第三步：UI设计

UI设计便是UI设计师对APP的用户界面进行设计，用户打开APP首先看到的便是APP的用户界面，只有简洁美观的用户界面才可以给用户带来更高的体验度，吸引用户对APP进行深度使用。用户界面是用户与APP进行交互的地方，所以用户界面的UI设计是极为重要的，需要有一定的创意和审美。

第四步：代码开发

代码开发是APP的正式开发阶段，通过UI设计的效果展示图，开发工程师通过代买进行原生开发，实现前期的所有功能设计。开发内容可能包括架构设计、数据库设计、业务功能实现及接口封装、管理后台的开发等。

第五步：产品测试

在代码开发完成后，就要开始进行产品上线前的测试阶段了，这个阶段是发现产品bug的过程，需要进行一遍一遍的测试，直到确保产品可以正常运行，且没有bug存在，便可以进行产品上线了。

第六步：交付验收

APP开发测试上线后，需要由开发公司交付给甲方，完整的交付清单包括：需求规格说明书、设计规范说明书、接口设计说明书、数据库设计说明书、测试用例、测试大纲、源代码、详细设计说明书等，保证产品交付的满意度。

一款好的APP开发是一定包含以上六点的，大家在寻找开发公司时可参考以上六点与该公司的流程进行对比，并在每一步都进行细致的沟通，从而达到自己预期的效果。

在APP产品的设计过程中，登录功能看似简单无奇，但其实会跟进产品业务、功能关联、用户体验紧密联系，也就需要产品经理花大量的时间去思考，思考如何设计出更高质量的登录环节

在准备进行登录模块设计前，我们首相要考虑清楚自身产品是否真正的需要登录模块，例如手电筒、计算器、录音机等纯工具类的产品其实是不需要拥有登录模块。所以在设计前，我们可以从用户角度、业务角度、产品功能角度三个角度进行思考和分析：

1. 功能角度

1）整个产品是基于登录为前提进行设计的，如果不登录，整个产品将无法使用。例如即时通讯的产品是必须基于用户已登录的前提下进行的、王者荣耀必须基于用户已登录的前提下进行的等

2）产品中有较多功能和用户身份挂钩，不知道用户身份便无法开展服务。例如如果想看爱奇艺的会员电影，你只有登录了具有会员标示的账户才能看，否则就只能看免费内容

2. 用户角度

1）用户需要和其他用户产生联系，需要登录才能满足。例如关注、交流、点赞、打赏等

2）用户需要很多登录后才能使用的功能和服务。例如电商产品、即时通讯产品等（很多产品的设计就是站在这个角度设计出很多很棒的功能，但是只有用户登录后才能使用，也就是变相的促使用户注册登录的一种方法）

3. 业务角度

1）产品需要搭建 用户体系

2）企业需要收集到用户的关键信息。例如手机号、身份证号、姓名等，为二次触达用户提供渠道。例如：通过收集到的手机号/邮箱，企业可以通过这些渠道再次触达到用户，进行运营

3）企业需要收集用户的使用数据，进行数据分析，为产品运营做支持。

4）出于法律规定或安全性考虑，企业需要知道用户信息

以上，我们在进行登录设计前要考量自身产品是否满足以上的三个角度的要求，如果不满足则无需登录模块，反之则需要。这三点是有严格的顺序关系的，只有产品功能上有登录的需要，才会激发出用户登录的需求，最后我们才能达到业务上的目的，这是一个严格的递进关系。所以说如果我们想达到某些业务角度的需要，从产品功能上找办法就相对容易。

确定产品需要登录模块之后，我们接着需要思考登录模块的设计原则，即登录模块该设计什么样子。同样我们也从三个角度来思考分析：

1.用户角度

1）用户在登录需求产生后，需要立刻释放需求，如果不释放或释放时间过长将导致用户体验降低甚至失去客户。故我们需要满足用户能够快速释放需求的愿望

2）用户习惯的登录方式为手机号登录、账号登录、邮箱登录、第三方快捷登录、手机验证码快捷登录、指纹快捷登录。每一种登录方式面向不对需求的用户：

2.业务角度

对于企业来说都是希望能获得用户的数据的，尤其是像手机号这种关键数据，越快获得越好。

3.安全性角度

1）用户安全：因为用户会在产品中留下自己的言论或内容等信息，这些信息的安全就需要一定保护，不能说随便什么人知道一个手机号后通过无限试密码的手段就可登录他人账号，故我们需要提供一定安全保护措施。例如密码连续错误5次冻结一段时间等

2）企业利益安全：某些无良的竞品会采用机器人的方式，循环获取手机验证码，增加信息成本，这其实就是对企业利益的损害。故我们需要提供一定的保护措施避免企业利益受损。例如验证码每60s才允许再次发送的设置等

以上，通过分析我们可总结出登录模块的设计原则（一句话）： 提供安全、快速、多方式的登录模块设计

下图截取了四个App Store免费榜前几名的登录页：

通多对大量已有产品的汇总和思考，可将登录模块包含的元素进行梳理归纳，如下：

确定了登录模块的元素构成后，我们就需要把登录模块中涉及到的所有流程逻辑全部梳理且整合起来

1. 登录方式

1）账号密码登录

2）免密码登录/短信登录

3）第三方登录

4）指纹登录

2. 服务协议和隐私协议

3. 忘记密码/找回密码

关于返回上一页/关闭的流程逻辑，把握好返回前后的页面选择，不造成用户认知前后不匹配即可，这里就不再赘述了。

（模块中的各元素流程逻辑会依据不同的实际因素形成不同的设计流程，不可能被标准化，我以上的流程逻辑不适用所有产品）

将各元素的流程逻辑梳理清楚后，再将其整合在一起后，我们就可以基本得到登录模块整体的逻辑骨架了。随后即可完善线框图等后续工作

登录模块所包含的元素很多，也就为体验的升级提供了更多的空间和想象。满足登录功能的前提下提升用户的体验也是必不可少的， 能用 的功能和 好用 的功能区别很是非常之大的。针对登录模块各组成元素会有一些细节设计来提升用户体验：

在任何模块的设计中时间和成本是产品经理必定要考虑的事情

通过对模块的 被需要程度、设计原则、组成元素、模块逻辑、设计细节 几方面的思考和分析，再结合产品的 时间、成本 等实际情况，尽可能设计更优质的登录模块

【帮助】模块和我之前讲到的注册、登录、支付模块有着明显的差异，从产品需要与否的层面来看的话。注册、登录、支付模块对于不同属性的产品来说有着强弱不同的存在度，甚至有些产品不需要这些模块，用户仍然可以无障碍使用，且无抱怨，例如计算器、手电筒等工具类软件。但是【帮助】模块就不同了，它对于任何一款产品来说都是必备的，不随产品属性、产品形态、所处行业等的变化而变化。

从事产品或交互或视觉的同学应该都知道尼尔森的十项交互基本原则（之后会和大家一同深入分析思考“十项基本交互原则”的意义和现在是否还适用等有趣问题），其中一条原则便为：人性化帮助原则。从字面上的意思理解，很容易理解为做产品时我们要给用户帮助。那该怎么给用户帮助呢？帮助该以何种形式交付给用户呢？''对，帮助中心功能，在产品中增加多个明显入口让用户在需要帮助时就能找到入口，进入帮助中心功能，找到解决方案，从而解决问题。'' 以上，是大多数产品新人在未深入思考和经验积累的情况下出现的惯性理解，也就是对于“帮助”认知的第一个误区： 帮助=帮助中心 。

我们经常在网络上或工作中看到或听到某某产品、某某研发和某某领导在看到产品方案中有关于帮助用户的内容设计时，都会一本正经的说：''我觉得不该给用户这些帮助，真正优秀的产品是不需要帮助的，而是用户拿来就会使用的，所以方案的这部分还是要重新修改….。'' 这便是对于帮助认知的第二个误区： 优秀产品不需要帮助 。（误区二更像是一种固化思维，从业者被大量此类的内容信息反复灌输，最终造成了洗脑的效果，形成固化思维，像极了脑白金的广告，真的很佩服洗脑者的这种****能力。）

首先对于误区一 帮助=帮助中心 ，我们通过对帮助组成类型进行了解，就很容易避免。

我们在产品设计中使用到的帮助可以分为以下四种类型：

在第一部分我们知晓了产品设计中“帮助”的四种类型。之后我们就能根据自身产品属性的不同，来选择不同的“帮助”组合方案来解决问题。

例如TOB产品和TOC产品中，四种类别的占比就不尽相同。对于TOB类产品而言，由于：

而对于TOC产品就完全不同了，由于C端产品几乎在各个赛道上都有大批竞品，且各竞品产品基本都是相同的、标准化的。这就导致产品无法从功能层面去向其他竞品争夺用户，也就是可替换度高。这时提升产品用户体验就变成了抢用户的重要因素之一，所以活得好的C端产品在细节上的体验往往做得都很不错。再加上C端产品的商业模式不像B端产品那样先付钱再使用，所以C端用户有很大的自由度，不喜欢你这款产品可以立刻去使用其他产品。所以TOC产品中“无需帮助”“一次性帮助”“场景化帮助”“帮助文档”都是需要的，只是权重的大小不同而已。

现在我们明白了为什么很多C端产品经理接触到B端产品时，总是会投出鄙视的眼光和嘲讽：‘这设计的是什么垃圾。这么难用，谁会用这东西’的原因，其本质是两者服务的对象不同而已，再直白的说就是付钱的对象不同而已。从而导致产品设计的侧重点就不相同了。

当然，产品除了TOB或TOC的不同外，还有像是硬件产品或软件产品的不同等等，不同属性的产品在“帮助”类型的选择和搭配上都是以相同的，千万不要一个组合套到所有产品上。

最后将APP中“帮助中心”的组成梳理下：

以上，在产品设计中“帮助”模块的总结思考及理解。