【产品经理学习笔记】Part 8 产品功能设计与PRD文档撰写

产品功能分析Case：搜索框

• 思考：
  • 回忆一下你在各类产品里见过的搜索入口
  • 搜索框在产品里的目的是什么？
    • 帮助用户更便捷高效地从大量信息内容中通过一些关键词迅速找到自己感兴趣的内容
    • 其次可以通过适当的引导设计来完成产品的商业需求
  • 搜索入口的类型有哪些？
    • 搜索框（淘宝、导航栏中）——带来流量
    • 底部标签栏（iOS AppStore ）——切换方便
    • 搜索按钮（放大镜、导航栏中）——搜索功能在APP中较不重要
    • 隐藏搜索框（微信下拉搜索）——搜索唤醒频率更低，用户需求量小
    • 搜索表单
  • 什么情况下需要搜索版面？设置这些目的是什么？

    • 默认提示词

      • 第一种：一般默认提示词会提醒用户搜索哪些关键词，比如搜索订单编号、搜索商品名称等，适用于产品初期，用户不太会玩，所以需要一个很好的引导（eg：MONO、花瓣网、百度一下你就知道）
      • 第二种：默认提示词也被用来进行运营推广，将业务需要的关键词至于搜索框内，用户看到感兴趣，直接搜索即可得到相应的结果，这可以用作活动的流量入口（eg:淘宝、虾米）

    • 历史搜索

      • 大部分用户的喜好是固定的，搜索有一定的重复性，故通过选择先前的记录，进一步帮助用户节省时间，高效操作

      • 清除历史搜索（eg：淘宝），部分业务还会有逐条删除的功能，给了用户比较大的自主权，留下常用的历史搜索，删掉不常用的（eg：微博、知乎）
      • 显示搜索纪录按钮，因为版面限制导致当前放不下较多的历史搜索，只能展示部分搜索记录，剩余会隐藏，点击显示后，搜索记录全部显示（eg：微博）

    • 热门搜索

      • 根据已有的搜索数据，放一些搜索频次较高的关键词，便于大部分用户快捷选择；此外就是运营层面的应用，会放一些商品或者活动入口的关键词，增加活动或商品曝光的机会。还可以通过视觉上的处理来突出想要突出的重点信息，比如加个品牌色，价格tag标签（eg:网易严选、微博）

      • 第一种：加个更多按钮，用一个新的页面承载更多的热搜内容（eg：微博、优酷）
      • 第二种：先展示一部分，然后有按钮可以在本页面展开更多（eg：虾米）
      • 第三种：用tab bar来承载不同分类下的热搜内容，节约了空间，放下更多的内容，同时有了明确的分类，用户更容易找到感兴趣的东西（eg：优酷）

    • 限定搜索范围

      • 某些业务范围较广，内容较复杂，所以用户在搜索页面即可限定搜索范围，让搜索更为准确

      • 第一种：二级tab bar的切换，直观且操作方便，适合于限定范围频繁的业务（eg：淘宝）
      • 第二种：搜索框左侧文字按钮，点击后出现浮层选择范围，适合于使用限定范围不太频繁的业务（eg：大众点评）
      • 第三种：文字或者按钮的不同范围的入口，点击进入该范围的搜索，适用于目的性较强的搜索（eg：微信、京东金融）
        

    • 实时搜索和非实时搜索

      • 实时搜索：边输入关键词，边出现结果页面（eg：百度）
      • 非实时搜索：当输入完关键词后按确定按钮，才显示结果页面。
        
  • 搜索结果筛选
  • 无结果推荐

  ---

产品结构图：梳理产品流程和框架

用户流程图：模拟用户操作流程

原型设计：将结构化的需求进行框架化

• 手绘原型（线框图）
• 灰模原型：静态原型
• 交互原型（Demo）——Axure

---

PRD（产品需求文档）

• 项目/产品概述
  -叙述该项目软件/产品应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料

  • 应用目标：可以理解为产品要解决什么问题，如：针对xx状态下，无法进行xxx的情况，使xx产品可以通过xxx完成对xxx的开展工作
  • 范围：明确产品边界，说明产品将干什么，不干什么
  • 开发背景：为何要开发这个产品，一般情况下根据团队理解程度，节选BRD、MRD相关调研背景资料
    • BRD：商业需求文档
    • MRD：市场需求文档

• 功能/需求概要

  • 描述提供给用户的产品特性和功能。通常使用框图、表、文字结合的方式说明，便于快速理解

  • 产品描述：总整体上解释和描述产品定位，产品目标。如：该产品是一款专注于xxx的平台，A业务解决用户xxx的问题，B业务解决运营xxx的问题。
  • 概要功能列表：列出文档涉及的功能列表清单

  序号	需求编号	功能名称	需求描述	需求类型	需求分析	优先级
  1	M1-F1	登录	快速登录	新增	【KANO等级】必备	1
  2	M2-F1	搜索	快速搜索	新增	【KANO等级】期望	2

• 产品结构图和页面结构图

• 详细功能需求：业务需求

  • 功能名称
  • 需求概述
  • 需求描述：xxx（角色）在xxx的情况下，通过xxx的方式，达到xxx的目的
  • 业务场景：描述用户的使用场景，如：小王到达A写字楼后，停车场管理员告知车位已满，小王扫描车位二维码，寻找附近的空闲停车场
  • 参与者：表述此功能具体使用人有哪些，如某功能是管理员使用还是员工使用
  • 业务流程：详细描述业务设计的主要事件流程，可通过流程图辅助说明
    • 前置条件：在开始前，系统可检测的有意义的条件。如：意见反馈查询功能中，用户已提交意见反馈
    • 触发事件：触发系统功能的时间。如：用户点击、收到通知
    • 基本事件流：常规，正常情况下的预期事件流
      • 如：1.点击xxx进入页面 2.输入xxx 3.选择xxx 4.点击确定保存xxx
      • 可以通过流程图辅助说明
    • 扩展事件流：备选，可选事件流。如：可通过点击{导出}，进入导出流程
    • 异常事件流：异常情况下事件流。如：空状态下，服务异常时的事件流
    • 后置条件：在结束时，系统可检测的有意义的条件。如：保存后，界面数据更新
  • 相关功能：与本功能相关，但较为复杂，难以一起表达时，拆分到细分场景后所关联的功能。可以描述出它们直接的输入输出关系
  • 界面原型：原型截图或者链接至原型文档

• 详细功能需求：报表需求

  • 报表功能 （金融APP、TO B）
  • 功能名称：一般直接使用报表名称作为标题项，便于生成目录和在文档结构图中快速定位。如：某某报表，编写时一个报表一个小节
  • 概述：因报表一般情况下的用户是管理者，因此报表类功能概述主要便于理解业务场景和管理者的意图和目的
    • 目的：管理者为什么需要查看此报表
    • 使用部门/职位：用于理解使用者的职责，包括地理级别，如：xx财务处理岗位，省级/市级
      -相关场景与频率
  • 报表内容
  • 详细详述报表的各项数据的来源和计算规则
    • 数据来源：该数据项的基于哪些数据生成。如：消费金额统计，来源于xx订单记录
    • 计算规则：该数据的统计公式。如：消费金额统计，xx订单中“实收”的累加金额
  • 界面原型
  • 报表展示原型：个人建议报表原型最好模拟一些真实数据和用户确认最终效果
  • 报表框架
    • 描述报表模块的通用框架需求，如：打印、打印预览、导出、总计、排序、默认条件、筛选条件、分页、是否支持动态报表模板等