四个方面，深解产品架构设计.docVIP

四个方面，深解产品架构设计 　　一个APP根据其所提供的服务不同，包含各种各样的功能元素。产品架构，就是将这些不同用途的功能元素围绕特定的目标进行分类整合。 　　 　　1.为什么需要产品架构 　　当我们打开一个APP， 映入我们眼帘的首先是一个精致的页面，一些丰富的信息、导航，一些生动的横幅引导我们去做一些看上去很有意思的事情。这些东西是APP的组成部分，是APP的一些必要的功能元素，它们分别作为显示、引导、诱导的功能。一个APP根据其所提供的服务不同，包含各种各样的功能元素。产品架构，就是将这些不同用途的功能元素围绕特定的目标进行分类整合。 　　假如我们把一些APP需要提供的功能元素不分主次先后的堆积在一起，用户不知道从哪里开始，点击按钮之后会发生什么事情，用户很难找到自己想要的东西，也不知道能怎样得到想要的结果，用户手足无措，只能带着深深的挫败感放弃离开。经过架构，产品能让用户按照自己的预期顺利完成自己想要进行的任务，达到想要的结果，并安心的离开。架构对产品来说是必要的。 　　2.产品架构解析 　　任何事物都是由一些元素组成，对于一个边界分明的事物来说，其组成元素总是可遍历的（有些系统组成元素数据量太大很难遍历，这是技术的限制性，不能说不可遍历。）。同样的，事物的所有组成元素之间总是在不同程度的发生关系。这些元素和元素之间的关系一起形成了事物展现在我们面前的整体形态。而我们现在想要分析的产品架构，就是产品的各种功能元素与元素之间的关系。这些功能元素与其相互之间的关系形成了一个产品的系统模型，用户通过系统模型来尝试了解一个产品，并不断的形成对产品的认知模型。用户通过系统模型建立认知模型的难易程度决定了用户对产品的认可和接受程度。 　　1）功能元素 　　这里说的功能元素是用户能够完成一个小回合操作的最小粒度的完整功能。比如一个展示可预订酒店的列表页面，一个点击之后可以触发一个事件返回一个结果的功能元素、一个密码修改的功能。而不是产品界面的组成组件按钮、标签、文本框。这里的功能元素带有一定的操作及其结果属性。 　　好的架构中，用户通过一个功能元素完整的完成一项唯一的工作，不是半个工作，也不是多项工作。这样的设计不会让用户对于操作和得到的结果迷惑不解。 　　不好的架构设计示例： 　　这是我曾经重构过的一个产品的功能。功能想要解决的问题是给用户开通一个财务账户，用户可以用这个财务账户里面的钱付收货费用、发货费用，订单费用、门店奖励费用等公司财务支付类型中的一部分。如果用户要用财务账号支付订单费用，则只能用来支付一些特定渠道的订单的费用。 　　简单的总结，这个财务账号有两个属性：支付类型和订单渠道 　　 　　我重构前，这个功能被设计成这样：订单渠道被作为订单类支付类型的一个属性。用户如果要给财务账户添加不同的订单渠道，他要改为为财务账户添加带有不同订单渠道的多个相同的支付类型。 　　 　　在这个例子中，一个功能元素融入了两个任务目标，用户每完成一次操作都是完成了任务的一部分。他要分很多次来完成一个完整的任务。 　　2）功能元素之间的关系 　　在 1）中不好的架构设计示例似乎同事也很好的说明了功能元素之间关系的问题，订单渠道被理解为是支付类型的属性，但这两者之间其实没有必然的联系。产品架构中，功能元素是根据其相互之间的关系来组织的。 　　一个产品中不同的功能元素之间的关系分直接关系和间接关系。只有直接相关的功能元素才会被组织到一起，那些没有直接关系的元素会在不同的层级通过其他的直接关系产生间接关系。好的架构实体与实体之间关系清晰明了。有时候为了性能、数据完整性、系统稳定性或特定用户场景的需要，对类似的功能元素做适当的冗余，但都是必要的合理的范围内，且前提是不会出现含糊不清或牵强的情况。 　　不能形成任何关系的功能元素组成的东西不能称为系统。有些功能被设计为彼此之间不产生关系，这样的组成部分在平台化的产品中比较常见。由于避免品牌影响力分散、安装麻烦等技术问题或其他原因，它们被组织在一个统一的平台型产品中作为并列的几个组成部分，共同为来平台的不同用户群体提供不同的服务。比如有些公司为了扩大目标用户群体、提升自己的竞争力或提升用户粘度，会开辟不同领域或相同领域不同体验的服务，作为更多的选项并列给用户提供更多选择。 　　3）系统功能层级 　　一个产品的使命是为特定用户群体提供特定的服务，产品所有的功能都是为这统一的目标服务的。一个产品不论其有多少功能元素，最后都只能汇总为一个完整的简单的最高层级的功能元素。比如一个购物产品需要提供的唯一的功能是：找到想要买的东西-下单-收货。会有很多其他的功能来辅助完成最高层级功能的某个环节，这些辅助功能就是低一层级的功能；有些复杂的低一层级的功能还会有更低一层及的功能来辅助用户完成它。在一个架构良好的产品中。