产品设计没有信息架构,等于在盖一栋迟早会倒的楼

6 评论 16190 浏览 67 收藏 8 分钟

用砖砌盖房子,如果只是盖一个小房子,我们随便一个人就能盖起来,并且一般情况下不会倒,也不需要什么钢筋或者框架,但是如果是一栋大楼或者一个楼群,那么就不得不事先设计好框架,想清楚各个单元之间的相互影响。

目前行业总体情况来看,大部分设计是在已经有一个产品基础上进行一定程度的优化,包括虽然没有产品,但是业绩有类似的产品可以参考,这部分其实也可以算作是优化类。又或者是完整的功能创新,创造一个以前没有的产品。这一类的项目,大部分以功能为主,基本不涉及信息架构内容。总体的架构已经有了,只是在不同的分支上进行优化,简单类的功能设计,也不需要什么信息架构来支撑。

但是如果遇到复杂的系统,多个系统之间又有千丝万缕的联系,这种情况下,如果还是用之前堆积功能的方法来设计,可能就会跌入万丈深渊。在刚开始的时候可能并不明显,越往后就越发难以控制。

而产品设计又不像盖楼那么在刚开始就能清楚的知道这是一栋什么样的楼。产品设计在刚开始时,都倾向于从用户角度出发,将用户的需求转化为系统的一个个功能。设计大部分情况成了堆砌功能。来一个堆一个,虽然也有一定程度的思考,但力度不够,不能从系统的角度去思考,最终还是一座将倾的大厦。

什么样的场景下需要信息架构

复杂场景最需要。一般场景如果也有这个思维,也是百利无一害。

举一个复杂场景的例子。假设要设计一个复杂系统,一般流程是这样的:

  1. 用户调研,构建persona。按道理这是第一步,不过鉴于现在电商已经很成熟,大家的业务功能已经很完善,直接借鉴就可以了,不用为了调研而调研。
  2. 确定mvp版本需求。在这个时候,一大堆功能就产生了,一切都是为了用户。
  3. 原型设计。按照确定好的需求,来设计原型图。一上来开始聚焦功能,就为灾难埋下了一个坚强的种子,一定能等到它发芽长出来的时刻。

后面流程大家都熟悉,不详解了。

以满足用户需求的明细将一对功能堆砌在一起,然后越往后开发,就越觉得困难。如果运气好,第一版看着什么都有,也没有什么问题,但越往后就越觉得困难重重,每一次的改版都好想重构。又没有那么多的时间让你重构。

拿我们最熟悉的电商网站来说,设计一个电商网站的原型是分分钟的事情。对于非技术出身的产品来说,倾向于从用户角度来思考整件事情,把用户使用的界面与流程都设计完整了,但是对于一些状态,以及状态的转化,信息的维护,架构的扩展,营销系统的设计,都相对欠缺。即使是一些技术出身的产品,如果没有专门的信息架构方面的意识,也会陷入的一些逻辑正确的设计细节,而没有总体观。

再来说电商网站,如果我们从架构上去区分,要首先搞清楚它所包含的以下子系统:

  • 商品:信息如何展示,维护,价格是否要单独管理。很多时候,价格需要单独管理,因为商品的基本信息是一定的,但是价格,却会根据环境变化进行相应的调整
  • 订单:订单的产生、失效、关闭、退货。物流状态和订单状态相关,但两种完全不同。
  • 财务:资金的进出。包括用户以及供应商资金的进出。
  • 报表:查看各个商品交易情况。
  • 用户统计:查看网站的流量、日活,月活等。
  • 营销:多种营销方式,能够满很容易的推出各类型营销活动,如满减,折扣,代金券等
  • 权限:各个层级的人员,进入整个网站后台系统中要有不同的权限。比如商品维护的只看商品相关,不能查看财务和订单数据。
  • 网站扩展性:比如临时加一个导航等,可以通过后台直接生成,而不是每次都改前后台。

以上,只是一个电商网站基础要搞清楚的架构内容,复杂点的,还有多个供应商所使用的支撑系统等。

这种情况下,要是这些内容先没有搞清楚它是什么,它们之间的相互关系是怎么样的,就直接开始设计功能,最后看到的必然是一个支离破碎,千疮百孔,不断打补丁的系统。

怎么去做架构

架构听上去很深奥,实际上就是把一个大的系统区分成若干小的系统的过程,在这个过程中需要定义清楚这些小系统之间是怎么联系起来的,为什么要这样联系起来。只要以一种小系统而组合成的大系统往往具有更稳定更强的生命力。就像超能陆战队中的情节,最厉害的机器人是由一个个单独的小机器人组合起来的。

简单的需求不需要架构。

在遇到上面那种复杂系统时,就要先从系统级别来定义架构,区分子模块。

一般,你用思维导图去做就可以了。

一是先定义清楚你目前做的这个系统包含哪些模块,尽量分的细一些。而如果分的过粗,在实际的开发中就会惊愕的发现原来此处有雷。

二是在有一个基本的子系统划分后,去考虑哪些是可以合并的,做到一个系统中。对细分的子系统进行整合,保证在相当一段时间内,两个子系统不会因为功能的扩展而逐渐交织,乃至重复。

三也是很重要的一点,各个子系统的相互关系。里边如果有复杂的逻辑的,一定要花时间去想清楚这里边的逻辑。比如他们之间的数据的相互调用,状态的相互关联。

这些都做完了,你会发现剩下的设计工作就很容易了。你就再也不会产生大厦将倾的恐惧。

 

作者:Peter,360产品经理,10年互联网产品设计经验,曾经历旅游创业公司从零开始搭建所有系统的过程。

本文由 @Peter 原创发布于人人都是产品经理。未经许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
海报
评论
评论请登录
  1. 你这里指的是产品架构,我觉得和信息架构还是不同的,信息架构侧重信息,即产品是一个信息环境,信息架构研究的就是去如何组织信息,让用户更好地理解和使用,而产品架构会更抽象,它是一种划分系统、定义系统边界和关系的思考方法,更多是帮助产品开发者去以一种低耦合、高扩展的方式去持续构建完整系统,两者本身出发点就不大一样,虽然最终产品架构会一定程度上映射到信息架构上

    来自广东 回复
  2. 现在也在迷失在系统架构里面,看后有所帮助,想问下,系统架构和功能架构如何区分,老是很容易把系统架构做成功能架构。在这方面两者需要着重思考哪些侧重点?然后,两者在上下级关系或者关联性上有所互通嘛?谢谢

    来自河南 回复
    1. 我这样理解,不知道对不对,系统架构只各相互封闭的功能集成模块之间通过接口等进行交互,系统架构高于功能架构,功能架构平行于信息架构,功能架构对应偏工具类产品、信息架构对应偏信息类产品,欢迎聊聊。

      来自北京 回复
  3. 真扯

    来自北京 回复
    1. 尊重

      回复
  4. 有思维导图先将各个子模块定义好,思考之间的逻辑,之后在做相应的架构设计

    来自广东 回复