1.为什么需要产品架构
当我们打开一个APP, 映入我们眼帘的首先是一个精致的页面,一些丰富的信息、导航,一些生动的横幅引导我们去做一些看上去很有意思的事情。这些东西是APP的组成部分,是APP的一些必要的功能元素,它们分别作为显示、引导、诱导的功能。一个APP根据其所提供的服务不同,包含各种各样的功能元素。产品架构,就是将这些不同用途的功能元素围绕特定的目标进行分类整合。
假如我们把一些APP需要提供的功能元素不分主次先后的堆积在一起,用户不知道从哪里开始,点击按钮之后会发生什么事情,用户很难找到自己想要的东西,也不知道能怎样得到想要的结果,用户手足无措,只能带着深深的挫败感放弃离开。经过架构,产品能让用户按照自己的预期顺利完成自己想要进行的任务,达到想要的结果,并安心的离开。架构对产品来说是必要的。
2.产品架构解析
任何事物都是由一些元素组成,对于一个边界分明的事物来说,其组成元素总是可遍历的(有些系统组成元素数据量太大很难遍历,这是技术的限制性,不能说不可遍历。)。同样的,事物的所有组成元素之间总是在不同程度的发生关系。这些元素和元素之间的关系一起形成了事物展现在我们面前的整体形态。而我们现在想要分析的产品架构,就是产品的各种功能元素与元素之间的关系。这些功能元素与其相互之间的关系形成了一个产品的系统模型,用户通过系统模型来尝试了解一个产品,并不断的形成对产品的认知模型。用户通过系统模型建立认知模型的难易程度决定了用户对产品的认可和接受程度。
1)功能元素
这里说的功能元素是用户能够完成一个小回合操作的最小粒度的完整功能。比如一个展示可预订酒店的列表页面,一个点击之后可以处罚一个事件返回一个结果的功能元素、一个密码修改的功能。而不是产品界面的组成组件按钮、标签、文本框。这里的功能元素带有一定的操作及其结果属性。
好的架构中,用户通过一个功能元素完整的完成一项唯一的工作,不是半个工作,也不是多项工作。这样的设计不会让用户对于操作和得到的结果迷惑不解。
不好的架构设计示例:
这是我曾经重构过的一个产品的功能。功能想要解决的问题是给用户开通一个财务账户,用户可以用这个财务账户里面的钱付收货费用、发货费用,订单费用、门店奖励费用等公司财务支付类型中的一部分。如果用户要用财务账号支付订单费用,则只能用来支付一些特定渠道的订单的费用。
简单的总结,这个财务账号有两个属性:支付类型 和 订单渠道