用面向过程和面向对象分辨功能结构图和信息结构图

基本概念

简单来说，面向过程即思考事情的流程、步骤，面向对象即思考存在哪些事物及事物的属性和方法（操作）。

产品思维的一种理解是解决特定场景下具有特定属性用户的需求，用户的需求可能需要多个步骤来实现，各个步骤可能与不同对象交互。

三图辨析

最近通过将各类产品的产品结构图分解为功能结构图和信息结构图，从而倒推需求逐渐具体化的过程（产品架构-> 主要功能-> 信息结构 -> 原型的脑图映射，也基本与用户体验五层次自底向上的实现过程相符）。

最开始，我认为功能结构图即分层次梳理功能，信息结构图就是进一步细化，按层级把每个字段摘下来，产品结构图就是信息结构图加上交互联系。这样的理解是错误的，如果三图仅仅是包含关系就没有共存的必要了。并且我发现小伙伴也对三图的区别有疑惑、一些网络文章对三图的辨析也存在错误理解。于是将自己的思考记录下来，或许也能给你一丝启发。

新产品（功能）诞生的初衷是为了解决需求，即谁在什么场景下要做什么，其中，“场景”不是实物，是一种情境（context），做什么可以按过程拆分，“谁”需要通过与不同的事物交互实现“做什么”的各个过程。

那么功能结构图就对应着按过程拆分的“要做什么”，信息结构图对应着“谁”和所要交互的不同事物，即，功能结构图包含各个“过程”中对象的“方法”（操作），梳理时注重思考用户使用流程；信息结构图包含对象的“属性”，梳理时注重思考表单、数据库设计。而产品结构图作为原型的脑图映射，是对功能结构图和信息结构图有联系的整合和复用。

所以说，三图的关系不是包含，也不是简单的加和关系，而是有联系的整合与复用。

以爱奇艺iPhone版V11.12.0为例：

功能结构图

用户对视频APP的需求主要为看内容和互动，主要使用过程（功能）可分析为：

看内容，消费，互动，生产内容，大致的一级功能也依此成型。有了一级功能，便需要根据用户在相关情景下能（想）具体做的操作进一步拆解子功能。比如交易功能模块可以被拆解为支出、收益等子功能，支出又可以被拆解为开通会员、充值奇点等等。

功能结构图

在拆解功能时可以思考目前拆出来的子功能是否拆分过细、是否能进一步整合，以提高绘制产品结构图时对功能结构图的复用性。同时，尽量避免直接将产品真实交互界面展示出来的功能（信息）父子关系与功能结构逻辑相映射，多独立思考功能之间的关系。部分情况下，视觉上的父子关系是由于同级别功能中的某一个功能（由于频繁使用/ 利益更多/ 希望加强引导用户……）优先级稍高。比如，最开始我被APP页面设计引导，把开通会员分为开通VIP会员和开通所有会员，并进行下一步功能拆分，但这样所得的功能结构图分支冗余、整合性差，选择会员类别这一功能便是对开通不同类型会员的进一步整合。而视觉上开通VIP会员和选择其他会员功能处于同一级，可能是由于VIP会员是主要业务、业务需求量最大等等。

会员开通页面

信息结构图

首先需要确定这个需求中的对象（角色、事物）有哪些，其次进一步拆解或整合各个对象，最后思考对象的自身属性以及通过操作功能而获得的属性，并将他们映射为对象的分支。

一些思考节点：1 视频APP这个context下的对象有视频、漫画、榜单、主播、我、作者、外观……2 视频、漫画都属于内容，视频有小视频和长视频，并且两者无论是属性还是相关操作区别都很大，那就把他们单独列出来吧……3 内容除了这些还有什么？哦对，把小说加进去……4 内容类别下的对象对应着内容个体（比如一部电影、一本书），那内容的集合（比如电影列表、书架）是属于单独一类对象还是也属于内容呢？……5 虽然表面上看列表就是内容个体的集合，但列表和内容个体的属性仅有部分重叠，而不是包含关系，所以应该存在内容列表这一类独立的对象，分为长视频列表、直播列表、漫画书架……

信息结构图

产品结构图

先放一张大致的产品结构图，方便对比功能结构和信息结构感受真实的产品构造，关联还没补充完全。

产品结构

我的想法是先通过体验现有产品梳理出产品结构图，对整个产品的业务线有个大概的认知，之后通过独立思考产出功能结构和信息结构图，再通过考虑优先级、联系等问题独立绘制产品结构图，并与实际产品结构图相对照反思，建立一个思考-输出-印证的学习闭环吧。

今天暂且到结合面向过程、面向对象以及产品思维分辨功能结构图和信息结构图，接下来便是“如何将功能结构图和信息结构图抽象为产品结构图及原型”了。