背景
今年二月底入职了新公司，主要产品是企业级研发管理 SaaS 软件。这家公司的新员工在参与产品迭代之前需要进行相关的学习和培训：
- 第一、二周先自己学习使用公司的软件和行业名词，并模拟成销售的角色来参与一次产品演示和场景化配置的考核；
- 第三周基于自己感兴趣的主题来分析竞品和自身产品的某项特点，并作一次分享会；
- 第四周才正式开始参与产品设计，进入到迭代当中。
我是比较认同现在这一家公司的入职流程的。毕竟 SaaS 软件是会有点学习成本，自己先把各种功能、场景、配置和行业相关名词学会了之后才能更顺畅地合作。
就在我刚开始学习使用公司软件的时候，会感到有些吃力。比如：
- 功能/流程配置。比如我想要做某项配置，但因找不到入口导致无法配置，或被某些逻辑限制导致结果与预期不符时，需要去到帮助文档里搜索相关概念，然后再对照文档里面写的步骤来实现；
- 名词释义。有些行业内的名词我之前没接触过，或者不能够直接根据字面意思理解的时候，我需要去文档或者维基百科上查找相关的释义、使用场景和最佳实践。比如「故事点」、「用户故事」、「史诗」等；
- 系统概念理解。我需要通过查阅文档、询问导师和自己反复尝试来去了解软件系统内的一些运行机制，比如说多种层级的权限，或者一个叫「池子」的概念…
所以在第三周的分享中我选择了主题是关于产品设计中如何帮助新用户上手使用软件。正好自己也看看其他做的好的产品是怎么做的，之前这方面的实践比较少。
概念学习
在实际进入竞品里体验之前，我先去网上学习点跟帮助系统相关的概念。我通过 NNGroup 的文章了解到帮助会分为两大类：
预防性帮助 (Proactive Help) 指的是系统在用户遇到问题之前提供帮助。常见的方式包括： Onboarding、新功能提示、上下文帮助(Contextual Help) 和向导等。
针对性帮助 (Reactive Help) 指的通过文档、视频、课程等资源来回答和解决用户的具体问题。或者为想要成为专家用户的人提供详细的文档和资源。
而「预防性帮助」，又能分为两种类型：
主动呈现 (Push Revelation)： 不考虑用户的任务而提供帮助内容。强调主动提供帮助信息而不考虑用户当前行为。这种方式会可能打断用户进行中的任务并引起用户的不适，需谨慎使用。
被动揭示 (Pull Revelation)：与用户当前行为相关的帮助。侧重于与用户当前正在进行的动作、行为和活动等有紧密关联。提供有助于用户完成当前任务的相关建议和信息。
经过梳理后，这些概念的关系图像大概是这样：
从 NNGroup 了解预防性帮助和针对性帮助的概念
。
接下来就从上述的多个手段中选取几个，结合 Jira、Asana 和 Notion 的做法来做一些观察和分析，并尝试总结出在它们身上能学到什么。
新用户旅程
新用户旅程 (Onboarding) 设计有助于引导用户使用产品，让用户发现产品的核心价值，进而推动用户留存、转化和推荐。
我分别体验了 Jira, Asana, Notion 的 Onboarding，发现这三者的流程大致相似，但基于软件本身的功能不同而有些许差异。值得一提的是，他们都做得很细致。
流程
走查了三款软件的 Onboarding 流程，并以粗颗粒度来划分步骤。
其中与比较关键的是第二步：
第二步：收集信息。收集用户的角色、工作职能、主要任务、团队规模等信息。用于获取用户的标签，以便后续进行精细化运营。同时影响到后续的配置、预设的数据和界面内提供帮助的程度。
第二步里收集到的信息会影响到创建入门项目、邀请成员和进入系统后的主界面。比如在 Notion 中如果提供了「个人使用」作为用途，则流程中不会出现「邀请成员」的模块。
千人千面
值得一提的是，Onboarding 流程中收集的用户信息，可以为后续的系统预设和默认配置提供参考。
比如在 Jira 中，系统会根据用户填写的团队类型和主要工作类型等因素，推荐对应的模板。如果用于管理软件开发团队，则推荐用敏捷项目模板；如果是管理业务团队，则推荐用项目管理模板。并引导用户使用模板创建第一个入门项目。
并且根据用户对 Jira 和敏捷方法论熟练度，决定是否在用户首次进入主界面时提供向导。如果是新手，在进入主界面时会询问是否需要跟随向导了解界面和功能；如果是有经验者，则没有向导提示。
再比如在 Asana 新用户旅程中，如果用户选择角色是「高管」，系统内新手引导卡片内的称谓和步骤，都会与「团队成员」的角色不同。
高管的引导卡片添加了「开始成为一名管理人员」的文案，而初始配置的步骤包含「创建报告」和「创建一对一会谈项目」等；而团队成员的引导卡片则是「填写个人资料」、「下载 App」和「查看第三方集成」。
或者当用户的角色是「经理」，仪表盘卡片也会与「自由职业者」不同。经理的默认仪表盘中有一个卡片是「我指派的任务」，而自由职业者则没有。
Notion 也会根据用户选择的工作类型，在邮件中更改相应的称谓。
我们能学到什么
💡 定制个性化的用户旅程。不同的用户有不同的需求和期望，为了更好地满足用户，我们可以根据收集到的信息来提供更符合其所处情境的预设、引导流程和配置等。
💡 合理利用向导来帮助用户上手软件。向导能帮助用户熟悉界面 UI 和功能，但要避免阻碍用户使用软件。所以需要根据用户对软件熟悉程度来决定是否提供向导，并保留跳过的方式。
上下文帮助
本文的最开始提到预防性帮助有两种方式，第一种是主动呈现 (Push Revelations)，比如一进入页面就出现的新功能提示，或者界面操作向导等。
而这里重点介绍的是另一种：被动揭示 (Pull Revelations)。而「被动揭示」有一种做法叫做上下文帮助 (Contextual Help)。这是指根据用户参与的特定活动，展示与此相关的帮助信息。强调要与用户当下的活动密切相关，而不是统一的推送。而具体的做法有很多种，比如：工具提示、向导、输入框提示、内嵌帮助中心等。
使用案例
Jira 的筛选器界面，在用户没有创建过筛选器时，会出现内嵌的帮助中心，呈现与筛选器相关的帮助；而当用户当前已存在筛选器，打算继续创建时，则会默认隐藏内嵌的帮助中心，用户可以手动点击右上角的问号图标打开。
相似地，Asana 的 Task 列表中，用户对任务进行多选后，也会在操作栏出现与之相关的工具提示。
同时也可以看看其他 SaaS 软件的做法，不必局限于竞品。因为这种设计理念是通用的，都是为了帮助用户更好地上手，为用户持续提供价值。比如 Slack 也在这方面下了很多功夫。
我们能学到什么
💡 帮助内容保持简洁。使帮助的内容简短并有效，并且在用户要求之前不要呈现过多细节或复杂的内容。
💡 易用且不干扰。上下文帮助可能会干扰已经熟悉界面或者不需要帮助的用户使用。所以在呈现帮助内容时，确保使用轻量的样式，并且允许用户跳过帮助。
💡 使帮助内容可以在其他地方访问。用户可能看到过一些帮助提示，但当时他们忽略了或者忘记了，这在复杂的软件里很常见。所以仍然需要提供其他方式来使用户获取到帮助内容。
模板
模板中心
用户使用 SaaS 软件通常是带着现实情境过来的，比如希望进来做任务追踪，或者是进行多项目的管理和进度追踪等。
所以我观察到这几款应用的模板生态还是比较丰富的，覆盖了多种场景。完善的模板能够帮助用户快速上手，减少学习和操作成本。
Jira 的模板中心以业务为基础，更多地关注具体的业务流程、管理流程和功能的实现。适用于企业内部、管理领域软件行业。并且有详细的模板使用说明和相关模板。
Asana 的模板按照团队内不同职能部门来划分，侧重于流程优化。并且有详细的模板使用说明。
Notion 的模板中心按照专业领域和个人兴趣分类。适用于个人、自由职业者和信息分享平台等。并且允许用户上传自己做的模板并进行收费，既能够满足用户的个性化需求，又能够为 Notion 和整个社区提供更多的价值和机遇。
本地化
值得一提的是，Notion 和 Asana 的模板中心做了比较细致的本地化处理，切换语言后会呈现更符合用户所在地区的分类和模板。
其中 Asana 的模板顺序，「每日站会」在日语和英语中，分别是首位和末位。为此我也有去了解过美国和日本的文化差异，试图去解释为何 Asana 要这么做，这是调研出来的差异：
- 文化倾向。日本强调集体主义，注重团队合作和群体利益；美国强调个人自由，注重个人的成就和个人的价值。
- 协作模式。日本注重面对面的交流和沟通。在组织中强调员工之间的默契和团队合作精神；而美国更加弹性化，注重个人的私人时间和团队协作效率的平衡，支持远程协作。
- 企业文化。日本注重团队合作、持久性和精益求精，对个人规范和职业素养的要求高；美国注重灵活性和创新，注重持续快速发展和快速创造价值。
这些未必是 Asana 做这种本地化差异的理由。但是能反映出来，日本和美国这两个国家在霍夫斯泰德文化维度来看，是有明显差异的。如果之后工作中我有相关的设计机会，也会多多尝试基于两个国家文化差异，而作出不同的设计策略。
我们能学到什么
💡 模板丰富实用。模板对于 SaaS 软件的用户来说是非常重要的，它可以帮助用户快速上手并减少学习成本，并且加深客户对产品定位的印象。
💡 帮助新用户上手。不同 SaaS 软件的模板中心存在一定的差异，它们通常会按照业务场景、职能部门、专业领域和个人兴趣等各种标准进行分类。
💡 关注本地化策略。设计模板时需要考虑到不同地区、不同文化和不同工作习惯的用户的需求和习惯，并且根据实际需要进行调整和优化，以便更好地适应当地市场，吸引更多潜在客户。
帮助中心
产品文档
产品功能文档或开发者文档，是 SaaS 软件帮助中心的标配。我也有去看不同产品的功能文档，看看他们为了帮助用户更好地理解和使用，做了哪方面的努力。
比如 Asana 会标记截图中的行动点，然后在旁边写上相关的步骤操作。标记行动点是用户更容易发现目标，而分步描述则让文字更加简洁易懂。
值得一提的是，Asana 不仅仅提供产品功能文档，还按场景分类，提供多个工作流程的配置方式（最佳实践），比如会议、日历和计划等。试图去引导用户按照 Asana 所推荐的方式来去使用该软件。
其他资源
调研中发现现在的帮助中心内容丰富，除了常见和必要的产品功能文档/开发者文档之外，还有其他很多提供帮助的资源。比如视频讲解、视频课程、实践案例、社区、博客、公开课等。
Jira 通过社区来加强与用户之间的联系，比如：处理用户反馈、新功能发布的通告和邀请客户参与一些试验性的功能等等。社区内也会常驻社区领袖来响应用户的反馈。
Notion Academy 提供了详尽的视频课程，由浅入深。比如从基础的界面功能、团队管理，到使用数据库和人力资源场景下的大型团队空间配置等。
Jira 和 Asan 都会比较积极地举办线上公开课 (Webinars)。通过这种方式来提高品牌知名度、建立专业的形象，保持和用户交流，并最终促进销售。
值得一提的是，我观察到海外的产品，对于视频课程除了直接把视频传上去之外，还能够多做几件事情来提升视频课程的阅读体验，并且在国际化场景更加友好。
- 支持 CC 字幕。帮助非视频语言母语的用户更好地理解视频内容，同时也能为听力障碍和不方便使用扬声器/耳机的用户提供便利。
- 支持时间轴目录。帮助用户快速了解视频的主要内容，并找到自己需要的信息。与图文教程相比，视频获取信息的效率比较低，但这种做法能弥补缺陷，提高用户的学习效率。
- 支持文字稿。帮助用户更好地跟进视频的内容，也方便他们在需要时快速查找相关的信息。并且同样能为听力障碍和不方便使用扬声器/耳机的用户提供便利。
- 加入互动元素。提供与视频课程相关的调查、实时聊天室或小测试，能够促进学习效果并增加兴趣和参与度，提升课程质量。
我们能学到什么
💡 细致易用的用户文档。用户使用文档的场景是明确需要帮助，或者希望成为专家用户，了解产品设计背后的概念。所以文档需要足够的细致、具体和易用。比如像 Asana 帮助文档中提供了步骤图，或者 Asana 线上公开课中为视频提供了段落拆分。
💡 丰富的资源和帮助方式。不同人在解决问题和接收帮助方面都有着自己的特点和偏好。所以需要提供多样化的帮助资源，比如：文档、视频、案例拆解、线上公开课等，持续提供影响力。
💡 强调最佳实践。Jira 的帮助中心里有许多关于敏捷开发概念、实践的文章。Asana 的实践案例也在频繁加入自身对工作流的理解。在帮助中心中强调最佳实践能够帮助用户更好地使用软件和理解背后的理念。
💡 增进用户的参与感。帮助系统可以支持互动和社区功能。比如评论、分享、点赞等。为了进一步提升用户的参与度，还会支持社区、公开课等。
结语
以上就是我对公司几款竞品帮助中心调研后，总结出来能够帮助新用户上手的产品设计。整体感受是「帮助系统」这一块可以做得很大，又能做得很细。
往大了做：包含基础的文档、功能引导；进阶的课程、模板和大学，以及上升到行业影响力的线上公开课、线下 Events 和职业认证。
往细了做：Onboarding 流程规划、上下文帮助的设计、文档/视频课程的细节，模板的本地化方案等等。
所以说越做设计越感到自己个人力量的渺小，世界太大了… 但不管怎样，来到新公司我的目的是取百家之所长，扩展下之前没怎么接触到的领域。
碎碎念
文中部分名词（如：Proactive help, Reactive help, Push revelations, Push revelations…）由于我没有在中文设计圈内找到合适的翻译，于是便自己琢磨着做出了翻译，本身自己不是想「造概念」的，但总得有个名字吧。如果读者有其他更好的翻译方案欢迎交流。
另外这是我第一次尝试用到人工智能来参与博客的创作。使用到了 ChatGPT 3.5 来帮我做资料搜集、文本润色&修正、名词释义和总结提炼。比如文中「我们能学到什么」里面的小标题，有部分是我发一段文字后，ChatGPT 帮我总结的，或者我理解了很久的 Pull revelations 和 Contextual helps 的关系，也是 ChatGPT 帮我梳理的。
另外也用到了 Midjourney 来生成这篇文章的封面图背景，以及「我们能学到什么」的配图。
这两个工具的强大不必过多介绍了，只是中途一件有件小事值得记录一下。起因是我想查找 Reactive Helps 相关的内容，就去阅读了 NNGroup 上面相关的文章，以及询问 ChatGPT。令人惊讶的是 ChatGPT 给了和 NNGroup 相反的理解…
