Jesse James Garrett所著的《交互设计——用户体验要素：以用户为中心的产品设计》描述了一个冰山五层模型，这个模型最早是用来指导网站设计的。随着互联网的发展和应用形式的变化，设计师们发现，除了web应用，这个模型也同样适用指导移动端APP应用。
冰山模型的每个层级的指代范围不再赘述。最近我在做商业模型和业务模块对应到多个应用群的“产品生态圈”设计时，我发现，使用冰山模型，能帮助很快地理清思路。
举一个例子。假设有一个项目在通过前期的宣传引流后，想要以电子商务的形式销售一批商品，商品包括实体物品和需要到线下实体店体验的服务类商品。这个项目的商业模式是这样的。
为了实现商业模型，项目中需要设计一个或多个产品，来覆盖具体的业务流程。从使用产品的用户角色划分，产品有给运营使用的业务系统、给前台用户使用的用户产品和B端合作者使用的业务后台。
首先分析商业模型中覆盖的业务有哪些。
底层业务模块包含了产品为了实现商业模型，所必须的基础功能。商业模型中有多个用户角色，而每一个业务模块没有对标的【用户】概念。PM在分析业务流程以后，才会确定不同使用环节中，使用者是谁，需要哪些功能。
数据库的实际设计远不像图示中的那么简单。数据库设计结果是总表和关联表的综合统筹。就以商品SKU表作为基础表举例，基础表可能仅包含商品的基本信息字段，具体的业务信息被设计在关联业务表中。在确定了唯一SKU编码以后，实际库存、相关销售品的销售状态、月售情况等字段可能是根据业务需求，被设计在关联表中。
设计表的核心就是①根据业务需求设计表字段；②确认关联表之间的唯一标识符，比如用户身份表和用户偏好表是两张表，表间能关联对应的基础是确定UID。
业务模块和数据表的设计是紧密相关的，因为都是从商业需求开始划分和设计的。对表的OI操作是产品模块的需求之一。
底层业务模块是彼此关联的。在设计产品的功能边界时，根据具体场景，一个业务模块可能被拆分到多个产品中，成为产品模块。
就拿上述的优惠模块为例，产品针对消费者有多种优惠模式，比如高级会员终身九折，活动商品八折，某渠道的用户买一送一，那在CRM、销售后台和渠道管理系统，可能各自存在优惠配置应用模块。
当然，视具体情况，以上也可能存在在一个整体的大业务后台。
页面模块和页间交互就是产品在确定了功能边界和功能模块以后，定义具体的用户使用流程和页面导航系统。这个应该是大部分用户产品PM所熟悉的流程了。
以上，星移酱的思路笔记。
