了解用户需求后，如何梳理产品的功能，才能做到全面，不遗漏核心功能？
之前的文章介绍了一种方法，暂且把它叫做：用户故事地图法。
用户故事地图，产品经理必须掌握的分析利器
今天介绍另外一种方法：用例法。
不是梳理产品功能吗？怎么提到了用例，先来看看用例和功能的关系。
用例是从用户和系统之外，第三者的角度去看的，是参与者通过系统完成一组动作的描述，如注册、登录。
功能是从系统的角度去看的，是满足用户需求的一系列特性，如注册这个用例里，有发送短信验证码、表单校验、重新性校验等功能。
用例的组成单元是参与者（用户）、系统、功能，功能的组成单元是输入、计算、输出，从组成来看，用例大于功能，功能是用例的一个部分。
先梳理用例
在明确了用户需求，动手画原型之前，应该先梳理用例，用例分层后，输出功能结构图（本质上是用例，功能结构图便于沟通）
产品经理的功能结构图有几个作用，一是尽可能全的梳理功能，不遗漏核心功能。
二是拆分成合适的颗粒度，作为产品设计的最小单元，这样便于制作产品路线图，制定版本迭代计划。
梳理功能结构图后，可以将功能（用例）作为最小设计单元，输出流程图、状态机图、页面流程图、原型图。
产品的功能结构可以通过用例的三级分层来梳理，用例分为目标层、实现层、步骤层。
以订外卖为例，目标层是用户订外卖，实现层是网上订外卖、电话订外卖，步骤层是浏览商品列表、浏览商品详情、选择商品规格、设置收货地址、下单。
用户的目标也有多个层次，比如用户要购买榔头，购买榔头的目的是钉钉子，钉钉子的目的是挂画，挂画的目的是让房间格调更好，格调更高的目的是获得女朋友喜欢，用户所有的目标，只要进行深挖，都可以挖到马斯洛需求这一层级。
但是产品经理在做用例分析时，不必挖太深的目标，只需要关注到用户在网站「购买榔头」就行了。
实现层是用户为了达成目标，所采取的方案，还是以订外卖为例，用户有两种方案可以选择，一是通过APP订，一种是通过打电话订。
实现层不一定需要梳理出来，比如订外卖这个例子中，打电话这个实现层用例就不用梳理出来，默认APP订，然后继续梳理步骤层。
步骤层的用例是设计的最小单元，但要注意颗粒度，比如用户订外卖，在设置收货地址的时候，要填写姓名、地址、备注等，这种步骤过于细，不用梳理出来，梳理为「设置收货信息」就可以了。
某些步骤层的用例还可以组合，以达到合适的颗粒度。
关于颗粒度的划分，没有严格的标准，一个中型系统，一层用例10个左右，二层用例1~3个，三层用例5个以内，比较合适。具体划分根据项目大小、团队分工来判断。
使用用例法梳理产品功能框架以后，可以用思维导图输出一张结构化的脑图，然后按照三层结构进行展示。
要注意的是，这个框架图里，所有功能的命名一定是动宾结构，如果不是动宾结构，你可能梳理的是功能或者信息。
功能结构和产品结构
梳理功能结构时，其实是在梳理用例，只是叫功能结构图会比较容易理解和沟通。
那功能结构和产品结构又有什么区别的？
功能结构是业务视角，是逻辑模块，产品结构是产品视角，从产品视角来看，产品是由模块、子模块、页面、字段、控件组成的，产品结构更像是物理结构。
梳理产品结构图，相当于提前过了一遍产品，梳理完以后就大概知道产品有多少个页面，每个页面要展现什么内容，以及有什么控件，产品结构图可以指导原型设计。
产品结构可以按照产品的全局导航或者菜单，梳理出产品的模块、页面和页面里的内容。
写在最后
业务架构、产品架构、产品结构、功能结构、信息架构、信息结构，这几个词经常出现，但是我感觉大家理解都不一样，基于我自己的理解，梳理了这张图：
希望对大家理解有一定的帮助，也欢迎和刀哥讨论，谈谈你的理解。